NIST, the CSF, CSA, and choosing a framework you can actually run

Why this matters

This lesson closes domain 1 and is its capstone: every earlier objective feeds into a framework, and the framework is what holds them together. Policies and standards implement it. The CMDB scopes it. GRC tooling tracks it. Risk assessment drives which parts matter. Threat modelling and attack surface tell you where it is thin. Compliance obligations constrain which one you may choose.

The exam distinction to get right is between the two kinds of framework that appear in this objective, because the names are similar and the uses are not. An outcome framework describes what good looks like and lets you decide how to achieve it. A control catalogue enumerates specific controls you select from. Choosing a catalogue when you needed an outcome framework produces an enormous implementation programme with no way to explain its value; choosing an outcome framework when a regulator required a catalogue produces a failed assessment.

The closing idea — adopt what you can operate — is the one CAS-005 rewards most consistently, and it is the same idea as lesson four's, applied to security frameworks rather than governance ones.

The lesson

The NIST Cybersecurity Framework functions and what an organisation does with them

The CSF organises security work into a small set of high-level functions, each broken into categories and subcategories. The functions are the part worth knowing cold, because they are how the framework is used in conversation:

• Govern — establishing and monitoring the organisation's cybersecurity risk management strategy, expectations and policy. This function was added to the framework's second version and is the connection to everything in this domain.
• Identify — understanding the assets, data, suppliers and risks. Lesson five lives here.
• Protect — the safeguards: access control, data security, awareness, maintenance, protective technology.
• Detect — finding events, which is most of domain 4.
• Respond — containment, analysis, communication, mitigation.
• Recover — restoration and improvement afterwards.

What an organisation actually does with them, in the order the framework intends:

1. Profile the current state. For each category, where are we now? This is the assessment, and its honesty determines everything downstream.
2. Profile the target state, driven by risk appetite, obligations and sector expectation rather than by an ambition to be uniformly excellent.
3. Compare, and treat the gaps as a prioritised programme, funded and owned.
4. Re-profile periodically, which converts the framework from an assessment into a management instrument.

Two properties make the CSF unusually useful for communication. It is outcome-based — subcategories describe results rather than mechanisms, so the same framework fits a cloud-native start-up and a manufacturer with industrial control systems. And it is tiered, describing how rigorous and integrated the risk management practice is, which lets an organisation say "we are deliberately at a lower tier in this area" as a decision rather than as a failure.

The board-reporting use from lesson three is where it pays off: a current and target profile across six functions is a picture an executive can act on, and it maps directly onto funding requests.

NIST SP 800-53 as a control catalogue versus the CSF as an outcome framework

This is the distinction the objective is built on.

SP 800-53 is a catalogue of security and privacy controls, organised into families — access control, audit and accountability, configuration management, identification and authentication, incident response, system and communications protection, and others. Each control has a statement, discussion, and enhancements, and controls are selected using baselines keyed to the impact level of the system. It is prescriptive, comprehensive, and large.

The CSF describes outcomes and references other documents — including 800-53 — for the controls that achieve them.

So they are complementary rather than alternatives, and the relationship is easy to state: the CSF tells you what outcomes to achieve and how to talk about them; the catalogue tells you which controls implement them.

Which to reach for:

A practical note that scenarios probe: a catalogue is sized for the system's impact level, and applying a high baseline to everything is a recognisable error. It is expensive, it dilutes attention, and it produces exceptions at scale — which brings back the exception register from lesson one, now with hundreds of entries nobody can review.

The Cloud Security Alliance CCM and where it fits alongside a general framework

The Cloud Controls Matrix is a control framework specific to cloud computing, organised into domains covering areas such as identity and access management, data security, interoperability, application security, and governance. Two features make it worth knowing.

First, it is mapped to other standards, so a control implemented and evidenced once can be shown against several regimes — the mapping work from lesson six, supplied rather than built.

Second, it distinguishes responsibility between customer and provider, which general frameworks handle poorly. That is its real contribution: a general catalogue says "encrypt data at rest" without saying who does it, and in a cloud estate that ambiguity is where controls fall down the gap. The CCM's shared responsibility framing forces the question, which is why it belongs in the same lesson as domain 2's shared responsibility model.

Alongside it, the associated consensus assessment questionnaire is a standardised set of questions aligned to the matrix, and the public registry of provider submissions means a supplier's answers may already exist. For third-party assessment this converts a bespoke questionnaire into a comparison against a known baseline — with the same caveat as every self-assessment in lesson eleven: it is a claim, and its scope must be read.

Where it fits: as a cloud-specific supplement to a general framework, not a replacement. An organisation with both cloud and on-premises estate uses a general framework as the spine and the CCM for the cloud portion, mapped so that the two do not become separate compliance programmes.

Framework selection driven by obligation, sector and maturity, with a worked comparison

Selection is a decision with three inputs and a defensible order.

Obligation first. If a regulator, a contract or a sector body names a framework, the decision is made. Selecting a different one because it is better does not discharge the obligation; the most you can do is map.

Sector expectation second. Where nothing is mandated, sector norms determine what customers and insurers will ask for. An organisation selling into enterprises will eventually be asked for a certification, and choosing the one your market recognises saves a second programme later.

Maturity and capacity third, and this is the one that decides between otherwise acceptable options.

A worked comparison for a mid-sized organisation with cloud and on-premises estate, no mandate, selling business-to-business:

The defensible answer is usually CSF for direction and reporting, a control catalogue or the CCM for specification, and certification only when the market requires it — because the first two cost effort proportional to the value taken, and the third costs a fixed and substantial amount regardless.

Adopting a subset deliberately and saying so, rather than claiming full adoption

The closing practice of domain 1, and it is the honest position rather than the modest one.

Full adoption of any substantial framework is a multi-year programme. Most organisations that claim it have documented it and operate a fraction, which is the worst outcome available: the cost of adoption, no capability gain, and reports that overstate the position to the people relying on them.

A deliberate subset looks different in four ways, and each is auditable:

• Scope is stated. Which parts of the framework are in scope, which are not, and why — with the exclusions justified by risk rather than by difficulty. This is exactly the form of a statement of applicability, and the discipline transfers even where you are not certifying.
• There is a roadmap. What comes into scope, when, and what it depends on. This turns an incomplete adoption into a plan.
• Reporting matches reality. The board sees coverage of the adopted subset, not a percentage computed over the whole framework, and sees what is excluded.
• The subset is chosen by risk. The functions and categories where your exposure is greatest come first, which is what the profile comparison earlier in this lesson produces.

An assessor, a customer and a regulator all respond better to this than to a claim of completeness they can disprove in an afternoon. And it closes the loop on the theme that has run through the whole domain: the value of governance is not in the documents produced but in the decisions they let somebody make and defend, and a claim nobody could defend is worse than a smaller claim that is true.