This chapter is from the book
This chapter is from the book
This chapter is from the book
Policy Format
Writing policy documents can be challenging. Policies are complex documents that must be written to withstand legal and regulatory scrutiny and at the same time must be easy for a reader to read and understand. The starting point for choosing a format is identifying the policy audience.
Understand Your Audience
Who a policy is intended for is referred to as the policy audience. It is imperative during the planning portion of the security policy project to clearly define the audience. Policies may be intended for a particular group of employees based on job function or role. For example, an application development policy is targeted to developers. Other policies may be intended for a particular group or individual based on organizational role, such as a policy defining the responsibility of the chief information security officer (CISO). The policy, or portions of it, can sometimes apply to people outside the company, such as business partners, service providers, contractors, or consultants. The policy audience is a potential resource during the entire policy life cycle. Indeed, who better to help create and maintain an effective policy than the very people whose job it is to use those policies in the context of their everyday work?
Policy Format Types
Organize before you begin writing! It is important to decide how many sections and subsections you will require before you begin writing. Designing a template that allows the flexibility of editing will save considerable time and reduce aggravation. In this section, you will learn about the different sections and subsections of a policy, as well as the policy document formation options.
There are two general ways to structure and format a policy:
Singular policy: Write each policy as a discrete document.
Consolidated policy: Group together similar and related policies.
Consolidated policies are often organized by section and subsection.
Table 2-1 illustrates policy document format options.
TABLE 2-1 Policy Document Format Options
Format |
Example |
|---|---|
Singular policy |
Chief information security officer (CISO) policy: Specific to the role and responsibility of the information security officer. |
Consolidated policy |
Governance policy: Addresses the role and responsibilities of the board of directors, executive management, chief risk officer, CISO, compliance officer, legal counsel, auditor, IT director, and users. |
The advantage of creating individual policies is that each policy document can be short, clean, crisp, and targeted to its intended audience. The disadvantage is the need to manage multiple policy documents and the chance that they will become fragmented and lose consistency. The advantage of a consolidated policy is that it presents a composite management statement in a single voice. The disadvantages are the potential size of the document and the difficulty the reader may have locating applicable sections.
In the first edition of this book, we limited our study to singular policy documents. Since then, both the use of technology and the regulatory landscape have increased exponentially—only outpaced by escalating threats. In response to this ever-changing environment, the need for policies and the number of policies has grown. For many organizations, managing singular policies has become unwieldy. The current trend is toward consolidation. Throughout this edition, we have consolidated policies by security domain.
Regardless of which format you choose, you should not include standards, baselines, guidelines, or procedures in your policy document. If you do, you will end up with one big unruly document. And you will undoubtedly encounter one or more of the following problems:
Management challenge: Who is responsible for managing and maintaining a document that has multiple contributors?
Difficulty of updating: Because standards, guidelines, and procedures change far more often than policies, updating this whale of a document will be far more difficult than if these elements were properly treated separately. Version control will become a nightmare.
Cumbersome approval process: Various regulations as well as the corporate operating agreement require that the board of directors approve new policies as well as changes. Mashing it all together means that every change to a procedure, guideline, or standard will potentially require the board to review and approve it. This will become very costly and cumbersome for everyone involved.
Policy Components
Policy documents have multiple sections or components (see Table 2-2). How the components are used and in what order depends on which format—singular or consolidated—you choose. In this section, we examine the composition of each component. Consolidated policy examples are provided in the “In Practice” sidebars.
TABLE 2-2 Policy Document Components
Component |
Purpose |
|---|---|
Version control |
To track changes |
Introduction |
To frame the document |
Policy heading |
To identify the topic |
Policy goals and objectives |
To convey intent |
Policy statement |
Mandatory directive |
Policy exceptions |
To acknowledge exclusions |
Policy enforcement clause |
Violation sanctions |
Administrative notations |
Additional information |
Policy definitions |
Glossary of terms |
Version Control
Best practices dictate that policies are reviewed annually to ensure that they are still applicable and accurate. Of course, policies can (and should) be updated whenever there is a relevant change driver. Version control, as it relates to policies, is the management of changes to the document. The version is usually identified by a number or letter code. Major revisions generally advance to the next letter or digit (for example, from 2.0 to 3.0). Minor revisions generally advance as a subsection (for example, from 2.0 to 2.1). Version control documentation should include the change date, the name of the person or persons making the change; a brief synopsis of the change; the name of the person, committee, or board that authorized the change; and the effective date of the change.
For a singular policy document, this information is split between the policy heading and the administrative notation sections.
For a consolidated policy document, a version control table is included either at the beginning of the document or at the beginning of a section.
Introduction
Think of the introduction as the opening act. This is where authors first meet the readers and have the opportunity to engage them. Here are the objectives of the introduction:
To provide context and meaning
To convey the importance of understanding and adhering to the policy
To acquaint the reader with the document and its contents
To explain the exemption process as well as the consequence of noncompliance
To reinforce the authority of the policy
The first part of the introduction should make the case for why the policy is necessary. It is a reflection of the guiding principles, defining for the reader the core values the company believes in and is committed to. This is also the place to set forth the regulatory and contractual obligations that the company has—often by listing which regulations, such as GLBA, HIPAA, or MA CMR 17 201, pertain to the organization as well as the scope of the policy.
The second part of the introduction should leave no doubt that compliance is mandatory. A strong statement of expectation from a senior authority, such as the chair of the board, CEO, or president, is appropriate. Users should understand that they are unequivocally and directly responsible for following the policy in the course of their normal employment or relationship with the company. This part of the introduction should also make clear that questions are welcome, and a resource is available who can clarify the policy and/or assist with compliance.
The third part of the introduction should describe the policy document, including the structure, categories, and storage location (for example, the company intranet). It should also reference companion documents such as standards, guidelines, programs, and plans. In some cases, the introduction includes a revision history, the stakeholders who may have reviewed the policy, and who to contact to make any modifications.
The fourth part of the introduction should explain how to handle situations where compliance may not be feasible. It should provide a high-level view of the exemption and enforcement process. The section should also address the consequences of willful noncompliance.
For a singular policy document, the introduction should be a separate document.
For a consolidated policy document, the introduction serves as the preface and follows the version control table.
Policy Heading
A policy heading identifies the policy by name and provides the reader with an overview of the policy topic or category. The format and contents of the heading significantly depend on the format (singular or consolidated) you are using:
A singular policy must be able to stand on its own, which means it is necessary to include significant logistical detail in each heading. The information contained in a singular policy heading may include the organization or division name, category (section), subsection, policy number, name of the author, version number, approval authority, effective date of the policy, regulatory cross-reference, and a list of supporting resources and source material. The topic is generally self-explanatory and does not require an overview or explanation.
In a consolidated policy document, the heading serves as a section introduction and includes an overview. Because the version number, approval authority, and effective date of the policy have been documented in the version control table, it is unnecessary to include them in section headings. Regulatory cross-reference (if applicable), lead author, and supporting documentation are found in the Administrative Notation section of the policy.
Policy Goals and Objectives
Policy goals and objectives act as a gateway to the content to come and the security principle they address. This component should concisely convey the intent of the policy. Note that even a singular policy can have multiple objectives. We live in a world where business matters are complex and interconnected, which means that a policy with a single objective might be at risk of not covering all aspects of a particular situation. It is therefore important, during the planning phase, to pay appropriate attention to the different objectives the security policy should seek to achieve.
A singular policy lists the goals and objectives either in the policy heading or in the body of the document.
In a consolidated policy document, the goals and objectives are grouped and follow the policy heading.
Policy Statement
Up to this point in the document, we have discussed everything but the actual policy statement. The policy statement is a high-level directive or strategic roadmap. This is the section where we lay out the rules that need to be followed and, in some cases, reference the implementation instructions (standards) or corresponding plans. Policy statements are intended to provide action items as well as the framework for situational responses. Policies are mandatory. Deviations or exceptions must be subject to a rigorous examination process.
Policy Exceptions and the Exemption Process
Realistically, there will be situations in which it is not possible or practical—or perhaps may even be harmful—to obey a policy directive. This does not invalidate the purpose or quality of the policy. It just means that some special situations will call for exceptions to the rule. Policy exceptions are agreed waivers that are documented within the policy. For example, in order to protect its intellectual property, Company A has a policy that bans digital cameras from all company premises. However, a case could be made that the HR department should be equipped with a digital camera to take pictures of new employees to paste them on their ID badges. Or maybe the security officer should have a digital camera to document the proceedings of evidence gathering after a security breach has been detected. Both examples are valid reasons a digital camera might be needed. In these cases, an exception to the policy could be added to the document. If no exceptions are ever to be allowed, this should be clearly stated in the policy statement section as well.
An exemption or waiver process is required for exceptions identified after the policy has been authorized. The exemption process should be explained in the introduction. Only the method or process for requesting an exemption—and not the criteria or conditions for exemptions—should be detailed in the policy. Trying to list all the conditions to which exemptions apply can lead to creating a loophole in the exemption itself. It is also important that the process follow specific criteria under which exemptions are granted or rejected. Whether an exemption is granted or rejected, the requesting party should be given a written report with clear reasons either way.
Finally, it is recommended that you keep the number of approved exceptions and exemptions low, for several reasons:
Too many built-in exceptions may lead employees to perceive the policy as unimportant.
Granting too many exemptions may create the impression of favoritism.
It can become difficult to keep track of and successfully audit a large number of exceptions and exemptions.
If there are too many built-in exceptions and/or exemption requests, it may indicate that the policy is not appropriate in the first place. At that point, the policy should be subject to review.
Policy Enforcement Clause
The best way to deliver the message that policies are mandatory is to include the penalty for violating the rules. The policy enforcement clause is where the sanctions for non-adherence to the policy are unequivocally stated to reinforce the seriousness of compliance. Obviously, you must be careful with the nature of the penalty. It should be proportional to the rule that was broken, whether it was accidental or intentional, and the level of risk the company incurred.
An effective method of motivating compliance is proactive training. All employees should be trained in the acceptable practices presented in the security policy. Without training, it is hard to fault employees for not knowing they were supposed to act in a certain fashion. Imposing disciplinary actions in such situations can adversely affect morale. We take a look at various training, education, and awareness tools and techniques in later chapters.
Administrative Notations
The purpose of administrative notations is to refer the reader to additional information and/or provide a reference to an internal resource. Notations include regulatory cross-references; the names of corresponding documents, such as standards, guidelines, and programs; supporting documentation such as annual reports or job descriptions; and the policy author’s name and contact information. You should include only notations that are applicable to your organization. However, you should be consistent across all policies.
A singular policy incorporates administrative notations either in the heading, at the end of the document, or split between the two locations. How this is handled depends on the company’s policy template.
In a consolidated policy document, the administrative notations are located at the end of each section.
Policy Definitions
The policy definition section is a glossary of terms, abbreviations, and acronyms used in the document that the reader may be unfamiliar with. Adding definitions to the overall document will aid the target audience in understanding the policy and will therefore make the policy a much more effective document.
The general rule is to include definitions for any instance of industry-specific, technical, legal, or regulatory language. When deciding what terms to include, it makes sense to err on the side of caution. The purpose of the security policy document is communication and education. The target audience for this document usually encompasses all employees of the company and sometimes outside personnel. Even if some technical topics are well known to all in-house employees, some of those outside individuals who come in contact with the company—and therefore are governed by the security policy—may not be as well versed in the policy’s technical aspects.
Simply put, before you begin writing down definitions, it is recommended that you first define the target audience for whom the document is crafted and cater to the lowest common denominator to ensure optimum communication efficiency.
Another reason definitions should not be ignored is for the legal ramifications they represent. An employee cannot pretend to have thought that a certain term used in the policy meant one thing when it is clearly defined in the policy itself. When you’re choosing which words will be defined, therefore, it is important to look not only at those that could clearly be unknown but also at those that should be defined to remove any and all ambiguity. A security policy could be an instrumental part of legal proceedings and should therefore be viewed as a legal document and crafted as such.