In GRC operations, words have specific meanings. The concept of policies vs standards vs procedures is a common “word crimes” incident, since the terms are not interchangeable.
When it comes to cybersecurity GRC activities, words have specific meaning and it is important to get those terms correct. In reality, these cybersecurity documentation terms have quite different implications and those differences should be kept in mind since the use of improper terminology has cascading effects that can negatively impact the internal controls of an organization.
Cybersecurity & data protection documentation needs to be usable. It cannot just exist in isolation. This means the documentation needs to be written clearly, concisely and in a business-context language that users can understand. By doing so, users will be able to find the information they are looking for and that will lead to cybersecurity and data protection “industry-recognized secure practices” being implemented throughout your organization.
Additionally, having clearly-written and concise documentation can be “half the battle” when preparing for an audit or assessment, since it shows that effort went into the program and key requirements can be easily found.
Words have specific meanings.
If it is not documented, then it does not exist.
Avoid assumptions at all cost.
It is disappointing to have to say this, but just because you’ve seen something used in other organizations or because you found it on the Internet does not mean it is correct.
Words have specific meanings and your feelings do not matter. What matters is authoritative definitions of the terms. Cybersecurity, IT professionals, privacy and legal professionals routinely abuse the terms “policy” and “standard” as if these words were synonymous, when they are not! In simple terms, a policy is a high-level statement of management intent that formally establishes requirements to guide decisions and achieve rational outcomes. A policy is intended to come from the CEO or board of directors that has strategic implications. However, a standard is a formally-established requirement in regard to a process, action or configuration that is meant to be an objective, quantifiable expectation to be met (e.g., 8 character password, change passwords every 90 days, etc.).
On Policy Exceptions
In reality, no one should ever ask for an exception to a policy. Exceptions should only be for standards when there is a legitimate business reason or technical limitation that precludes a standard from being followed (e.g., vulnerability scanning exception for a “fragile” application that breaks when scanned by the default scanning profile). It is important that if a standard is granted an exception, there should be a compensating control placed to reduce that increased risk from the lack of the required standard (e.g., segment off the application that cannot be scanned for vulnerabilities).
Due to fact that terminology pertaining to cybersecurity documentation is often abused, a simplified concept of the hierarchical nature of cybersecurity documentation is needed to demonstrate the unique nature of these components, as well as the dependencies that exist. The reference model below was designed to encourage clear communication by defining cybersecurity documentation components and how those are linked. This model is based on industry-recognized terminology from NIST, ISO, ISACA and AICPA to address the inter-connectivity of policies, control objectives, standards, guidelines, controls, assessment objectives, risks, threats, procedures & metrics.
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 are enforced by standards and further implemented by procedures to establish actionable and accountable requirements. Policies are a business decision, not a technical one. Technology determines how policies are implemented. Policies usually exist to satisfy an external requirement (e.g., law, regulation and/or contract).
Control Objectives are targets or desired conditions to be met. These are statements describing what is to be achieved as a result of the organization implementing a control, which is what a Standard is intended to address. Where applicable, Control Objectives are directly linked to an industry-recognized secure practice to align cybersecurity and privacy with accepted practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny.
Standards are mandatory requirements regarding processes, actions and configurations. Standards are intended to be granular and prescriptive to ensure systems, applications and processes are designed and operated to include appropriate cybersecurity and privacy protections.
Guidelines are recommended practices that are based on industry-recognized secure practices. Guidelines help augment Standards when discretion is permissible. Unlike Standards, Guidelines allow users to apply discretion or leeway in their interpretation, implementation, or use.
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, since control testing is designed to measure specific aspects of how standards are actually implemented.
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. Without documented procedures, there can be no defendable evidence of due care practices. 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. The result of a procedure is intended to satisfy a specific control. Procedures are also commonly referred to as “control activities.”
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: Center for Internet Security (CIS) Benchmarks; Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs); and/or Original Equipment Manufacturer (OEM) recommendations.
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.
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.
Risk represents 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 × Vulnerability × 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.
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.).
Metrics provide a “point in time” view of specific, discrete measurements, unlike 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. 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).
Walking into an audit/assessment without appropriate evidence of due diligence and due care is a guaranteed way to fail. This goes back to the old adage, “If you fail to plan, then you plan to fail!” Without having evidence of your cybersecurity program, an honest assessor will be left with no recourse but to find all those associated controls deficient, since they cannot take your word for it. If it is not documented, then it doesn’t exist to an auditor/assessor.
Since you are on this website, you are clearly interested in complying with a cybersecurity law, regulation or framework. Every organization has a need to understand and clarify the difference between “compliant” versus “secure” since that is necessary to have coherent risk management discussions. To assist in this process, you can distill requirements into “must have” vs “nice to have” requirements:
Controls that represent the minimum bar required by external obligations: laws, regulations, and contracts. These are non-negotiable; not implementing them creates legal or contractual exposure.
Controls selected based on the organization's own risk appetite and judgment. These go beyond the minimum and represent best-practice enhancements driven by internal risk management.
The Bottom Line
Secure and compliant operations exist when both MCR and DSR are implemented and properly governed. When it comes to compliance, you have to take a holistic view of your requirements and implement a risk-based, prioritized approach to addressing those compliance obligations. Not doing so opens your organization up to negligence, which gets into dicey legal territory and possible insurance loopholes where you may void coverage for negligent behavior.
%20(white).png)
.png)