Cybersecurity Frameworks Compared Guide: NIST CSF, ISO 27001, CIS Controls and COBIT

Most organisations do not pick a cybersecurity framework, they inherit three or four of them from customers, auditors and regulators, and then run each one as a separate project. The frameworks are not competitors: NIST CSF 2.0 describes outcomes, ISO/IEC 27001:2022 certifies a management system, CIS Controls v8.1 prescribes prioritised technical safeguards, COBIT 2019 governs enterprise IT, and SP 800-53, SOC 2 and Cyber Essentials each answer a narrower question. This guide compares them side by side on purpose, structure, assurance model, effort and audience, explains the published crosswalks that connect them, and gives a method for choosing an anchor and layering the rest. It is written for CISOs, GRC leads and security architects deciding where to start or how to rationalise an existing programme. Each framework has its own deep guide on NHI Mgmt Group, linked rather than repeated here.

Key takeaways

• Frameworks answer different questions. CSF 2.0 asks what outcomes you need, ISO/IEC 27001 asks whether you run a working ISMS, CIS Controls asks which safeguards to deploy first, COBIT asks whether I&T is governed, and SOC 2 asks whether a service organisation's controls operated over a period.
• Only some can be certified or attested. ISO/IEC 27001 and Cyber Essentials lead to certificates for an organisation, SOC 2 leads to a CPA attestation report, while CSF, CIS Controls, COBIT and SP 800-53 (outside federal authorisation) are self-assessed frameworks.
• Pick one anchor, map the rest. Choose the framework that best fits your main external obligation as the spine of your control set, then map others to it using published references such as NIST's Informative Reference Catalog.
• Combinations are normal. A common pattern is CSF 2.0 for board reporting, ISO/IEC 27001 for the management system and certificate, CIS Controls or SP 800-53 for technical depth, and SOC 2 for customer assurance.
• Identity carries weight in every one. PR.AA in CSF, A.5.15 to A.5.18 and A.8.5 in ISO/IEC 27001, CIS Controls 5 and 6, AC and IA in SP 800-53 and CC6 in SOC 2 all reach service accounts, API keys and other non-human identities.

The frameworks at a glance

Versions are those current at the date of this guide. For the latest version status of each standard, see our Security Standards Tracker.

For depth on each, see the NIST CSF 2.0 Guide, the ISO 27001 Certification Guide, the CIS Controls Guide, the COBIT 2019 Guide, the NIST SP 800-53 Guide, the SOC 2 Guide and the Cyber Essentials Guide.

Outcome, management system, control catalogue or governance model

The most useful way to compare frameworks is by the kind of document each one is. Mixing them up, for example treating ISO/IEC 27001 Annex A as the whole standard, wastes effort.

• Outcome frameworks (CSF 2.0): state what good looks like without saying how. A Subcategory such as PR.AA-01 says identities and credentials are managed; it does not specify a password length or a tool. You choose controls from elsewhere to achieve the outcome, and NIST links those sources through Informative References.
• Management system standards (ISO/IEC 27001): specify how the organisation runs security: context, leadership, risk assessment and treatment, internal audit, management review and continual improvement. Annex A controls are selected through risk treatment and justified in the Statement of Applicability. An auditor tests the system as much as the controls.
• Prescriptive control sets (CIS Controls, Cyber Essentials, SP 800-53): say what to deploy. CIS orders Safeguards so that IG1, which CIS calls essential cyber hygiene, is done first. Cyber Essentials is narrower still: five controls with set technical requirements. SP 800-53 is the deepest catalogue, with parameters to fill in and baselines to tailor.
• Governance frameworks (COBIT 2019): cover the whole of enterprise I&T, of which security is one part. Security sits mainly in APO13 Managed Security, DSS05 Managed Security Services and DSS06 Managed Business Process Controls, governed through EDM03 Ensured Risk Optimisation. COBIT expects detailed controls to come from standards like ISO/IEC 27001 or SP 800-53.
• Assurance schemes (SOC 2, ISO certification, Cyber Essentials): are about proving something to a third party. SOC 2 is a report on your own description and controls; it is not a framework you design a programme around, but its criteria shape what evidence you keep.

Assurance, effort and cost compared

Effort depends on scope, existing maturity and the number of systems in scope, so the table gives relative indications rather than figures. The only published price used here is the NCSC's own: Cyber Essentials starts at £320 plus VAT, priced by organisation size.

Other frameworks you will meet

Several further frameworks sit beside or on top of the seven above. They are usually layered onto an existing anchor rather than adopted as one.

• NCSC Cyber Assessment Framework (CAF): outcome-based, used by UK regulators for operators of essential services. See the NCSC Cyber Assessment Framework (CAF) Guide.
• PCI DSS 4.0.1: mandatory for entities that store, process or transmit cardholder data, assessed by a QSA or through a self-assessment questionnaire. See the PCI DSS 4.0 Guide.
• CSA Cloud Controls Matrix and STAR: 197 control objectives in 17 domains aimed at cloud providers and customers. See the Cloud Security Alliance CCM and STAR Guide.
• NIST SP 800-171 and CMMC 2.0: for US defence supply chains handling controlled unclassified information. See the NIST SP 800-171 and CMMC 2.0 Guide.
• AI frameworks: ISO/IEC 42001 certifies an AI management system on the same harmonised clause structure as ISO/IEC 27001, while the NIST AI RMF is outcome-based like CSF. See the ISO/IEC 42001 Guide and the NIST AI RMF Guide.
• Laws that reference frameworks: NIS2 and DORA set obligations but do not mandate a single framework; most organisations evidence them through an ISO/IEC 27001 or CSF based programme. See the Regulations and Frameworks Guide.

Crosswalks: how the frameworks connect

You do not need to build mappings from nothing. The main publishers maintain crosswalks, but each one is a claim made by its author and should be reviewed before an auditor relies on it.

• NIST OLIR and the Informative Reference Catalog: the National Online Informative References programme lets subject matter experts submit standardised mappings between their documents and NIST focal documents such as CSF and SP 800-53 Rev. 5. The catalogue also holds Derived Relationship Mappings, which link two non-NIST documents through a shared focal document. NIST IR 8278 Rev. 1 explains the method.
• CSF 2.0 Informative References: NIST lists mappings from CSF 2.0 to SP 800-53 Rev. 5, ISO/IEC 27001:2022, CIS Controls v8.1, PCI DSS 4.0.1 and the CSA CCM, browsable through the CSF 2.0 resources. NIST does not verify the correctness of mappings written by others.
• CIS mappings: CIS publishes mappings from the Controls to other frameworks, and v8.1 specifically realigned its CSF mappings to CSF 2.0 and added the Govern security function.
• COBIT focus area for CSF: ISACA publishes a COBIT 2019 focus area guide on implementing the NIST Cybersecurity Framework, which places CSF inside a COBIT governance system.
• ISO/IEC 27002 attributes: each 27002:2022 control carries attributes including cybersecurity concepts (Identify, Protect, Detect, Respond, Recover) that line up with the CSF Functions, which makes ISO to CSF mapping easier than it was under the 2013 edition.

The table shows how one topic, identity and access management, appears across frameworks. It illustrates how mappings work; it is not a verified one to one equivalence.

For the full mapping method, including relationship types such as subset, intersects and equal, see the Control Mapping Guide and the NIST CSF to ISO 27001 Mapping Guide.

How to choose: decision guidance

Start from the obligation that has the hardest consequence if you miss it, not from the framework you know best.

• Small versus large: for small organisations a full ISO/IEC 27001 ISMS or COBIT governance system is often more process than the risk justifies until a customer asks for it; CIS IG1 or Cyber Essentials gives fast, testable protection. Large and regulated organisations usually need a management system and a control catalogue, plus several attestations.
• Certificate versus capability: a certificate proves a process to outsiders; a prescriptive control set improves technical defence.
• Outcomes versus controls for reporting: boards respond better to CSF Functions and Profiles than to control percentages. Keep the control catalogue for engineers and auditors, and roll it up to CSF for reporting.

Combining frameworks: a phased approach

1. Inventory obligations: list every contract clause, regulation, customer questionnaire and insurer requirement that names a framework, with the consequence of non-compliance. Record it in a register. See the Risk Register Template.
2. Choose the anchor: use the decision table. Write down why, because auditors and new CISOs will ask.
3. Build a CSF 2.0 Current Profile: even if CSF is not your anchor, a Subcategory-level current state is the cheapest way to see gaps across all six Functions, including Govern.
4. Define a common control set: one catalogue of your own controls, each mapped to the anchor and to every other framework in scope, with owners, evidence and test frequency. Start from published Informative References and review each row.
5. Pilot on one scope: run one business unit or product through the common control set and one assessment (an internal audit against ISO/IEC 27001 clauses, or a SOC 2 readiness review) before rolling out further. Expect mapping corrections.
6. Add assurance in order of value: typically Cyber Essentials or CIS IG1 baseline first, then ISO/IEC 27001 certification or SOC 2 Type 1, then Type 2 or surveillance cycles.
7. Roll back without losing evidence: if a framework is dropped (for example a customer contract ends), retire its mappings and reports but keep the underlying controls and evidence, since another framework almost always still uses them.
8. Review on framework change: CSF 2.0, ISO/IEC 27001:2022, CIS v8.1 and SP 800-53 Release 5.2.0 all changed within the last few years; schedule a mapping review whenever a publisher issues a new version.

Tooling helps once the method is settled. See the Compliance Automation Guide and the GRC Platform Buyer's Guide.

Where identity fits

Every framework treats identity as a core control area, and most auditors now sample machine accounts as well as staff accounts. CSF 2.0 PR.AA explicitly covers identities and credentials for users, services and hardware. A common control set should therefore define one identity lifecycle control, one privileged access control and one secrets and credential rotation control that cover service accounts, API keys, OAuth applications and AI agents, mapped once to PR.AA, ISO/IEC 27001 A.5.16 to A.5.18 and A.8.2, CIS Controls 5 and 6, SP 800-53 AC-2 and AC-6, and SOC 2 CC6. See the Identity Security Programme Guide.

Measuring the programme

• Control reuse ratio: number of framework requirements satisfied divided by number of internal controls. A rising ratio shows the common control set is working.
• Profile gap closure: number of CSF Subcategories where the Current Profile meets the Target Profile, tracked each quarter.
• Audit findings per cycle: major and minor nonconformities (ISO), exceptions (SOC 2) and failed CE Plus tests, trended year on year.
• Evidence freshness: percentage of controls with evidence inside its test frequency, ideally collected automatically. See the Audit Evidence and Continuous Controls Monitoring Guide.
• Duplicate effort removed: count of overlapping questionnaires, audits or evidence requests answered from the common control set rather than from scratch.
• Mapping currency: number of frameworks in scope whose mapping matches the publisher's current version.

Framework mapping for running the programme itself

The work of selecting, combining and governing frameworks is itself covered by controls in the frameworks. These IDs were checked against the official NIST datasets.

Common failure patterns

• One project per framework: separate teams run ISO, SOC 2 and CSF with separate evidence, so the same access review is performed three times with three different populations. Fix it with a common control set.
• Certificate mistaken for security: a narrow ISMS scope or a carved-out SOC 2 system boundary produces a valid certificate for a fraction of the estate. Read the scope statement before relying on anyone's certificate, including your own.
• Governance on paper, configuration in the cloud: policies and risk registers exist, but nobody tests that cloud roles follow least privilege. The Capital One breach turned on an over-permissioned role attached to a misconfigured web application firewall, and the OCC fined the bank $80 million in 2020 over weaknesses in its cloud risk management.
• Trusting mappings blindly: published crosswalks are claims by their authors, and "intersects" is not "equal". Auditors reject evidence mapped on a weak relationship.
• Scoring CSF Tiers as a target: chasing Tier 4 everywhere wastes money. Tiers describe rigour, and leadership should choose them per risk.
• Stale versions: mappings still pointing to ISO/IEC 27001:2013 control numbers or CSF 1.1 Categories after the publishers moved on.

Practitioner checklist

• List every external obligation that names a framework, with owner and consequence.
• Choose and document one anchor framework and the reason for it.
• Build a CSF 2.0 Current Profile and a Target Profile signed off by leadership.
• Create one common control set with owners, evidence and test frequencies, mapped to every framework in scope.
• Start mappings from NIST Informative References and CIS mappings, and review every row with a stated relationship type.
• Define single identity, privileged access and credential rotation controls that explicitly include non-human identities.
• Check the scope statement of every certificate and SOC 2 report you issue or rely on.
• Track control reuse ratio, profile gap closure, audit findings and evidence freshness quarterly.
• Schedule a mapping review whenever a framework publisher releases a new version.

Standards and references

• NIST: Cybersecurity Framework 2.0
• ISO: ISO/IEC 27001:2022 Information security management systems, Requirements
• CIS: CIS Critical Security Controls v8.1
• ISACA: COBIT
• NIST: SP 800-53 Rev. 5
• NIST: National Online Informative References (OLIR) Program
• NCSC: Cyber Essentials overview
• AICPA: SOC 2

Related NHI Mgmt Group resources: Control Mapping Guide · NIST CSF to ISO 27001 Mapping Guide · Regulations and Frameworks Guide · Shared Responsibility Models Guide · GRC Maturity Model