Cybersecurity Policy Organization, Format, and Styles
By Omar Santos
Date: Aug 5, 2024
In this chapter, we go over cybersecurity policies in the private sector, from guiding principles, policy, standards, procedures, and guidelines, as well as adjunct plans and programs. Most importantly, you will learn how a well-constructed policy employs plain language to deliver the intended meaning.
In Chapter 1, “Understanding Cybersecurity Policy and Governance,” you learned that policies have played a significant role in helping us form and sustain our social, government, and corporate organizations. In this chapter, we begin by examining the hierarchy and purpose of guiding principles, policy, standards, procedures, and guidelines, as well as adjunct plans and programs. Returning to our focus on policies, we examine the standard components and composition of a policy document. You will learn that even a well-constructed policy is useless if it doesn’t deliver the intended message. The end result of complex, ambiguous, or bloated policy is, at best, noncompliance. At worst, negative consequences result as such policies may not be followed or understood. In this chapter, you will be introduced to “plain language,” which involves using the simplest, most straightforward way to express an idea. Plain-language documents are easy to read, understand, and act on. By the end of the chapter, you will have the skills to construct policy and companion documents. This chapter focuses on cybersecurity policies in the private sector and not policies created by governments of any country or state.
Policy Hierarchy
As you learned in Chapter 1, a policy is a mandatory governance statement that presents management’s position. A well-written policy clearly defines guiding principles, provides guidance to those who must make present and future decisions, and serves as an implementation roadmap. Policies are important, but alone they are limited in what they can accomplish. Policies need supporting documents to give them context and meaningful application. Standards, baselines, guidelines, and procedures each play a significant role in ensuring implementation of a governance objective. The relationship between the documents is known as the policy hierarchy. In a hierarchy, with the exception of the topmost object, each object is subordinate to the one above it. In a policy hierarchy, the topmost objective is the guiding principles, as illustrated in Figure 2-1.
FIGURE 2.1 Policy Hierarchy
Cybersecurity policies should reflect the guiding principles and organizational objectives. This is why it is very important to communicate clear and well-understood organizational objectives within an organization. Standards are a set of rules and mandatory actions that provide support to a policy. Guidelines, procedures, and baselines provide support to standards. Let’s take a closer look at each of these concepts.
Standards
Standards serve as specifications for the implementation of policy and dictate mandatory requirements. For example, you might have a remote worker policy that states the following:
This policy ensures that all employees understand their obligations to maintain a secure, productive, and efficient work environment while working from a remote location.
This policy applies to all employees who are approved to work remotely, either on a full-time, part-time, or temporary basis.
Employees must be reachable via phone, email, or video conferencing during core work hours.
Company-issued equipment should be used for work purposes only and should be maintained in a secure manner.
Employees must adhere to the organization’s data security policy, including but not limited to, use of the VPN, use of approved cloud services, secure data transfer, and storage solutions.
The remote worker standard would then dictate the required characteristics, such as the following:
MFA must be enabled for all accounts accessing corporate resources.
All devices used for remote work must have up-to-date anti-malware software installed.
Laptops and workstations used for remote work must have full-disk encryption enabled.
No sensitive data should be stored locally unless approved and encrypted. Use corporate cloud storage solutions when possible.
Only software approved by the IT department may be installed on work devices.
Keep all operating systems and applications updated with the latest security patches.
Remote devices and activity may be audited periodically for compliance with this standard.
Failure to adhere to this standard may result in disciplinary actions, as described in the Remote Work Policy.
Another example of a standard is a common configuration of infrastructure devices such as routers and switches. An organization may have dozens, hundreds, or even thousands of routers and switches, and it might have a “standard” way of configuring authentication, authorization, and accounting (AAA) for administrative sessions. It might use TACACS+ or RADIUS as the authentication standard mechanism for all routers and switches within the organization.
As you can see, a policy represents expectations that are not necessarily subject to changes in technology, processes, or management. A standard, on the other hand, is very specific to the infrastructure.
Standards are determined by management, and unlike policies, they are not subject to authorization by the board of directors. Standards can be changed by management as long as they conform to the intent of the policy. A difficult task of writing a successful standard for a cybersecurity program is achieving consensus by all stakeholders and teams within an organization. In addition, a standard does not have to address everything that is defined in a policy. Standards should be compulsory and must be enforced to be effective.
Baselines
A baseline serves as a standard guideline or set of specifications that is applicable to a particular category or group within an organization. These groups can be defined by different factors such as the platform (including specific operating systems and their versions), device type (like laptops, servers, desktops, routers, switches, firewalls, and mobile devices), ownership status (whether devices are employee-owned or corporate-owned), and location (such as onsite or remote workers).
The main purpose of establishing baselines is to ensure uniformity and consistency across the organization’s technological environment. For instance, in the context of a policy for remote workers, a baseline might require that all Windows devices used by remote employees adhere to a specific Active Directory Group Policy configuration. This standard configuration is used to technically enforce security requirements, ensuring that all devices within this group meet a consistent level of security compliance. This approach helps in managing and securing IT resources effectively, particularly in diverse and distributed environments.
Guidelines
Guidelines are best thought of as teaching tools. The objective of a guideline is to help people conform to a standard. In addition to using softer language than standards, guidelines are customized for the intended audience and are not mandatory. Guidelines are akin to suggestions or advice. A guideline related to the remote worker standard in the previous example might read like this:
Use MFA all the time. MFA is a security measure that requires you to provide two or more forms of identification before you can access your account. This usually means entering your password (something you know) plus a second form of identification—like a code sent to your phone (something you have) or a face recognition scan (something you are).
Store your device in a secure place when it is not in use to minimize the risk of theft or unauthorized access.
Regularly back up important files to the corporate cloud storage solution, not to personal cloud or local storage.
Use secure methods to delete sensitive information from your device rather than just moving files to the recycle bin.
Guidelines are recommendations and advice to users when certain standards do not apply to the environment. Guidelines are designed to streamline certain processes according to best practices and must be consistent with the cybersecurity policies. At the same time, guidelines often are open to interpretation and do not need to be followed to the letter.
Procedures
Procedures are instructions for how a policy, a standard, a baseline, and guidelines are carried out in a given situation. Procedures focus on actions or steps, with specific starting and ending points. There are four commonly used procedure formats:
Simple step: Lists sequential actions. There is no decision making.
Hierarchical: Includes both generalized instructions for experienced users and detailed instructions for novices.
Graphic: Uses either pictures or symbols to illustrate the step.
Flowchart: Used when a decision-making process is associated with the task. Flowcharts are useful when multiple parties are involved in separate tasks.
Procedures should be well documented and easy to follow to ensure consistency and adherence to policies, standards, and baselines. Like policies and standards, they should be well reviewed to ensure that they accomplish the objective of the policy and that they are accurate and remain relevant.
Plans and Programs
The function of a plan is to provide strategic and tactical instructions and guidance on how to execute an initiative or how to respond to a situation, within a certain time frame, usually with defined stages and with designated resources. Plans are sometimes referred to as programs. For our purposes, the terms are interchangeable. Here are some examples of information security–related plans we discuss in this book:
Vendor management plan
Incident response plan
Business continuity plan
Disaster recovery plan
Policies and plans are closely related. For example, an incident response policy generally includes the requirement to publish, maintain, and test an incident response plan. Conversely, the incident response plan gets its authority from the policy. Quite often, the policy will be included in the plan document.
Writing Style and Technique
Style is critical. A reader’s first impression of a document is based on its style and organization. If the reader is immediately intimidated, the contents become irrelevant. Keep in mind that the role of policy is to guide behavior. That can happen only if the policy is clear and easy to use. How the document flows and the words you use will make all the difference in how the policy is interpreted. Know your intended reader and write in a way that is understandable. Use terminology that is relevant. Most importantly, keep it simple. Policies that are overly complex tend to be misinterpreted. Policies should be written using plain language.
Using Plain Language
The term plain language means using the simplest, most straightforward way to express an idea.
No single technique defines plain language. Rather, plain language is defined by results: It is easy to read, understand, and use. Studies have proven that documents created using plain-language techniques are effective in a number of ways:1
Readers understand documents better.
Readers prefer plain language.
Readers locate information faster.
Documents are easier to update.
It is easier to train people.
Plain language saves time and money.
Even confident readers appreciate plain language. It enables them to read more quickly and with increased comprehension. The use of plain language is spreading in many areas of American culture, including governments at all levels, especially the federal government, health care, the sciences, and the legal system.
The Plain Language Movement
It seems obvious that everyone would want to use plain language, but as it turns out, that is not the case. There is an enduring myth that to appear official or important, documents should be verbose. The result has been a plethora of complex and confusing regulations, contracts, and, yes, policies. In response to public frustration, the plain language movement began in earnest in the early 1970s.
In 1971, the National Council of Teachers of English in the United States formed the Public Doublespeak Committee. In 1972, U.S. President Richard Nixon created plain language momentum when he decreed that the “Federal Register be written in ‘layman’s terms.’” The next major event in the U.S. history of plain language occurred in 1978, when U.S. President Jimmy Carter issued Executive Orders 12044 and 12174, with the goal of making government regulations cost-effective and easy to understand. In 1981, U.S. President Ronald Reagan rescinded Carter’s executive orders. Nevertheless, many continued their efforts to simplify documents; by 1991, eight states had passed statutes related to plain language.
In 1998, President Clinton issued a Presidential Memorandum requiring government agencies to use plain language in communications with the public. All subsequent administrations have supported this memorandum. In 2010, plain-language advocates achieved a major victory when the Plain Writing Act was passed. This law requires federal government agencies to write publications and forms in a “clear, concise, well-organized” manner, following plain language guidelines.
We can take a cue from the government and apply these same techniques when writing policies, standards, guidelines, and plans. The easier a policy is to understand, the better the chance of compliance.
Plain Language Techniques for Policy Writing
The Plain Language Action and Information Network (PLAIN) describes itself on its website (https://plainlanguage.gov) as a group of federal employees from many agencies and specialties who support the use of clear communication in government writing. In March 2011, PLAIN published the Federal Plain Language Guidelines. Some of the guidelines are specific to government publications. Many are applicable to both government and industry. The 10 guidelines listed here are pertinent to writing policies and companion documents:
Write for your audience. Use language your audience knows and is familiar with.
Write short sentences. Express only one idea in each sentence.
Limit a paragraph to one subject. Aim for no more than seven lines.
Be concise. Leave out unnecessary words. Instead of “for the purpose of,” use “to.” Instead of “due to the fact that,” use “because.”
Don’t use jargon or technical terms when you can use everyday words that have the same meaning.
Use active voice. A sentence written in active voice shows the subject acting in standard English sentence order: subject–verb–object. Active voice makes it clear who is supposed to do what. It eliminates ambiguity about responsibilities. Not “it must be done” but “you must do it.”
Use “must,” not “shall,” to indicate requirements. “Shall” is imprecise. It can indicate either an obligation or a prediction. The word “must” is the clearest way to convey to your audience that they have to do something.
Use words and terms consistently throughout your documents. If you use the term “senior citizens” to refer to a group, continue to use this term throughout your document. Don’t substitute another term, such as “the elderly” or “the aged.” Using a different term may cause the reader to wonder if you are referring to the same group.
Omit redundant pairs or modifiers. For example, instead of “cease and desist,” use either “cease” or “desist.” Even better, use a simpler word, such as “stop.” Instead of saying “the end result was the honest truth,” say “the result was the truth.”
Avoid double negatives and exceptions to exceptions. Many ordinary terms have a negative meaning, such as unless, fail to, notwithstanding, except, other than, unlawful (“un-” words), disallowed (“dis-” words), terminate, void, insufficient, and so on. Watch out for them when they appear after “not.” Find a positive word to express your meaning.
Want to learn more about using plain language? The official website of PLAIN has a wealth of resources, including the Federal Plain Language Guidelines, training materials and presentations, videos, posters, and references.
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.
Summary
You now know that policies need supporting documents to give them context and meaningful application. Standards, guidelines, and procedures provide a means to communicate specific ways to implement our policies. We create our organizational standards, which specify the requirements for each policy. We offer guidelines to help people comply with standards. We create sets of instructions known as procedures to ensure that tasks are consistently performed. The format of a procedure—simple step, hierarchical, graphic, or flowchart—depends on the complexity of the task and the audience. In addition to creating policies, we create plans or programs to provide strategic and tactical instructions and guidance on how to execute an initiative or how to respond to a situation, within a certain time frame, usually with defined stages and with designated resources.
Writing policy documents is a multistep process. First, we need to define the audience for which the document is intended. Then, we choose the format. Options are to write each policy as a discrete document (singular policy) or to group like policies together (consolidated policy). Finally, we need to decide upon the structure, including the components to include and in what order.
The first and arguably most important section is the introduction. This is our opportunity to connect with the reader and to convey the meaning and importance of our policies. The introduction should be written by the “person in charge,” such as the CEO or president. This person should use the introduction to reinforce company-guiding principles and correlate them with the rules introduced in the security policy.
Specific to each policy are the heading, goals and objectives, policy statement, and (if applicable) exceptions. The heading identifies the policy by name and provides the reader with an overview of the policy topic or category. The goals and objectives convey what the policy is intended to accomplish. The policy statement lays out the rules that need to be followed and may reference the implementation instructions (standards) or corresponding programs. Policy exceptions are agreed waivers that are documented within the policy.
An exemption or waiver process is required for exceptions identified after a policy has been authorized. The policy enforcement clause is where the sanctions for willful non-adherence to the policy are unequivocally stated to reinforce the seriousness of compliance. Administrative notations refer the reader to additional information and/or provide references to internal resources. The policy definition section is a glossary of terms, abbreviations, and acronyms used in the document that the reader may be unfamiliar with.
Recognizing that the first impression of a document is based on its style and organization, we studied the work of the plain language movement. Using plain language helps produce documents that are easy to read, understand, and use. We looked at 10 techniques from the Federal Plain Language Guideline that we can (and should) use for writing effective policies. In the next section of the book, we put these newfound skills to use.
Multiple Choice Questions
1. The policy hierarchy is the relationships between which of the following?
Guiding principles, regulations, laws, and procedures
Guiding principles, standards, guidelines, and procedures
Guiding principles, instructions, guidelines, and programs
None of the above
2. Which of the following statements best describes the purpose of a standard?
To state the beliefs of an organization
To reflect the guiding principles
To dictate mandatory requirements
To make suggestions
3. Which of the following statements best describes the purpose of a guideline?
To state the beliefs of an organization
To reflect the guiding principles
To dictate mandatory requirements
To help people conform to a standard
4. Which of the following statements best describes the purpose of a baseline?
To measure compliance
To ensure uniformity across a similar set of devices
To ensure uniformity and consistency
To make suggestions
5. Simple step, hierarchical, graphic, and flowchart are examples of which of the following formats?
Policy
Program
Procedure
Standard
6. Which of the following terms best describes instructions and guidance on how to execute an initiative or how to respond to a situation, within a certain time frame, usually with defined stages and with designated resources?
Plan
Policy
Procedure
Package
7. Which of the following statements best describes a disadvantage to using the singular policy format?
The policy can be short.
The policy can be targeted.
You may end up with too many policies to maintain.
The policy can easily be updated.
8. Which of the following statements best describes a disadvantage to using the consolidated policy format?
Consistent language is used throughout the document.
Only one policy document must be maintained.
The format must include a composite management statement.
The document may end up being very long.
9. Policies, standards, guidelines, and procedures should all be in the same document.
True
False
Only if the company is multinational
Only if the documents have the same author
10. Version control is the management of changes to a document and should include which of the following elements?
Version or revision number
Date of authorization or date that the policy took effect
Change description
All of the above
11. What is an exploit?
A phishing campaign
A malicious program or code designed to exploit, or take advantage of, a single vulnerability or set of vulnerabilities
A network or system weakness
A protocol weakness
12. The name of the policy, policy number, and overview belong in which of the following sections?
Introduction
Policy heading
Policy goals and objectives
Policy statement
13. The aim or intent of a policy is stated in the ________.
introduction
policy heading
policy goals and objectives
policy statement
14. Which of the following statements is true?
A security policy should include only one objective.
A security policy should not include any exceptions.
A security policy should not include a glossary.
A security policy should not list all step-by-step measures that need to be taken.
15. The _________ contains the rules that must be followed.
policy heading
policy statement
policy enforcement clause
policy goals and objectives list
16. A policy should be considered _____.
mandatory
discretionary
situational
optional
17. Which of the following best describes policy definitions?
A glossary of terms, abbreviations, and acronyms used in the document that the reader may be unfamiliar with
A detailed list of the possible penalties associated with breaking rules set forth in the policy
A list of all the members of the security policy creation team
None of the above
18. The _________ contains the penalties that would apply if a portion of the security policy were to be ignored by an employee.
policy heading
policy statement
policy enforcement clause
policy statement of authority
19. What component of a security policy does the following phrase belong to? “Wireless networks are allowed only if they are separate and distinct from the corporate network.”
Introduction
Administrative notation
Policy heading
Policy statement
20. There may be situations in which it is not possible to comply with a policy directive. Where should the exemption or waiver process be explained?
Introduction
The policy statement
Policy enforcement clause
Policy exceptions
21. The name of the person/group (for example, executive committee) that authorized the policy should be included in the ___________________.
version control table or policy statement
heading or policy statement
policy statement or policy exceptions
version control table or policy heading
22. When you’re drafting a list of exceptions for a security policy, the language should _________________.
be as specific as possible
be as vague as possible
reference another, dedicated document
None of the above
23. If supporting documentation would be of use to the reader, it should be __________________.
included in full in the policy document
ignored because supporting documentation does not belong in a policy document
listed in either the policy heading or administrative notation section
included in a policy appendix
24. When writing a policy, standard, guideline, or procedure, you should use language that is ___________.
technical
clear and concise
legalese
complex
25. Readers prefer plain language because it __________________.
helps them locate pertinent information
helps them understand the information
saves time
All of the above
26. Which of the following is not a characteristic of plain language?
Short sentences
Using active voice
Technical jargon
Seven or fewer lines per paragraph
27. Which of the following is the best term to use when indicating a mandatory requirement?
must
shall
should not
may not
28. A company that uses the term “employees” to refer to workers who are on the company payroll should refer to them throughout their policies as _________.
workforce members
employees
hired hands
workers
29. Which of the following statements is true regarding policy definitions?
They should be included and maintained in a separate document.
The general rule is to include definitions for any topics except technical, legal, or regulatory language.
The general rule of policy definitions is to include definitions for any instance of industry-specific, technical, legal, or regulatory language.
They should be created before any policy or standards.
30. Even the best-written policy will fail if which of the following is true?
The policy is too long.
The policy is mandated by the government.
The policy doesn’t have the support of management.
All of the above.
Exercises
EXERCISE 2.1: Creating Standards, Guidelines, and Procedures
The University System has a policy that states, “All students must comply with their campus attendance standard.”
You are tasked with developing a standard that documents the mandatory requirements (for example, how many classes can be missed without penalty). Include at least four requirements.
Create a guideline to help students adhere to the standard you created.
Create a procedure for requesting exemptions to the policy.
EXERCISE 2.2: Writing Policy Statements
Who would be the target audience for a policy related to campus elections?
Keeping in mind the target audience, compose a policy statement related to campus elections.
Compose an enforcement clause.
EXERCISE 2.3: Writing a Policy Introduction
Write an introduction to the policy you created in Exercise 2.2.
Generally an introduction is signed by an authority. Who would be the appropriate party to sign the introduction?
Write an exception clause.
EXERCISE 2.4: Writing Policy Definitions
The purpose of policy definitions is to clarify ambiguous terms. If you were writing a policy for an on-campus student audience, what criteria would you use to determine which terms should have definitions?
What are some examples of terms you would define?
EXERCISE 2.5: Understanding Baselines
The goal of this exercise is to understand what baselines are, why they are important, and the different types of baselines.
Read articles or watch tutorials on the importance of baselines in IT security.
Reflect on how baselines can contribute to uniformity and security in various IT environments.
Explore different tools and methodologies for baseline management across platforms such as Windows, Linux, and network devices.
Create a detailed security baseline for a chosen IT environment. Choose an IT environment that you are familiar with or interested in, such as Windows desktops, Linux servers, or network routers.
Document the standard configurations for the system.
Define appropriate security policies including password policies and security protocols. List approved software and version numbers. Outline procedures for regular updates and patches.
Compare your baseline with existing standards or best practices found in your research to evaluate its completeness and robustness.
Projects
PROJECT 2.1: Comparing Security Policy Templates
Search online for “cybersecurity policy templates.”
Read the documents and compare them.
Identify the policy components that were covered in this chapter.
Search for a real-world policy, such as Tufts University’s Two-factor Authentication Policy, at https://it.tufts.edu/univ-pol.
Choose a couple terms in the policy that are not defined in the policy definitions section and write a definition for each.
PROJECT 2.2: Researching New York City’s AI Bias Law
The objective of this project is to research the requirements, implications, and real-world application of New York City’s AI Bias Law in hiring practices and why it was failing after being enacted.
PART 1: Background Research
Goal: Gain a foundational understanding of the AI Bias Law and its objectives.
Research and read articles, official documents, and other credible sources detailing New York City’s AI Bias Law. Focus on understanding the definitions of Automated Employment Decision Tools (AEDTs) and the scope of the law.
Summarize the key elements of the law:
What are AEDTs?
What requirements does the law impose on employers using these tools?
What are the intended outcomes of the law?
PART 2: Exploring Implications and Challenges
Goal: Analyze the potential impacts of the law on employers and job seekers, and identify challenges in its implementation.
Consider the implications for employers in terms of compliance costs and changes to hiring practices. Reflect on how the law affects job seekers, especially those from marginalized groups.
Investigate any reported difficulties or controversies associated with implementing the law. Consider technical, legal, and ethical challenges.
Identify any criticisms or support from various stakeholders including businesses, advocacy groups, and legal experts.
Examine how companies have responded to the law and the real-world effectiveness of such regulations.
Choose one or more companies that have implemented measures to comply with the AI Bias Law. If specific company examples are scarce, consider hypothetical scenarios based on industry standards.
Analyze the steps these companies have taken to audit their AEDTs.
Evaluate the transparency of the published audit results and any actions taken based on those results.
Write a detailed report on your findings, highlighting effective practices and areas where companies may fall short in compliance.
PROJECT 2.3: Testing the Clarity of a Policy Document
Locate your school’s cybersecurity policy. (It may have a different name.)
Select a section of the policy and use the U.S. Army’s Clarity Index to evaluate the ease of reading. (See the “In Practice: U.S. Army Clarity Index” sidebar for instructions.)
Explain how you would make the policy more readable.
Reference
1. Baldwin, C., Plain Language and the Document Revolution. Lamplighter, 1999.
Regulations Cited
“Executive Order—Improving Government Regulations,” accessed April 2024, https://www.presidency.ucsb.edu/ws/?pid=30539.
“A History of Plain Language in the Government,” accessed April 2024, https://www.plainlanguage.gov/about/history/.
“Executive Order 13563—Improving Regulation and Regulatory Review,” accessed April 2024, https://obamawhitehouse.archives.gov/the-press-office/2011/01/18/executive-order-13563-improving-regulation-and-regulatory-review.
“Public Law 111-274—Oct. 13, 2010 [Plain Writing Act],” accessed April 2024, https://www.govinfo.gov/content/pkg/PLAW-111publ274/pdf/PLAW-111publ274.pdf.
Additional Reference
Krause, M., and H. F. Tipton. Information Security Management Handbook, 5th ed. CRC Press, 2004.