Mapping controls to frameworks without drowning in them

Every security programme I've walked into has the spreadsheet. Hundreds of rows, a column per framework, and a colour scheme nobody remembers agreeing to. It maps NIST to ISO to CIS to the internal policy, and it's always slightly out of date. Mapping itself is useful. The problem is that the mapping has become the work, instead of a by-product of it.

The way out is to stop treating frameworks as competing checklists and notice that each one answers a different question. Put them in the right order and they stop overlapping and start connecting.

Each framework answers a different question

SABSA — why does the business need this?

SABSA (Sherwood Applied Business Security Architecture) describes itself as a methodology for "business-driven, risk and opportunity focused" security architecture. Its central idea is that security requirements are derived from the business, captured as business attributes — available, confidential, auditable, compliant — each with an agreed definition and a way to measure it. Its layered model runs from the contextual, business view down through conceptual, logical, physical and component layers. Its signature property is two-way traceability: every control traces up to a business reason, and every business requirement traces down to whatever satisfies it. I go deeper in SABSA as the foundation.

NIST CSF 2.0 — what outcomes should we achieve?

The NIST Cybersecurity Framework describes outcomes rather than prescribing methods. Version 2.0, released in February 2024, organises them into six Functions: Govern, Identify, Protect, Detect, Respond and Recover. Govern is new, and it matters: NIST frames cybersecurity as a major source of enterprise risk that senior leaders should weigh alongside finance and reputation. 2.0 also widened the audience explicitly to organisations of every size and sector, not just critical infrastructure. CSF is the language I use with boards, because it says what good looks like without dictating how.

NIST SP 800-53 — which controls, specifically?

Where CSF describes outcomes, SP 800-53 Rev. 5 is the catalogue: 20 control families, from Access Control (AC) to Supply Chain Risk Management (SR), including privacy families such as PII Processing and Transparency. It is actively maintained — release 5.2.0 in August 2025 added new controls and revised existing ones. Nobody implements 800-53 end to end. You select from it, and the SP 800-53B baselines exist to help you do exactly that.

CIS Controls v8.1 — where do we start?

The CIS Controls are prioritised and practical: 18 Controls broken into 153 Safeguards, grouped into three Implementation Groups. IG1 — 56 Safeguards that CIS calls "essential cyber hygiene" — is the most honest starting point I know for an organisation without a mature programme. Version 8.1 realigned its mappings to NIST CSF 2.0, which is precisely the kind of maintained cross-reference you should reuse rather than rebuild.

Risk — which of this actually matters here?

Frameworks don't know your threats. Risk is what turns a catalogue into a selection. NIST defines risk as a measure of the extent to which an entity is threatened by a potential circumstance or event — typically a function of the adverse impact if it happens and the likelihood that it will. The NIST Risk Management Framework makes the link explicit: its Select step is to choose SP 800-53 controls "based on risk assessment(s)".

One spine, many lenses

Put those questions in order and you get a single chain instead of five parallel lists:

1. Business attributes (SABSA). Agree with the business what the system must be — "customer data stays confidential", "payments are auditable", "the service is available during trading hours" — and how each is measured. It's the only step that needs the business in the room, and the one most often skipped.
2. Risks to those attributes. What could undermine each one, how likely, how bad. This is where your threat model lives.
3. Outcomes (CSF 2.0). Express what you need in CSF terms, so governance, audit and the board share one vocabulary.
4. Controls (SP 800-53 or CIS). Select controls to treat the risks — 800-53 where you need depth and formal assurance, CIS from IG1 upwards where you need a prioritised, achievable baseline.
5. Evidence. For every control, what proves it is working — a configuration, a log, a test result — collected automatically wherever you can.

Each link in the chain points both ways. That is SABSA's traceability doing the heavy lifting: an auditor can start at a control and walk up to the business reason for it; an executive can start at "customer data stays confidential" and walk down to the evidence.

Where mapping efforts drown

A few patterns come up again and again:

• The mapping becomes the deliverable. Months spent reconciling one framework to another, with neither connected to the business. Map to your own attributes and risks first; cross-framework mapping then falls out almost for free.
• Hand-rolled cross-references. Frameworks move — CSF 2.0 added Govern, CIS realigned to it, 800-53 keeps issuing releases. Reuse published mappings where they exist and keep your own additions small.
• Catalogue thinking. Treating 800-53 as a to-do list rather than a menu. Baselines and the RMF exist precisely so you select, tailor and justify instead of implementing everything.
• Evidence as an annual event. If proof is gathered by hand the month before the audit, your mapping describes a system that existed for a few weeks a year.

Why it's worth the effort

Done this way, the framework stack stops being overhead. The board sees outcomes it understands. Engineers see a short list of controls, each with a reason attached. Auditors get evidence that traces to requirements. And when a new regulation or framework version arrives, you map it once — to the attributes and risks you already hold — instead of starting another spreadsheet.

---

Frameworks are lenses, not destinations. Pick one spine — business attributes, then risk, then outcomes, then controls, then evidence — and let every framework hang off it. You'll write less, prove more, and never again have to explain what the orange cells mean.

Sources

• SABSA executive summary — The SABSA Institute
• NIST releases Cybersecurity Framework 2.0 — NIST, February 2024
• SP 800-53 Rev. 5, Security and Privacy Controls — NIST
• CIS Controls Implementation Groups and CIS Controls v8.1 — Center for Internet Security
• About the Risk Management Framework — NIST
• Glossary: risk (from SP 800-30 Rev. 1) — NIST