- Policies establish management’s intent;
- Control Objectives identify leading practices (mapped to requirements from laws, regulations and frameworks);
- Standards provide quantifiable requirements;
- Controls identify desired conditions that are expected to be met (requirements from laws, regulations and frameworks);
- Procedures / Control Activities establish how tasks are performed to meet the requirements established in standards and to meet controls; and
- Guidelines are recommended, but not mandatory.
Why Does Documentation Terminology Matter?
Cybersecurity, technology, privacy, and legal professionals routinely abuse the terms "policy" and "standard" as if they are synonymous. They are not, and they have very distinct differences.
Improper terminology usage has cascading effects that can negatively impact the internal controls of an organization. A multi-page "policy" document that blends high-level security concepts (policies), configuration requirements (standards), and work assignments (procedures) is an example of poor governance documentation that leads to confusion and inefficiencies.
Documentation needs to be usable. It cannot just exist in isolation as shelfware. This means cybersecurity documentation needs to be written clearly, concisely, and in business-context language. Clearly written documentation can be "half the battle" when preparing for an audit, since documentation is often the first impression an assessment team has. Not only does this put your organization in a positive light, it can also decrease audit-related expenses by minimizing back-and-forth communications.
When it comes to cybersecurity compliance, words have specific meanings. Getting those terms correct is essential because documentation terminology directly pertains to compliance efforts. A policy is NOT a standard, and a standard is NOT a procedure.
Getting Terminology Right
Yes. Technically, a policy is a control since a policy is merely an “administrative safeguard” and that meets the criteria of a control. A control is a “means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.”
Common Cybersecurity Documentation Components
ComplianceForge leverages a few key authoritative sources for cybersecurity documentation definitions:
- The NIST Computer Security Resource Center's Glossary;
- ISACA's Glossary;
- NIST framework-specific glossaries; and
- International Organization for Standardization (ISO) framework-specific glossaries.
Well-designed cybersecurity documentation is hierarchical and comprised of multiple parts, each serving a distinct purpose:
1. Policy
Policies are high-level statements of management intent from an organization’s executive leadership that are designed to influence decisions and guide the organization to achieve the desired outcomes:
- Policies exist to mitigate risks to the organization, including statutory, regulatory and contractual obligations.
- Policies are enforced by standards and further implemented by procedures to establish actionable and accountable requirements.
Unfortunately, for many IT/cybersecurity professionals, when they refer to a “policy” they really mean “standard.” This common misuse of critical documentation components can create a significant amount of confusion, since those are not interchangeable terms. Standards are subordinate to policies and standards address the granular requirements needed to satisfy a policy. Therefore, a 1-3 sentence policy statement is acceptable to capture a “high-level statement of management intent” for a specific domain.
- An organization is expected to have multiple policies to address cybersecurity and data privacy needs (e.g., access control, data handling, etc.).
- Policies address the strategic needs of the organization.
- There is never a justifiable reason to have an exception to a policy, since exceptions should only be at the standard or procedure level.
- A document that records a high-level principle or course of action that has been decided on.
- The intended purpose is to influence and guide both present and future decision making to be in line with the philosophy, objectives and strategic plans established by the enterprise’s management teams.
- Overall intention and direction as formally expressed by management.
- Any general statement of direction and purpose designed to promote the coordinated planning, practical acquisition, effective development, governance, security practices, or efficient use of information technology resources.
- Intention and direction of an organization as formally expressed by its top management.
- Statements, rules or assertions that specify the correct or expected behavior of an entity.
- A statement of objectives, rules, practices or regulations governing the activities of people within a certain context.
- Note 1: System elements include technology, machine, and human, elements.
- Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behavior of employees in performing their mission/business functions) or at very low levels (e.g., an operating system policy that defines acceptable behavior of executing processes and use of resources by those processes).
- Security policies define the objectives and constraints for the security program. Policies are created at several levels, ranging from organization or corporate policy to specific operational constraints (e.g., remote access). In general, policies provide answers to the questions “what” and “why” without dealing with “how.” Policies are normally stated in terms that are technology-independent.
- A set of rules that governs all aspects of security-relevant system and system element behavior.
2. Control Objective
Control Objectives are targets or desired conditions to be met.
- Control Objectives describing what is to be achieved as a result of the organization implementing a Control.
- A Standard applies organization-specific criteria to achieve a Control Objective.
Where applicable, Control Objectives are directly linked to laws, regulations and frameworks to align cybersecurity and data privacy with reasonably-expected practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny (e.g., external audits/assessments) to disprove potential accusations of negligence.
- A statement of the desired result or purpose to be achieved by implementing control procedures in a particular process.
- Statement describing what is to be achieved as a result of implementing controls.
3. Standard
Standards are mandatory requirements regarding processes, actions and/or configurations.
- Standards are intended to be granular and prescriptive to ensure systems, applications and services are designed and operated to include appropriate cybersecurity and data privacy protections.
- Standards are designed to satisfy Controls and Control Objectives.
- A mandatory requirement.
- Classification of components.
- Specification of materials, performance, or operations; or
- Delineation of procedures.
- A published statement on a topic specifying the characteristics, usually measurable, that must be satisfied or achieved to comply with the standard.
- A rule, condition, or requirement describing the following information for products, systems, services or practices:
4. Guidelines / Supplemental Guidance
Guidelines are recommended practices that are based on industry-recognized secure practices.
- Guidelines help augment Standards when discretion is permissible.
- Unlike Standards, Guidelines allow individuals / teams to apply discretion or leeway in interpretation, implementation, or use.
- A description of a particular way of accomplishing something that is less prescriptive than a procedure.
- Recommendations suggesting, but not requiring, practices that produce similar, but not identical, results.
- A documented recommendation of how an organization should implement something.
- Statements used to provide additional explanatory information for security controls or security control enhancements.
5. Control
Controls are technical, administrative or physical safeguards.
- Controls are the nexus used to manage risks through preventing, detecting or lessening the ability of a particular threat from negatively impacting business processes.
- Controls directly map to Standards, Procedures and Control Objectives.
- Control testing is designed to measure specific aspects of how Standards are actually implemented and if the Control / Control Objective is sufficiently addressed.
- The means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which can be of an administrative, technical, management, or legal nature.
- Controls include any process, policy, device, practice, or other actions which modify risk.
- Controls may not always exert the intended or assumed modifying effect.
- The policies, procedures, practices and organizational structures designed to provide reasonable assurance that business objectives will be achieved and undesired events will be prevented or detected and corrected.
- Measure that is modifying risk:
- Measure that is modifying risk. (Note: controls include any process, policy, device, practice, or other actions which modify risk.)
- The safeguards or countermeasures prescribed for an information system or an organization to protect the confidentiality, integrity, and availability of the system and its information [security control].
- The administrative, technical, and physical safeguards employed within an agency to ensure compliance with applicable privacy requirements and manage privacy risks [privacy control].
6. Assessment Objective
Assessment Objectives (AOs) are a set of determination statements that express the desired outcome for the assessment of a Control.
- AOs are the authoritative source of guidance for assessing Controls to generate evidence that can support an assertion that the underlying Control has been satisfied.
- All AOs associated with a control must be satisfied to legitimately conclude a Control is properly implemented.
- A set of determination statements that expresses the desired outcome for the assessment of a security control, privacy control, or control enhancement.
7. Procedure
Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard.
- Procedures help address the question of how the organization actually operationalizes a Policy, Standard or Control.
- Procedures are generally the responsibility of the process owner / asset custodian to build and maintain but are expected to include stakeholder oversight to ensure applicable compliance requirements are addressed.
- Without documented procedures, there is no defendable evidence of due care practices.
The result of a procedure is intended to satisfy a specific control. Procedures are also commonly referred to as “control activities.”
- A document containing a detailed description of the steps necessary to perform specific operations in conformance with applicable standards. Procedures are defined as part of processes.
- A detailed description of the steps necessary to perform specific operations in conformance with applicable standards.
- A group of instructions in a program designed to perform a specific set of operations.
- A set of instructions used to describe a process or procedure that performs an explicit operation or explicit reaction to a given event.
8. Risk
Risks represent a potential exposure to danger, harm or loss. Risk is associated with a control deficiency (e.g., If the control fails, what risk(s) is the organization exposed to?). Risk is often calculated by a formula of Threat x Vulnerability x Consequence in an attempt to quantify the potential magnitude of a risk instance occurring. While it is not possible to have a totally risk-free environment, it may be possible to manage risks by avoiding, reducing, transferring, or accepting the risks.
- The combination of the probability of an event and its consequence.
- The level of impact on organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation resulting from the operation of an information system given the potential impact of a threat and the likelihood of that threat occurring.
- The adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and
- The likelihood of occurrence.
- A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function of:
- The adverse impacts that would arise if the circumstance or event occurs; and
- The likelihood of occurrence. Information system-related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.
- A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of:
9. Threat
Threats represent a person or thing likely to cause damage or danger. Natural and man-made threats affect control execution (e.g., if the threat materializes, will the control function as expected?). Threats exist in the natural world that can be localized, regional or worldwide (e.g., tornados, earthquakes, solar flares, etc.). Threats can also be manmade (e.g., hacking, riots, theft, terrorism, war, etc.).
- Anything (e.g., object, substance, human) that is capable of acting against an asset in a manner that can result in harm.
- A potential cause of an unwanted incident.
- Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threatsource to successfully exploit a particular information system vulnerability.
- Cyberthreat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service.
10. Metric
Metrics provide a “point in time” view of specific, discrete measurements. However, trending and analytics that are derived by comparing a baseline of two or more measurements taken over a period of time. Analytics are generated from the analysis of metrics.
When people refer to "metrics" it is generally a misuse of the term, since the desired result is actually analytics. Analytics are designed to facilitate decision-making, evaluate performance and improve accountability through the collection, analysis and reporting of relevant performance related data. Good metrics are those that are SMART (Specific, Measurable, Attainable, Repeatable, and Time-dependent).
- A quantifiable entity that allows the measurement of the achievement of a process goal.
- A thing that is measured and reported to help with the management of processes, services, or activities.
- Tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data.
11. Secure Baseline Configuration / Hardening Standard
Secure baseline configurations (e.g., hardening standard) are technical in nature and specify the required configuration settings for a defined technology platform. Leading guidance on secure configurations tend to come from (1) Center for Internet Security (CIS) Benchmarks, (2) Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) and/or (3) Original Equipment Manufacturer (OEM) recommendations.
- A documented set of specifications for an information system, or a configuration item within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures.
- A set of specifications for a system, or Configuration Item (CI) within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures. The baseline configuration is used as a basis for future builds, releases, and/or changes.
12. Risk Register / Plan Of Action & Milestones (POA&M)
A POA&M is a “living document” that summarizes control deficiencies from identification through remediation. A POA&M is essentially a risk register that tracks the assignment of remediation efforts to individuals or teams, as well as identifying the tasks and resources necessary to perform the remediation.
- Risk Register: A repository of risk information including the data understood about risks over time.
- Risk Register: A central record of current risks, and related information, for a given scope or organization. Current risks are comprised of both accepted risks and risk that are have a planned mitigation path (e.g., risks to-be-eliminated as annotated in a POA&M).
- POA&M: A document that identifies tasks that need to be accomplished. It details resources required to accomplish
13. System Security Plan (SSP) / System Security & Privacy Plan (SSPP)
A SSP/SSPP is a “living document” that summarizes protection mechanisms for a system or project. It is a documentation method used to capture pertinent information in a condensed manner so that personnel can be quickly educated on the “who, what, when, where, how & why” concepts pertaining to the security of the system or project. A SSP/SSPP is meant to reference an organization’s existing policies, standards and procedures and is not a substitute for that documentation.
- Formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.
Side-by-Side Comparison
Understanding the differences between each documentation component is critical for building a defensible cybersecurity program:
How Do I Assign Control Ownership For Cybersecurity Controls & Procedures?
One of the most important things to keep in mind with procedures is that the "ownership" is different than that of policies and standards:
- Policies, standards and controls are designed to be centrally-managed at the corporate level (e.g., governance, risk & compliance team, CISO, etc.)
- Controls are assigned to stakeholders, based on applicable statutory, regulatory and contractual obligations
- Procedures are by their very nature de-centralized, where control implementation at the control level is defined to explain how the control is addressed.
Given this approach to how documentation is structured, based on "ownership" of the documentation components:
- Policies, standards and controls are expected to be published for anyone within the organization to have access to, since it applies organization-wide. This may be centrally-managed by a GRC/IRM platform or published as a PDF on a file share, since they are relatively static with infrequent changes.
- Procedures are "living documents" that require frequent updates based on changes to technologies and staffing. Procedures are often documented in "team share" repositories, such as a wiki, SharePoint page, workflow management tool, etc.
Below is an example of how documentation can be broken down from a law/regulation/framework to build documentation (e.g., policies, standards, guidelines, procedures, etc.):
If you visualize these concepts, you can see the hierarchical nature of documentation components, where policies are the foundation that everything builds upon. A poorly-architected document that blends policies, standards, and procedures into a single document creates confusion, is hard to maintain, and makes audit preparation unnecessarily expensive.
Hierarchical Cybersecurity Governance Framework (HCGF)
The HCGF is a documentation model that leverages industry-recognized terminology to logically arrange documentation components into their rightful order.
The HCGF creates an approach to architecting documentation that is concise, scalable, and comprehensive. When properly laid out, an organization's cybersecurity documentation should be hierarchical and linked from policies all the way through metrics. The "ComplianceForge Reference Model" is entirely based on industry-recognized best practices according to terminology definitions from NIST, ISO, ISACA, and AICPA.
If you visualize these concepts, you can see the hierarchical nature of documentation components, where policies are the foundation that everything builds upon. A poorly-architected document that blends policies, standards, and procedures into a single document creates confusion, is hard to maintain, and makes audit preparation unnecessarily expensive.
Common Documentation Pitfalls
Several patterns consistently lead to poor cybersecurity governance outcomes:
- Human nature defeats unclear documentation - people will not take the time to read excessively long documents. An ill-informed workforce entirely defeats the premise of having documentation.
- Excessively-wordy documentation is misguided for audits - paragraph after paragraph explaining concepts makes it very hard to identify exact requirements, leading to compliance gaps.
- Blending policies, standards, and procedures into a single document creates confusion and makes maintenance nearly impossible. Each should be a separate, clearly-scoped document.
- Documentation that only exists for audits - "shelfware" that is pulled out once a year defeats the purpose. Documentation must be usable day-to-day to guide actual operations.