Security Governance: Laws, Frameworks, Policies, Standards, Procedures

Governance answers a simple question: who decides what the organization must do about security, and how do those decisions reach the people doing the work? The answer is a hierarchy. External requirements sit at the top, organizational documents sit below them, and each layer becomes more specific as you move down.

The layers, from top to bottom, are:

• Regulations and laws: mandatory rules created by governments and regulators, enforced with penalties.
• Contractual requirements: industry standards such as PCI DSS that become binding when an organization signs an agreement, enforced by the other party to the contract.
• Frameworks: voluntary collections of best practices, such as the NIST Cybersecurity Framework or ISO/IEC 27001, that organizations choose to adopt.
• Policies: high-level, mandatory statements of management intent inside the organization.
• Standards: specific, mandatory requirements that give policies measurable teeth.
• Procedures: mandatory step-by-step instructions for performing a task.
• Guidelines: recommended, optional advice that helps people follow the layers above.

Two facts anchor everything else in this lesson. First, laws come from outside the organization and are never optional, contractual requirements bind whoever signed the contract, and frameworks are adopted by choice. Second, of the four internal document types, three are mandatory once approved: policy, standard, and procedure. Only the guideline is a recommendation. If you remember nothing else, remember which layer is external, which layers are chosen, and which single document type is optional. Nearly every CC governance question is a variation on one of those distinctions.

Laws and regulations are mandatory rules created by governments and regulatory bodies. They apply to an organization whether it likes them or not, and they carry legal consequences for noncompliance: fines from a regulator, sanctions, loss of licenses, and in some cases criminal liability. You do not adopt a law; you are subject to it. When a requirement comes from a government and is enforced by a government body, it is a law or regulation, not a framework and not a policy.

The CC exam expects recognition-level knowledge of two named examples, and in particular of what brings an organization under each one. You are not expected to know individual articles or rules.

GDPR, the European Union General Data Protection Regulation, protects the personal data of people who are in the EU. It applies in two ways. First, it applies to any organization established in the EU that processes personal data. Second, under its territorial-scope rule (Article 3(2)), it reaches an organization with no EU presence at all when that organization processes personal data of people in the EU in order to offer them goods or services, paid or free, or to monitor their behaviour while they are in the EU, for example by tracking or profiling them online. The trigger is the person being in the EU, not their citizenship: an EU citizen living in the United States and dealing with a US company is not, by that fact alone, covered, while a non-EU visitor being tracked while in the EU can be. Having offices, staff or servers in the EU is not required for the second route.

HIPAA, the United States Health Insurance Portability and Accountability Act, protects health information, but only health information held by particular kinds of organization. It applies to covered entities, which are health plans, healthcare clearinghouses and healthcare providers that conduct standard transactions such as insurance claims electronically, and to their business associates, the vendors that create, receive, store or transmit protected health information on a covered entity's behalf. Health data alone does not trigger HIPAA. A consumer fitness or health app that is not acting for a covered entity, an employer holding sick notes in its employment records, and a life insurer are all outside HIPAA even though they hold health-related information; other laws may apply to them instead. HIPAA is enforced by the US Department of Health and Human Services through its Office for Civil Rights, which can impose civil money penalties.

A framework is an organized collection of security practices, published by a standards body or industry group, that an organization can voluntarily adopt to structure its security program. Frameworks answer the question of where to start and what a complete program looks like. Unlike laws, no government forces a framework on a private organization; unlike internal policies, a framework is written by someone outside your organization.

The NIST Cybersecurity Framework (CSF), published by the US National Institute of Standards and Technology, is a voluntary, risk-based framework for understanding, managing and reducing cybersecurity risk. It is free to use and widely adopted far beyond the United States. Version 2.0, released in 2024, organizes outcomes into six functions:

• Govern: establish and monitor the organization's cybersecurity risk management strategy, expectations and policy.
• Identify: understand current cybersecurity risks, including assets.
• Protect: use safeguards to manage those risks.
• Detect: find and analyze possible attacks and compromises.
• Respond: take action on a detected incident.
• Recover: restore assets and operations affected by an incident.

Govern is the function added in 2.0, and it sits at the centre of the other five. It holds organizational context, the risk management strategy, roles, responsibilities and authorities, policy, oversight, and cybersecurity supply chain risk management (category GV.SC), which covers identifying, assessing and managing risk from suppliers and other third parties: supply chain risk strategy, supplier due diligence, and security requirements written into supplier contracts. In CSF 1.1 supply chain risk management sat under Identify (ID.SC); in 2.0 it moved to Govern. The CSF has no official certification: an organization can align with it and describe its maturity against it, but nobody issues a "NIST CSF certificate".

The ISO/IEC 27000 family is a set of international standards for information security. Two members are easy to confuse:

Of the frameworks in this lesson, only ISO/IEC 27001 offers an accredited third-party certificate; aligning with the NIST CSF or following ISO/IEC 27002 guidance is something an organization can claim, not something an auditor can certify.

Voluntary does not mean consequence-free. A contract may require a supplier to hold ISO/IEC 27001 certification, and a regulator may treat a recognized framework as evidence of due care. But if an organization simply chooses a framework and then departs from it, no outside body fines it for that: the consequences are internal, such as audit findings, management action and higher risk. The obligation to follow the framework comes from the organization's own decision to adopt it, which is the subject of the standards section below.

Not every mandatory external requirement is a law. PCI DSS, the Payment Card Industry Data Security Standard, is an industry standard published by the PCI Security Standards Council, a body founded by the major payment card brands. It is not a law passed by a government. A merchant or service provider becomes bound by it through contract: the merchant agreement with its acquiring bank or payment processor, which in turn follows the card brands' rules. For an organization that accepts card payments, PCI DSS is therefore mandatory by contract, and it is enforced by the contracting parties, which can impose fines, raise fees or stop the organization from processing cards.

An organization usually faces all three kinds of obligation at once, and the exam often asks which one carries outside penalties. Ask where the obligation comes from and who enforces it:

A single organization can sit in every row. Picture a streaming-subscription company based in Canada that bills customers by card, tracks viewing behaviour of subscribers in the EU, and shapes its security program on ISO/IEC 27002 guidance. GDPR reaches it because it monitors the behaviour of people in the EU, even with no EU establishment (a law, enforced by EU data protection authorities). PCI DSS binds it through its merchant agreement (a contract, enforced by its acquirer and the card brands). ISO/IEC 27002 binds it only internally, because it chose to follow it. To find who can penalize an organization, trace each requirement back to its source: a legislature, a counterparty, or the organization itself. In a few places the lines blur (some US states reference PCI DSS in statute, for example), but the general rule holds.

A policy is a formal, high-level document, approved by senior management, that states what the organization requires and why. Policies express management intent: they set direction, assign broad responsibility, and declare rules that everyone in scope must follow. Once approved, a policy is mandatory for the organization. That word, mandatory, is essential, because learners often assume that anything high-level must be merely advisory. It is not. A policy is short on detail but full of authority.

That authority comes from senior management approval. A policy is binding because the organization's leadership has approved it on the organization's behalf, not because each employee has signed or acknowledged it, and not because a regulator has approved it. Acknowledgment forms are useful evidence that staff were told about a policy, and a policy is often written to meet a legal requirement, but an employee who never signed the acknowledgment is still required to follow an approved policy, and a regulator does not need to bless an internal policy for it to apply.

Because policies sit at the top of the internal document stack, they are deliberately written to be stable and technology-neutral. A data protection policy might state that all sensitive corporate data must be protected against unauthorized access and disclosure. Notice what it does not say: which encryption algorithm to use, which products to buy, or which settings to configure. Those details change often, and if they lived in the policy, management would have to re-approve the document every time a product version changed. Instead the details are pushed down into standards and procedures.

Common examples include an acceptable use policy, which defines how employees may use organizational systems, a data classification policy, and an access control policy. On the exam, the trigger phrases for a policy are high-level, management intent, broad rules, and mandatory. If a scenario describes a document that tells everyone what must be achieved without saying exactly how, you are looking at a policy.

A standard translates the broad intent of a policy into specific, measurable, mandatory requirements. Where the policy says sensitive data must be protected, the standard says exactly what that means in practice: for example, that all company laptops must use AES-256 full disk encryption, or that passwords must be at least twelve characters long. A standard creates uniformity. When everyone builds systems to the same standard, the organization gets consistent, auditable security instead of each team inventing its own interpretation of the policy.

The word standard also appears in an external sense, and the CC exam expects you to recognize both uses. External standards are published by recognized bodies: ISO and IEC publish the ISO/IEC 27000 family, NIST publishes standards and special publications such as SP 800-63B on digital identity and passwords, and the Center for Internet Security (CIS), a nonprofit, publishes two different things that are easy to mix up:

Voluntary to adopt, mandatory once adopted. No outside body requires a private organization to use ISO/IEC 27001 controls, CIS Benchmarks or NIST SP 800-63B. But once the organization writes one of them into its own policy or standards, for example a policy stating that passwords must meet SP 800-63B, or a hardening standard requiring the CIS Benchmark for every server, those requirements become the organization's own mandatory internal standard. The voluntary nature of the framework stops mattering at that point: the obligation now comes from management's adoption, not from the publisher. External certification such as ISO/IEC 27001 is assurance that the adopted requirements are being met; it is not the source of the obligation, and a team is bound by the adopted standard whether or not a certificate exists.

Keep the relationship straight: the policy states the goal, the standard states the specific requirement that satisfies the goal, and both are mandatory. The difference between them is not whether you must comply. It is the level of detail. A document full of specific required values, settings, or thresholds is a standard, even if it never uses the word.

A procedure is a detailed, step-by-step set of instructions for completing a specific task. It is the most granular document in the hierarchy and the one closest to the person doing the work. Where a policy says what must happen and a standard says what specific requirement applies, the procedure says exactly how to do it: step one, step two, step three, in order, often naming the exact system, screen, or command involved.

Procedures matter for two reasons. First, repeatability: when the help desk follows the same password reset procedure every time, the task is performed consistently and securely regardless of who performs it. Second, accountability: a documented procedure lets an organization verify that a task was done correctly and train new staff quickly. Typical examples include the procedure for provisioning a new user account, the procedure for responding to a suspected phishing email, and the procedure for backing up and restoring a server.

Procedures are mandatory. Once management approves a procedure, employees are required to follow it, just as they are required to follow policies and standards. This surprises many candidates, who assume detailed how-to documents are optional aids. They are not; the optional document is the guideline, covered next. On the exam, the trigger phrase for a procedure is step-by-step. A scenario that mentions a numbered sequence of actions, a checklist that must be followed in order, or detailed how-to instructions is pointing at a procedure.

A guideline is a recommendation. It offers useful advice, suggested practices, or flexible approaches that help people comply with policies and standards, but it does not itself impose a requirement. A guideline might suggest ways to create a memorable passphrase, or recommend an approach for evaluating a new cloud service. Following a guideline is encouraged; departing from it is allowed when circumstances justify it. Among the four internal governance documents, the guideline is the only one that is optional, and that single fact is one of the most reliably tested points in the entire CC syllabus.

Read the table down the mandatory column and the detail column. Compliance separates the guideline from everything else; detail separates the policy from the standard and the standard from the procedure. Every classification question about these documents can be answered with those two dimensions.

Follow a single requirement from the top of the hierarchy to the bottom. As a US healthcare provider that bills insurers electronically, the hospital is a HIPAA covered entity, so HIPAA applies: an external, mandatory law that requires the hospital to protect the privacy and security of health information. The hospital cannot decline this obligation.

To organize its response, the hospital voluntarily adopts the NIST Cybersecurity Framework as the structure for its security program and uses ISO/IEC 27001 practices to shape its management system. Nobody forced these choices; the frameworks simply give the hospital a proven blueprint. Management then approves an access control policy stating that access to patient records is granted only to staff who need it for their duties. That policy is now mandatory inside the hospital. A supporting standard specifies exactly what the policy requires in practice: unique user accounts for every staff member, multifactor authentication for remote access, and a minimum password length. A procedure gives the help desk the exact numbered steps for verifying a caller and resetting a password. Finally, a guideline suggests tips for choosing a strong passphrase, which staff are encouraged, but not required, to follow.

Notice how each layer answers a different question. The law says the hospital must protect the data. The framework says how to organize the effort. The policy says what management requires. The standard says precisely what compliant looks like. The procedure says how to do the task. The guideline offers helpful, optional advice. When an exam scenario hands you a document, ask which of those questions it answers, and the classification follows.