Information Security Governance Documents

An organization’s ISG documents form the basis of its information security program. They document the organization’s commitment to information security. They are used to address:

• The organization’s information security goals
• How the organization protects its own data
• How the organization protects the data of others
• Compliance with legal and regulatory requirements
• Employee information security responsibilities
• Consequences for failing to meet responsibilities

Organizations use policies, standards, guidelines, and procedures to create their security program. These documents work together to support information security goals. A formal policy is the highest-level governance document. Standards are the next level. Then procedures. Guidelines provide security advice. The documents move from the general (policies) to the more specific (procedure). FIGURE 13-3 shows how these documents work together.

For purposes of this discussion, these documents are collectively referred to as “ISG documents” or “policies.” You should keep in mind that the term policies is often used in a very generic way. It is used to describe the entire suite of ISG documents. It will be clear from the text when the term is used in the generic way.

Policies

A formal policy is executive management’s high-level statement of information security direction and goals. They are the top level of governance documents and help minimize risk by laying out the organization’s information security strategy. High-level policies are approved by an organization’s BOD.

The BOD uses policies to set forth its information security goals. They also state compliance expectations. Not all organizations will have the same types of high-level policies. They are unique to each organization. Each organization develops policies by reviewing its regulatory landscape, taking into account the size and complexity of the organization and its IT systems. They also think about how information security can be used to help meet business goals.

Policies must be drafted with care. Policy elements vary among organizations. However, there are some common elements to all policies. They include:

• Policy statement—States the expected behavior, actions, or outcomes. It is a clear statement of permitted or forbidden actions.
• Policy exclusions—Lists situations or people who are not covered by the policy. For the most part, there should not be many exclusions in a high-level policy.
• Policy rationale—States the reason why the policy exists. This includes the legal or regulatory reasons for the policy. A policy might be drafted in response to information security threats.
• Policy definitions—Defines terms that have special meaning. Terms with common definitions do not need to be defined.
• Who is affected by the policy—States the people, units, or departments affected by the policy. In a high-level policy, this usually is all of the organization’s employees.
• Who must follow the policy—Lists who must follow the policy as part of their job responsibilities, or if some people have special policy responsibilities because of their job duties.
• Compliance language—States how the organization will enforce the policy. It also states what happens to units and employees who fail to follow the policy.
• Related documents—Lists other documents that are related to the policy. Standards or procedures that support the policy should be listed in this section.
• Policy contact—Lists the person who is responsible for answering questions about the policy.
• Policy history—Lists historical data about the policy. This section should list revision and review dates.

High-level policies are concise and tightly worded so that they are easy to understand. A high-level information security policy states the organization’s information security expectations. They should be written in a way so that all employees can understand them. These high-level documents do not usually include explanations about how to meet those expectations. Supporting documents, such as standards, guidelines, and procedures, provide that detail.

FYI

Policy documents tend to go through a lengthy development and review process. The process can be very time consuming because policies are high-level governance documents from executive management. They have a broad scope and address the whole organization. Most policy development processes include multiple levels of review so that other leaders within the organization have a chance to comment on the policies while they are being developed. These leaders will tell executive management how the policy will affect their units or departments.

Policies are rarely changed because they contain language that sets forth general expectations. The broad goals stated in a policy should not need to be changed often. Standards and procedures are used to provide flexibility and are easier to change. An organization can easily update these documents in response to changing technology conditions.

Standards

Standards support high-level policies and state the activities and actions needed to meet policy goals. They are just below policies in the ISG documents hierarchy. Standards are more specific than policies. Standards may require employees to take (or refrain from) certain actions and often state a minimum level of behavior or actions that must be met to comply with a policy. This is called a baseline.

Standards are technology neutral. They do not refer to specific technologies or products. Instead, they refer to the safeguards and controls an organization should use to protect data and IT resources.

Several different ISG levels can create standards. They are usually created at the CIO or CISO level. However, an organization’s BOD is not usually involved in creating standards. An organization usually develops standards with input from information security managers because they have overall organizational responsibility for implementing information security. They are the subject matter experts in what it will take to implement the standard.

Procedures

Procedures are the lowest level of ISG documents. They are step-by-step checklists that explain “how” to meet security goals or conduct security-related activities. Organizations often tailor their procedures to a certain type of technology. They also can be limited to the activities of specific departments or end users.

Procedures usually only address single tasks. They are designed to be flexible so they can change as technology changes. Information security managers usually create procedures, although a CIO or CISO may sometimes review procedures. For the most part, however, procedures are department- or technology-specific documents.

Guidelines

Guidelines are the most flexible type of ISG document. Organizations can issue guidelines for several reasons. They issue guidelines to:

• Encourage employees to adopt good information security practices
• Educate employees about security threats and how to respond to them
• Encourage employees to take action in areas that the organization cannot

An organization can use guidelines to give information security advice. They can recommend actions that an employee can apply on his or her own. The guidelines help employees adopt behaviors that improve information security. Sometimes they address specific kinds of employee behavior. They also might address a specific security issue. For example, an organization might create a guideline to help employees learn how to avoid social engineering attacks.

Organizations might issue guidelines to address issues that they cannot control through technical measures or organizational authority. This is where the organization needs its employees to help it protect IT resources. They hope that they can encourage employees to read the guidelines and take individual action.

For example, an organization may allow its employees to access its IT systems from home because it increases productivity. It allows employees to work from home on days when they otherwise would not be working. (For example, if a parent stays home to care for a sick child or if an office is closed due to a global health pandemic.) Employees may use their home personal computing equipment to complete their work in these situations. However, the organization must safeguard its IT resources from security threats introduced by this activity, such as malware that might be on an employee’s home computer that could be transmitted to the organization’s IT resources.

The organization has no real way to make employees use good security practices at home. It has no real authority to require employees to protect their home computers. To encourage employees to secure their home computers, the organization can issue a guideline. The guideline outlines security safeguards that employees can use at home. Following the guideline benefits employees because it helps them secure their own personal data. It also helps protect the organization’s IT resources if the employee follows the recommended practices. Both the employee’s computer and the organization’s IT resources are protected. It is a winning situation for everyone.

Creating Information Security Policies

Each type of ISG document has a different role and focus. They might be directed at different audiences. They might address similar issues from different standpoints. However, they do share some similarities. These similarities include:

• They must be easy to understand.
• They must have a well-defined scope.
• They must be regularly reviewed.
• They must be communicated to all employees.

First, the documents must be easy to read. All employees must be able to understand them. Even if the subject matter deals with legal issues, the document itself should be free from legalese. The documents should not use technical jargon. The only time it is OK to use complex language is when it is needed to help employees know their responsibilities. Otherwise, these documents must be understandable so that employees can follow them.

Second, ISG documents must have a clear scope. They must clearly address a specific aspect of the organization’s security program. Employees should not have to consult many high-level documents to determine the organization’s stance on a single issue. Ensuring that policy scope is clearly outlined helps employees follow the policy.

Third, the organization must regularly review its ISG documents. Information security does not exist in a vacuum. Risks change. Laws change. Technology changes. An organization must respond to these changes in its security program. To do this, they must review their ISG documents on a regular basis to make sure that they are current.

Finally, an organization must communicate the ISG documents to its employees. Employees cannot follow policies that they do not know about. Good communication makes sure that employees view ISG documents as business enablers. Organizations can communicate ISG documents to employees in several ways. They can use newsletters, in-person and online training, or company-wide email messages. Many communication mechanisms should be used to make sure that employees know about the ISG documents.

Policy Development Process

An organization should create a structured ISG document development process. It may even want to consider writing a “policy on policies” to specify the formal process. A formal process gives many units, departments, and stakeholders the opportunity to comment on a policy. This is very important for high-level policies that apply to the whole organization. A formal process also makes sure that final policies are communicated to employees. It also provides organizations with a way to make sure that policies are reviewed regularly.

In general, a policy development process should include the following steps:

1. Development
2. Stakeholder review
3. Management approval
4. Communication to employees
5. Documentation of compliance or exceptions
6. Continued awareness activities
7. Maintenance and review

The need for a new ISG document is determined in the development phase. The BOD, CIO, or CISO might decide that there is a need for a high-level policy. An information security department might also notice situations that require a new high-level document to guide the organization. The idea for a new ISG document really can come from anywhere in an organization. This section focuses on how high-level policies are created. However, a similar development process is recommended for other ISG documents, such as standards and procedures, as well.

Once a policy need is identified, the BOD must determine the goals of the policy. To do this, it reviews several areas. It looks at its use of IT resources and reviews the data that it is legally required to protect. It considers its business objectives. An organization’s CIO or CISO will give advice about information security issues. The BOD also might consider how other companies in the same industry approach a certain type of issue. After this review, the BOD establishes the policy goals.

An organization must take care when it drafts high-level policies. It must make sure that a new high-level policy does not conflict with any previously issued policy. Stakeholders must review the draft when it is finished.

FYI

At the next step, stakeholders review the ISG draft documents. Stakeholders are interested parties. They are employees and departments that will be affected by the new policy. They also may be subject matter experts in the underlying policy subject matter. IT resource managers also will review the document at this point. They do this to make sure that they can implement technical controls to meet the policy.

This also is the step where legal counsel, risk management, and audit will review the document. These groups make sure that the document meets the organization’s regulatory needs. Risk management and audit departments will want to make sure that they can measure policy compliance actions. Legal counsel makes sure that the document helps protect the organization from legal liability. The organization may revise the policy many times during this step.

The policy must be signed when it is in final form. The BOD must always review and sign high-level information security policies. Their support is crucial for a successful information security program. They do not always sign lower-level documents. The executive with authority over certain tasks may sign lower-level documents; for example, a CIO or CISO might sign standards or guidelines. Departmental managers and supervisors may sign procedures for their specific areas. Each organization will make its own rules about who needs to approve and sign each level of ISG document.

The next step, the communication step, is the most critical step in the development process. Communication is necessary to make sure that all employees know about the new policy. It helps employees know where to find resources to follow the policy. Organizations can communicate new policies in several different ways. Internal newsletters, memos, and company-wide emails can all be used to inform employees about a new policy.

As part of the overall development process, an organization must measure policy compliance. It must know how departments act to meet policy requirements. It also must note any exceptions to compliance. An organization can show compliance by documenting the following:

• When the ISG document was approved
• How and when it was communicated to employees
• Actions departments took to meet the responsibilities stated in the ISG document
• Deviations from the requirements in the ISG document

Sometimes departments might request an exception to a policy. They can request an exception for several reasons. For example, a policy might state a technical control that an IT system cannot meet for a very legitimate reason. Or it might require an action that a business unit cannot take because of some other regulatory requirement.

Organizations must have a formal way to review policy exception requests. For example, the BOD must review, approve, and document each high-level policy exception request. A BOD might assign this role to an upper management official with technology expertise such as a CIO or CISO. Exception requests from standards and procedures might be handled by the CIO or CISO as well.

An organization must carefully consider exception requests. This is because every policy exception weakens the organization’s overall security posture. There are two main reasons to grant a policy exception request. The first is when following the policy negatively affects the organization’s business objectives. This might happen when a policy control interferes with a critical business process.

The second reason to approve an exception request is when the cost to comply with the policy is more than the cost of noncompliance. For example, an organization may grant an exception request if a particular IT resource is incapable of technically meeting a policy requirement. It might do this if buying new equipment is too expensive. In those cases, the organization still must implement controls to protect the IT resource. The policy exception request must document how an area will use compensating controls to meet the spirit of the policy.

The development process must continually educate employees about policy compliance. Ongoing security training and awareness are required to keep employees aware of their responsibilities. An organization must build regular policy awareness activities into its day-to-day routine. For example, they can be included in other training programs, such as workplace safety programs.

Finally, an organization must review its ISG documents on a regular schedule. They must make sure the documents continue to reflect business and information security goals. Sometimes internal or external factors change so much that an organization must change its policies. At this point, it can either update its policy or withdraw it and create a new one. A BOD demonstrates due diligence and reasonable care when it regularly reviews its policies. FIGURE 13-4 shows the policy development process.

An organization can adjust the development process if necessary. For example, it might need to create a new policy to respond to a new law. It can step that policy through the development process quickly, then go back and review the document once the urgent regulatory need has passed. In addition, the process can be shortened for some ISG documents. Standards and procedures that apply to one department only may go through an expedited review process. This is because there may not be as many people who need to comment on them.

An organization uses ISG documents to support its business objectives and information security goals. These policies form the basis of an information security program. They also set the tone for a culture of information security awareness.