What Should be in a Good Cybersecurity Policy

I often get called in to evaluate cybersecurity documentation, more specific policies and procedures. One of the concerns is what to include in such documents. For local governments, it is often easy to borrow a policy or procedure from another local government. As a result, sometimes the policies do not reflect the organization’s culture and may miss items that are important to that organization. However, borrowing policies and procedures can get an organization up and running much quicker than others.

Small businesses that attempt to write policies often find it difficult to get started because the same openness to share that you have in local governments is not there. For this reason, they often have to start from scratch. Some make policies that are very simple, and others make policies that are very complex. Which is better? Every organization is different and should go with what matches the needs of its style and culture.

What should I have in my policies?

Make sure your policies cover the following:

Purpose or Overview: the reason behind the policy that’s aligned to the organizational mission
Scope and Applicability: to what and to whom does the policy apply?
Policy Statement: what is to be done, when, how, etc?
Roles and Responsibilities: who is responsible for what?
Exceptions: any exceptions, how exceptions will be handled, and who can make exceptions (should be based on risk and mission)
Enforcement and Violations: how will they be handled, any oversight
Limitations on Liability (if needed)
Approval and Authorization: who approved the policy, when does it take effect, when is it to be reviewed again, and is there a sunset clause?
References: including Definitions and any external requirements (contracts, laws, standards, etc.)
Document History: revision and review history

Purpose and Overview

All policies should start with “why”: Why does this policy exist and, more specifically, how does this policy help your organization meet its goals and mission? I highly recommend this, so when employees read the document, you tell them upfront why it is important before they lose attention. By starting with “why,” you are more likely to get buy-in on the policy. Staff buy-in is extremely important.

I often find organizations that have difficulty getting staff to follow proper policies and procedures. I won’t beat around the bush on this one—it is a management problem. Management has to set the tone. If executives feel they are above the policies they have established, it sends a message to the employees that following proper protocol is not required. Management needs to take leadership in this area and set the example that the rules apply to everyone, even the CEO.

Scope and Applicability

The next thing I recommend is to define the scope of the policy. State whom and what this document applies to, and what systems, data, communications, and applications software are applicable to this policy or procedure.

I also recommend adding any exceptions or exclusions to the policy. For example, it is not a good policy item to say that all systems will have anti-malware on them without scoping the applicability. Sometimes the people drafting the policy are not aware that such a policy statement is impossible to apply to all systems. Anti-malware is not typically installed in IoT devices or networking and communication devices like routers and switches. A better policy statement would either set the scope of the statement to exclude devices that do not have the capability or broaden the policy statement by saying anti-malware mechanisms shall be put in place to reduce the risk of malware execution. Anti-malware mechanisms include but are not limited to anti-malware software. It could include regular patch management or it could include a locked down configuration.

Policy Statement

In this section, you cover what it is that management, board, executive team, or council wants to happen. This is the management’s statement of the extent of risk the firm is willing to take in pursuant of its mission. Of course, there is risk in everything we do, and policies are a way of saying we want to limit our exposure and define the acceptable level of risk. This means that employees need to be counselled on risk and that information needs to be delivered to them in a meaningful way. More on that in a later post.

The biggest mistake I see in this area is the tendency to make the statement too narrow and overly complex. The policy statement needs to address the operational risk related to the organization being able to accomplish its objectives. It should be written broadly enough that it can apply to all systems in every department, from the top to the bottom of the organization. When it gets too specific or too detailed, the policy ends up being inapplicable to one department. As such, when the policy is implemented, it hinders staff’s ability to effectively and efficiently meet their department’s mission. There is a philosophy of cascading missions within an organization, which I will talk about in a later post. For now, the point is that the policy should not hinder the fulfillment of the mission anywhere within an organization just because it was poorly planned or worded.

Roles and Responsibilities

The next section should state who does what. State who oversees the process, who executes the process, and who ensures and validates that the process is being done properly. In this section, you can also state how often the policy should be reviewed and who should review it.

One tip on assigning responsibility: assign it to a title or position and not an individual by name. I have witnessed instances where someone has been at the organization forever and intends to work until retirement, so the person is listed and not the role or position. The idea is you don’t want to have to update the policy if there is a change in staff or if the person is out on vacation. When assigned to a role, there is no need to update the policy when staff changes. Plus, if someone goes on vacation, the role can be assigned to someone else until that person gets back.

Exceptions

Because technology changes so quickly, even the best written policy can suddenly become obsolete or, worse, stand in the way of business processes. It is important to address the possibility that an exception to the policy is needed in order for the organization to continue to meet its mission.

You need to outline the process for making an exception to the policy or potentially state that there are to be no exceptions. Generally, the process should include the documentation on why the exception is needed, why the policy cannot be applied, or the negative effect that would result from applying the policy. It would also include who is able to approve the exception and any reporting requirements.

For a local government, this clause may require the CIO or equivalent to review the request with the CISO or equivalent. The document would include a brief description of the risk associated with the proposed solution. That request could then be forwarded to the CEO (City Manager) for approval. This helps the CEO to make an informed risk-based decision. In the case of a city, reporting of the exception would be done to City Council. Depending on the sensitivity of the situation, this may need to be a confidential report and not open to the public.

Enforcement and Violations

All policies should cover what is to happen if an employee violates the policy. Will the employee be held personally liable? What disciplinary action can be taken? Normally, you’d want to keep this clause as open as possible to give your organization the most flexibility. Each situation will be different and the impact on the organization can range from nonexistent to catastrophic.

This clause is important when an organization has union employees who may be subjected to contract implications. It is a good idea to have legal counsel review these provisions to ensure that they will be enforceable and not leave the organization open to litigation. Well, I guess you are always open to litigation! But you want to make sure you can win the case if someone brings a lawsuit against your organization. A lawyer can help you with that.

This provision does not have to be in each policy in an organization. If an organization has a policy portfolio, they can have this clause in one policy and have it applied to all others. If you already have such a clause, make sure it covers the cybersecurity and IT policies.

Limitations on Liability

This is another section for legal wording. This is mostly needed if any action someone could take related to the policy might have a potential to harm the individual. Generally, you will see this in an acceptable use policy (Terms of Use, Rules of Behavior). For example, an employee may use the organization Wi-Fi and as a result, they get malware on their system. This section would have wording that limits liability for the organization hosting the Wi-Fi.

Limitations on liability will not be needed in all policies.

Approval and Authorization

This section covers who approved the policy and anything on when the policy goes into effect. It may also contain a sunset clause as to when the policy will expire. You may wish to include a section that covers review requirements. For example, it may require staff to review the policy annually and report any suggested changes to the Board or Council on a predetermined frequency. For a city, you may have policies at different levels, such as policies by Council and by the City Manager. Council policies obviously supersede those by the City Manager, although you don’t really want conflicts between the two.

References

If you reference another policy, procedure, standard, guideline, law, or any other document, ensure that you provide a link, the title and description, and location of the document. Don’t forget to include the location in case the document link is broken in the future.

In this section, I always recommend calling out any standards that apply to this policy. This will help in the review phase. For example, if we are talking about an anti-malware policy, I would include a reference to PCI DSS and NIST guidelines. During policy reviews, you will clearly know that this policy is required for compliance or as part of industry best practices. On the flip side, if standards and guidelines evolve, you will be able to readily find applicable policies and see if there is any impact with those policies. It also makes the auditor/assessor’s job and your compliance tracking much easier.

Definitions

You’d want to include definitions in your document. Don’t assume that everyone who reads it will know the terminology. I recommend pointing to NIST for industry-specific definitions that most people in the industry will know without having to look them up. When you have an assessor or auditor look at your policies, it will take them longer to understand if you are not using industry standard definitions. In short, don’t make up your own words and be sure to call out specific terms.

One example is “information systems,” whose definition according to OMB and NIST includes far more than technology. It includes people, processes, and technology that process information. With that definition, typing pools and file cabinets are all part of an information system. Another example is “cybersecurity,” which is maintaining the confidentiality, integrity, and availability of information and systems. I often see policies that state “security and integrity” or “security and availability.” These are redundant because security already includes integrity and availability. So, provide definitions of the terms to tighten up the wording in your policy and make it clearer.

Document History

Finally, I recommend ending the document with a document history. List out when it was adopted, when it was reviewed, and when it was changed. Even if the policy was reviewed and no changes were made to it, make an entry in the document. That way you and third parties like auditors will know that you are periodically reviewing them.

Key takeaways