Security frameworks provide structure, but the right choice depends on your specific context. A framework is not a certificate you buy; it is an operating discipline you commit to. The organisations that struggle with this decision usually aren't confused about the frameworks themselves — they're confused about what problem they're actually trying to solve: a sales requirement, a regulatory obligation, an insurance condition, or a genuine need to reduce risk.
Most mid-sized organisations should anchor on NIST CSF 2.0 as a risk-management structure, use the CIS Controls (starting at Implementation Group 1) as a prioritised technical baseline, and pursue ISO/IEC 27001 certification or a SOC 2 report only when a customer, regulator, or insurer actually requires third-party attestation. In the EU, entities in scope of NIS2 have a legal floor of measures under Article 21 regardless of which voluntary framework they layer on top. Pick one primary framework, map the others to it, and resist running parallel, uncoordinated compliance programmes.
Key Takeaways
- Frameworks solve different problems. NIST CSF is a risk-management taxonomy, ISO 27001 is a certifiable management system, CIS Controls is a prioritised technical checklist, and SOC 2 is a service-provider trust report. Comparing them as if they compete head-to-head is the wrong frame.
- Regulation sets a floor, not a ceiling. In the EU, NIS2 defines mandatory minimum measures for essential and important entities; a voluntary framework like ISO 27001 or NIST CSF is how you operationalise and evidence that floor, not a substitute for it.
- Start with the smallest defensible scope. CIS Controls' Implementation Group 1 (IG1) is explicitly designed as the baseline "every organisation should implement" before layering on more advanced controls.
- Certification is a business decision, not just a security one. ISO 27001 and SOC 2 exist primarily to satisfy a third party (customer, partner, regulator). If nobody outside your organisation is asking for the attestation, the ongoing audit cost may not be justified yet.
- One framework should be primary. Running NIST CSF, ISO 27001, CIS Controls, and SOC 2 as separate, uncoordinated programmes multiplies audit fatigue without multiplying security. Map secondary frameworks onto your primary one instead of tracking them independently.
- For Azure-hosted environments, Microsoft's own Cloud Security Benchmark cross-maps a single set of Azure controls to NIST CSF, CIS Controls, ISO 27001, SOC 2, and PCI-DSS simultaneously — a practical way to avoid re-implementing near-identical controls once per framework.
What Do These Frameworks Actually Cover?
NIST Cybersecurity Framework (CSF) 2.0
The NIST Cybersecurity Framework, published by the U.S. National Institute of Standards and Technology, organises cybersecurity activity into a small number of high-level functions. CSF 2.0, released in February 2024, added a sixth function — Govern — to the original five, and NIST explicitly broadened the framework's scope beyond critical-infrastructure operators to "all organizations regardless of type or size," retitling it from the "Framework for Improving Critical Infrastructure Cybersecurity" to simply "The Cybersecurity Framework" (NIST).
The six functions are:
| Function | What it covers |
|---|---|
| Govern | How the organisation makes and executes decisions to support its cybersecurity strategy, including roles, policy, and risk appetite |
| Identify | Understanding organisational risk to systems, people, assets, data, and capabilities |
| Protect | Safeguards to ensure delivery of critical services |
| Detect | Activities to identify the occurrence of a cybersecurity event |
| Respond | Actions taken regarding a detected incident |
| Recover | Activities to restore capabilities or services impaired by an incident |
(Identify through Recover per NIST's CSF 1.1 five-functions reference; Govern per NIST's 2023 announcement of the CSF 2.0 draft.)
CSF is not certifiable and does not prescribe specific technical controls — it is a common language for describing a security programme's maturity, useful for board-level reporting and for structuring a roadmap. This is also its main limitation: an organisation can be "aligned to CSF" without much technical rigour underneath it, because CSF itself doesn't mandate specific safeguards.
ISO/IEC 27001:2022
ISO/IEC 27001 is a certifiable information security management system (ISMS) standard. The 2022 revision restructured Annex A into 93 controls across four themes: Organizational (37), People (8), Physical (14), and Technological (34) controls (DataGuard). Certification requires an accredited external auditor to assess both the management system (risk assessment, policies, internal audit, management review) and a "Statement of Applicability" explaining which Annex A controls apply and why.
ISO 27001's strength is that it forces a management system around security — ownership, continuous improvement, documented risk treatment — rather than a static list of technical controls. Its weakness is that certification says an ISMS exists and is being followed; it does not by itself guarantee any specific technical control is well-implemented, since the Statement of Applicability allows organisations to justify excluding controls.
CIS Critical Security Controls (v8.1)
The Center for Internet Security's Critical Security Controls are a prioritised, technically specific set of safeguards, organised into three Implementation Groups. IG1 — "essential cyber hygiene" — is the baseline CIS recommends every organisation implement first; IG2 builds on it for organisations with more resources and higher risk exposure; IG3 covers the full safeguard set for organisations with the most complex requirements and highest exposure (CIS). Across CIS Controls v8/v8.1 there are 153 total Safeguards, with IG3 encompassing the complete set.
CIS Controls are the most actionable of the group — they read like an engineering checklist rather than a management-system standard — which makes them a good technical baseline underneath a governance framework like CSF or a management system like ISO 27001, rather than a replacement for either.
SOC 2 (System and Organization Controls 2)
SOC 2 is not a certification but an attestation report, produced under standards set by the American Institute of Certified Public Accountants (AICPA), in which an independent CPA firm evaluates a service organisation's controls against the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy (AICPA & CIMA). Security (the "Common Criteria") is mandatory in every SOC 2 report; the other four categories are optional depending on what the organisation wants to demonstrate.
SOC 2 is built specifically for B2B software and service providers who need to show enterprise customers, during procurement, that their controls have been independently tested. A Type I report assesses whether controls are suitably designed at a point in time; a Type II report assesses whether they operated effectively over an observation period (commonly three to twelve months) — Type II is what most enterprise customers actually expect to see.
NIS2 (EU Directive) — the regulatory floor, not a voluntary framework
For organisations operating in the EU, NIS2 is different in kind from the four frameworks above: it is binding law for entities within its scope, not a voluntary standard. Article 21 of the directive requires essential and important entities to implement a minimum set of risk-management measures, including risk analysis and information-system security policies, incident handling, business continuity and disaster recovery, supply-chain security, security in system acquisition and development, policies on cryptography, human-resources security and access control, and multi-factor or continuous authentication (NIS2 Directive Article 21 text). The directive applies proportionally to organisational size and risk exposure, and identifies specific sectors — including DNS providers, cloud services, data centres, CDN providers, managed service providers, and trust service providers — for further implementing rules.
Whether NIS2 applies to a specific organisation, and how national transposition laws implement it, are legal questions. This section describes the directive's published minimum measures; it is not legal advice, and organisations that believe they may be in scope should confirm applicability and obligations with qualified legal counsel and their national competent authority.
Operationalising Frameworks on Azure
For organisations already standardised on Azure, Microsoft publishes the Microsoft Cloud Security Benchmark (MCSB) — a set of Azure-specific security controls, delivered as 420+ Azure Policy built-in definitions, that is explicitly cross-mapped to NIST SP 800-53 Rev. 5, NIST CSF 2.0, CIS Controls v8.1, PCI-DSS v4, ISO/IEC 27001:2022, and SOC 2 simultaneously (Microsoft Learn — Microsoft Cloud Security Benchmark overview). Each control carries a criticality rating (Must have / Should have / Nice to have), MITRE ATT&CK mappings, and step-by-step Azure implementation guidance.
This matters practically because implementing and evidencing the same control (multi-factor authentication, for example, or encryption at rest) separately for NIST CSF, CIS Controls, ISO 27001, and SOC 2 is exactly the audit-fatigue problem described above. Microsoft's own documentation is explicit that these mappings "indicate which Azure features can address framework requirements" but "don't guarantee full compliance with those standards" — the benchmark accelerates implementation and evidence-gathering, it does not replace an ISO 27001 audit or SOC 2 engagement. For Azure-first organisations, using MCSB as the technical implementation layer underneath whichever framework is chosen as primary is usually more efficient than treating Azure configuration as a separate workstream from the framework mapping exercise.
How Do These Frameworks Relate to Each Other?
They are not mutually exclusive, and for most organisations the realistic end state is a primary framework with the others mapped underneath it.
| Framework | Type | Certifiable? | Best used as |
|---|---|---|---|
| NIST CSF 2.0 | Risk-management taxonomy | No | A common structure for strategy, roadmap, and board reporting |
| ISO/IEC 27001:2022 | Management system standard | Yes | Third-party proof that a security management system exists and operates |
| CIS Controls v8.1 | Prioritised technical safeguards | No (self-assessed) | The concrete engineering checklist underneath a governance framework |
| SOC 2 | Independent attestation report | No (audited, not certified) | Proof to enterprise customers during procurement, primarily for SaaS/service providers |
| NIS2 (EU) | Binding directive | Not applicable — legal obligation | The mandatory floor for in-scope EU entities, regardless of which voluntary framework sits on top |
A common and defensible pattern: use NIST CSF's six functions as the organising structure for governance and reporting, implement CIS Controls IG1 (moving to IG2 as maturity grows) as the technical baseline underneath it, and pursue ISO 27001 certification or a SOC 2 report only when a specific customer, tender, or regulatory requirement demands third-party attestation. Because CIS, NIST CSF, and ISO 27001 controls substantially overlap, mapping them once during initial adoption avoids re-litigating the same control (e.g., multi-factor authentication, asset inventory, vulnerability management) across four separate audit trails.
What Should Drive the Decision?
Who is actually asking for this?
- A specific enterprise customer or tender document asking for SOC 2 or ISO 27001 → the certification/attestation route is close to mandatory; there is no substitute that will satisfy their procurement checklist.
- Cyber insurance underwriting → increasingly maps to CIS Controls or NIST CSF maturity questions; confirm with the broker which framework the insurer's questionnaire actually references.
- EU regulatory scope (NIS2, and sector rules like DORA for financial entities) → this is a legal floor, not optional, and should be confirmed with counsel rather than treated as "another framework to pick from."
- No external requirement yet, but the board wants assurance the risk is managed → NIST CSF plus CIS Controls IG1 is usually sufficient and considerably cheaper than pursuing certification prematurely.
What size and maturity is the organisation?
A five-person startup pursuing ISO 27001 certification before it has basic asset inventory and MFA everywhere is solving the wrong problem first — CIS IG1 exists precisely because CIS considers it "essential cyber hygiene" that should come before anything more advanced (CIS). Conversely, a 2,000-person regulated enterprise trying to run its whole security programme off IG1 alone is under-scoped for its actual risk exposure.
Trade-offs and Decision Guidance
You sell into enterprise or public-sector accounts where procurement explicitly requires it; you operate across multiple jurisdictions and want one recognised standard rather than negotiating bespoke security questionnaires repeatedly; or a regulator/sector rule effectively expects a certified ISMS.
Basic hygiene (MFA, patching, backups, asset inventory, logging) is still inconsistent. An external audit will surface these gaps anyway, at a much higher cost per fix than addressing them proactively under CIS IG1 first.
Build vs. buy also applies here in a specific way: implementing frameworks in-house is usually a moderate-complexity documentation and process exercise, not a technology purchase. Many organisations under-invest in the unglamorous parts — asset inventories, log retention, access review cadence — because they're not vendor products with a sales cycle, even though frameworks weight them heavily.
Common Mistakes
Rushing an ISO 27001 audit to close a deal, then discovering the Statement of Applicability doesn't match reality, damages credibility with the auditor and the customer far more than simply not being certified yet.
Teams sometimes debate "NIST CSF vs. ISO 27001" as if choosing one excludes the other. They answer different questions — strategy/reporting versus certifiable management system — and are frequently used together.
An organisation can be fully ISO 27001 certified and still be non-compliant with NIS2 if it hasn't confirmed which of the directive's specific Article 21 measures apply to it and implemented them explicitly.
Without a control-mapping exercise, security teams end up answering nearly identical evidence requests (MFA, vulnerability scanning, incident response plan) separately for SOC 2, ISO 27001, and a customer questionnaire, multiplying audit fatigue without multiplying actual security.
A narrower, accurate scope (e.g., the specific product and infrastructure that processes customer data) is more defensible and cheaper to maintain than an overly broad scope that's hard to keep evidence current for.
Cost, Complexity, and Timeline
Exact costs vary too widely by organisation size, auditor, and existing maturity to state reliably, so treat the following as relative complexity, not fixed figures:
- NIST CSF adoption — low-to-moderate effort; primarily a mapping and governance exercise using existing security work, since CSF has no external audit.
- CIS Controls IG1 — moderate effort; mostly foundational engineering work (MFA, inventory, patch management, logging) many organisations partially have already.
- ISO 27001 certification — significant effort; requires a documented ISMS, internal audit, management review, and an external certification audit, typically involving dedicated ownership (often a fractional or full-time information security manager) and ongoing annual surveillance audits.
- SOC 2 Type II — significant, ongoing effort; requires operating controls consistently across an observation window (commonly several months to a year) before the audit can even begin, plus annual re-audits.
- NIS2 compliance — effort depends entirely on current maturity and sector-specific implementing rules; this is a compliance deadline, not a discretionary project, so timeline should be driven by legal advice on the applicable transposition deadline in each member state.
Security and Governance Considerations
Whichever framework is primary, a few control areas recur across all of them and are worth prioritising regardless of framework choice: centralized identity and MFA, a current asset and data inventory, a tested incident response plan, vulnerability and patch management with defined SLAs, and defined ownership for each control area. These show up in CIS IG1, NIST CSF's Protect/Detect functions, ISO 27001 Annex A's technological controls, and SOC 2's Common Criteria simultaneously — which is exactly why building them once, well, pays off across every framework layered on top later.
How Halden Solutions Approaches This
We start by asking what's actually driving the framework conversation — a specific customer requirement, a regulatory deadline, an insurance renewal, or a genuine internal risk-reduction goal — because that answer determines whether certification is even the right near-term investment. Where a framework is warranted, we favour mapping one primary structure (usually NIST CSF for governance, CIS Controls for the technical baseline) and layering certification-specific requirements on top of controls that already exist, rather than running separate compliance tracks. For Azure-hosted clients specifically, we use the Microsoft Cloud Security Benchmark's existing framework mappings as a starting point rather than re-deriving Azure-specific control implementation from scratch. For clients with EU regulatory exposure, we treat NIS2 and sector rules as a legal-scope question to resolve with the client's counsel first, and then help translate the resulting obligations into concrete engineering and process work.
Frequently Asked Questions
They're not directly comparable — ISO 27001 is a certifiable management-system standard audited by a third party; NIST CSF is a non-certifiable risk-management taxonomy. Many organisations use CSF as an internal structure and pursue ISO 27001 only when certification itself is required by a customer or market.
Not as a separate audited programme, but CIS Controls remain useful as a concrete, prioritised checklist for verifying that ISO 27001's Annex A technological controls are implemented with real engineering rigour, not just documented.
No. It becomes practically necessary when enterprise customers require it during procurement. Smaller B2B companies selling primarily to SMBs, or products without enterprise sales cycles, often don't encounter the requirement yet.
No — NIS2 sets mandatory minimum measures under Article 21 for in-scope EU entities; a voluntary framework like ISO 27001 or NIST CSF is commonly used as the operational structure through which those legal measures get implemented and evidenced, not a substitute for confirming and meeting the directive's requirements directly.
No. Microsoft's own documentation states MCSB mappings indicate which Azure controls can address a framework's requirements, not that using them guarantees full compliance. It accelerates technical implementation and evidence-gathering; it doesn't replace the governance work, risk assessment, or external audit a framework like ISO 27001 or SOC 2 still requires.
Applicability depends on sector, size thresholds, and each EU member state's national transposition law. This is a legal determination, not a technical one — confirm scope with qualified counsel or your national competent authority rather than assuming based on general sector descriptions.
Conclusion
The frameworks described here solve different problems: NIST CSF gives you a governance vocabulary, CIS Controls gives you a prioritised technical checklist, ISO 27001 gives you a certifiable management system, SOC 2 gives you a customer-facing attestation, and NIS2 (where applicable) gives you a binding legal floor. The practical decision isn't "which one" — it's which one is primary, which are mapped underneath it, and whether an external requirement actually justifies the cost of certification or attestation right now. Start from the smallest defensible baseline, confirm any legal obligations separately with counsel, and add certification only when a real stakeholder is asking for it.
If you're weighing which framework fits your organisation's risk profile and customer requirements, Halden Solutions' Cybersecurity & Sovereign Cloud team can help assess your current posture and map a pragmatic path forward. See also our guide to identity and access management on Azure.
Sources
- NIST — "NIST Drafts Major Update to Its Widely Used Cybersecurity Framework" (CSF 2.0 announcement, six functions incl. Govern, expanded scope)
- NIST — "The CSF 1.1 Five Functions"
- CIS — "CIS Critical Security Controls Implementation Groups" (IG1/IG2/IG3 definitions)
- AICPA & CIMA — "SOC 2® – SOC for Service Organizations: Trust Services Criteria"
- DataGuard — "ISO 27001 Controls: Overview of all measures from Annex A" (93 controls, four themes)
- NIS2 Directive — Article 21 text, cybersecurity risk-management measures
- Microsoft Learn — Overview of the Microsoft Cloud Security Benchmark