Security teams routinely treat regulations and control frameworks as interchangeable, and that confusion leads to wasted effort, false confidence and, at worst, a certificate on the wall that a regulator does not accept as proof of compliance. A regulation is law: it says what outcome you must achieve, who enforces it and what happens if you fail. A control framework is guidance or a standard: it says how you might achieve security outcomes, and only becomes binding when a law, contract or certification you have chosen makes it so. This guide compares the two on legal force, certification, enforcement and evidence, shows how a regulatory obligation is met through framework controls, and sets out how to build one control set that serves both. It is written for GRC leads, CISOs, compliance officers and auditors working across NIS2, GDPR, HIPAA and similar rules alongside NIST CSF, ISO/IEC 27001 or CIS Controls.
Key takeaways
- Regulations bind, frameworks guide. NIS2 sets fines of at least EUR 10 million or 2 per cent of worldwide turnover for essential entities; NIST describes CSF 2.0 as something that may be adopted voluntarily and that does not prescribe how outcomes are achieved.
- Most regulations are deliberately outcome-based. NIS2 Article 21 requires appropriate and proportionate measures; HIPAA lets entities use any security measures that reasonably and appropriately implement the standards. Frameworks fill the gap between "appropriate" and an actual control.
- Certification is evidence, not a legal shield. GDPR Article 32(3) lets certification be used as an element to demonstrate compliance, and Article 42(4) states it does not reduce the controller's or processor's responsibility.
- Frameworks become mandatory by reference. A law, a supervisory regulation, a contract or a customer requirement can turn a standard into an obligation, as the NIS2 implementing regulation does by basing its requirements on ISO/IEC 27001 and 27002.
- Build one control set, map outward. Anchor on one framework, map each regulatory obligation to controls, and keep a register of the obligations that no framework control covers, such as notification deadlines and management accountability.
The short answer
A regulation answers "what must we achieve, and what happens if we do not?". A framework answers "how could we organise and implement controls to achieve it?". A standard sits between them: a published, often certifiable specification (ISO/IEC 27001 is a standard; NIST CSF 2.0 is a framework; PCI DSS is an industry standard enforced through card-scheme contracts). Whether any of them is mandatory for you depends on the legal or contractual route by which it reaches you, not on what it is called. The Regulations and Frameworks Guide gives the overview of the field; this page goes deeper on how the two interact in practice.
| Dimension | Regulation (e.g. NIS2, GDPR, HIPAA Security Rule) | Control framework or standard (e.g. NIST CSF 2.0, ISO/IEC 27001, CIS Controls) |
|---|---|---|
| Source of authority | Legislature or regulator; legal force within its territory and scope | Standards body, government agency acting as guidance publisher, or industry body |
| Who must comply | Defined by law: sector, size, activity, data processed | Whoever chooses to adopt it, or is required to by contract or by a law that references it |
| Typical wording | Outcomes and duties: "appropriate and proportionate measures", "level of security appropriate to the risk" | Controls, outcomes or requirements with implementation detail and informative references |
| Enforcement | Supervisory authorities: audits, binding instructions, fines, management sanctions | None by itself; certification bodies can withdraw a certificate; customers can end contracts |
| Proof | Whatever the regulator accepts; burden often on the organisation to demonstrate compliance | Certificate, attestation report or self-assessment against the framework |
| Change cycle | Legislative process, implementing acts, guidance and case law | Revision cycles by the publisher (CSF 2.0 in 2024, ISO/IEC 27001:2022) |
| Non-security duties | Often included: notification deadlines, registration, management training, reporting to authorities | Usually absent or covered only as "identify legal requirements" |
| Territorial reach | Jurisdictional, sometimes extraterritorial (GDPR) | Global, but adoption varies by market |
Legal force: how each one reaches you
Regulations
Regulations create obligations whether you like them or not, once you fall in scope. NIS2 (Directive (EU) 2022/2555) required Member States to adopt transposing measures by 17 October 2024 and apply them from 18 October 2024. Article 20 requires management bodies to approve cybersecurity risk-management measures, oversee their implementation and makes them liable for infringements. Article 21 requires appropriate and proportionate technical, operational and organisational measures, with a minimum list in Article 21(2) points (a) to (j): from risk analysis policies through incident handling, business continuity, supply chain security, effectiveness assessment and cryptography to access control and multi-factor authentication. Each Member State's transposition adds its own detail, so check the national law (see the NIS2 Directive Guide and national implementation pages such as the Germany NIS2 Implementation Guide).
In the United States, the HIPAA Security Rule shows the same outcome-based design: 45 CFR 164.306(b)(1) lets covered entities and business associates use any security measures that allow them to reasonably and appropriately implement the standards, and 164.306(d) splits implementation specifications into required and addressable, where addressable means assess, implement if reasonable and appropriate, or document why not and adopt an equivalent alternative where reasonable. See the HIPAA Security Rule Guide.
Frameworks
NIST CSF 2.0 (CSWP 29, published 26 February 2024) states plainly that it does not embrace a one-size-fits-all approach, that it does not prescribe outcomes nor how they may be achieved, and that it may be adopted voluntarily and through governmental policies and mandates. That last clause is the key: a framework is voluntary until something makes it mandatory. ISO/IEC 27001 is a certifiable management system standard, but nobody is obliged to certify unless a customer, contract or regulator asks for it.
The routes by which a framework becomes binding
| Route | How it works | Example |
|---|---|---|
| Law references a standard | The legal text or an implementing act builds its requirements on a named standard | Implementing Regulation (EU) 2024/2690 states in its recitals that its Annex requirements are based on European and international standards including ISO/IEC 27001 and ISO/IEC 27002 |
| Law allows mandated certification | Member States or regulators may require certified products or services | NIS2 Article 24(1) lets Member States require certain ICT products, services and processes certified under European cybersecurity certification schemes |
| Government policy | Agencies and their suppliers are required to use a framework | CSF 2.0 notes adoption through governmental policies and mandates |
| Contract | A customer or scheme makes the standard a condition of doing business | PCI DSS for organisations that store, process or transmit cardholder data; SOC 2 or ISO 27001 clauses in supplier contracts |
| Regulator expectation | Supervisory guidance treats a framework as the benchmark of "appropriate" | Supervisors encouraged by NIS2 Article 25 to promote European and international standards |
Certification and attestation: what they prove and what they do not
A certificate or attestation proves that an independent party checked your controls against the framework, within a defined scope, at a point in time or over a period. It does not prove that you meet a specific law. GDPR is explicit: Article 32(3) says adherence to an approved certification mechanism may be used as an element by which to demonstrate compliance with the security requirements of Article 32(1), and Article 42(4) says certification does not reduce the responsibility of the controller or the processor for compliance and does not affect the supervisory authorities' powers. Note also that GDPR certification means a mechanism approved under Article 42, not any security certificate.
| Assurance artefact | What it shows | What it does not show |
|---|---|---|
| ISO/IEC 27001 certificate | An ISMS meeting the standard's clauses, within the stated scope, audited by a certification body | That every regulatory obligation is met; that out-of-scope units are covered; that specific controls operated well between surveillance audits |
| SOC 2 Type 2 report | Controls relevant to the trust services criteria operated effectively over a period, with tests and exceptions described | Legal compliance; coverage of systems outside the described system |
| NIST CSF self-assessment or profile | Current and target outcomes as judged by the organisation | Independent verification, unless someone else assessed it |
| Regulatory audit (e.g. NIS2 Article 32 security audit) | The authority's or independent body's view of compliance with the law | Conformance with any framework beyond what the authority chose to examine |
For how auditors decide whether controls actually work, rather than merely exist, see Control Design vs Operating Effectiveness. For choosing an auditor and preparing for ISO certification see the ISO 27001 Certification Guide.
Enforcement: who can sanction you and how
Enforcement is where the difference becomes concrete. Under NIS2 Article 32, competent authorities can carry out on-site and off-site inspections, regular and targeted security audits, ad hoc audits and security scans, request evidence of implementation, issue binding instructions and order public disclosure of infringements; where earlier measures fail they can temporarily suspend certifications or authorisations and seek a temporary ban on a chief executive exercising managerial functions. Article 34 sets maximum fines for infringing Articles 21 or 23 of at least EUR 10 million or 2 per cent of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4 per cent for important entities, whichever is higher.
A framework has no equivalent. The worst outcome of failing ISO/IEC 27001 is losing the certificate, which matters commercially but carries no fine. The worst outcome of ignoring CSF is nothing at all, unless a contract or law required it. The practical consequence: when budget is tight, regulatory obligations come first, and framework conformance is justified by how efficiently it delivers them.
From obligation to control: a worked mapping
The mapping runs one way: start from the legal obligation, decompose it into testable requirements, then find the framework controls that meet each one and the evidence that proves it. Mapping the other way (we have ISO, so we comply) is how gaps are missed. The method for building and maintaining mappings is covered in the Control Mapping Guide and the ISO 27001 to NIS2 and DORA Mapping Guide; the example below shows the reasoning for one obligation.
| Layer | Content for NIS2 Article 21(2)(i) and (j) |
|---|---|
| Legal text (paraphrased) | Human resources security, access control policies and asset management; use of multi-factor or continuous authentication and secured communications where appropriate |
| Interpretation | Who is in scope (staff, contractors, machine identities, suppliers with access); which systems are "network and information systems" for this entity; what "where appropriate" means in your risk assessment |
| Testable requirements | Asset and identity inventory exists and is current; access granted by role and reviewed; MFA enforced for remote and privileged access; NHI credentials owned, scoped and rotated |
| Framework controls (anchor plus references) | NIST CSF 2.0 ID.AM-01, PR.AA-01, PR.AA-03, PR.AA-05; NIST SP 800-53 AC-2, IA-2, IA-5; ISO/IEC 27001:2022 Annex A 5.15 to 5.18 and 8.5 |
| Evidence | Inventory exports, access review records, conditional access or MFA policy configuration, vault rotation reports, exception register |
| Gaps the framework does not close | National transposition specifics, entity registration, management body approval and training (Article 20), incident notification timelines (Article 23) |
Where identity fits
Access control and authentication obligations appear in almost every security regulation, and auditors increasingly ask how they apply to machine identities. "Access control" in NIS2 Article 21(2)(i) or "access controls" in HIPAA do not exempt service accounts, API keys or AI agents, yet many control sets map those obligations only to workforce identity processes. When you map an access obligation, make the NHI population an explicit testable requirement. The Machine Identity Requirements Map lists where regulations and frameworks touch machine credentials.
Building one control set that serves both
- Build the obligation register first. List every law, regulation, contract and customer requirement in scope, with article-level obligations, owner and jurisdiction. NIST CSF 2.0 GV.OC-03 covers understanding legal, regulatory and contractual requirements.
- Choose one anchor framework. Pick the one most of your obligations and customers already speak: ISO/IEC 27001 for certification-driven and EU-facing organisations, NIST SP 800-53 or CSF for US public sector suppliers, CIS Controls for smaller teams needing prioritised technical safeguards.
- Write controls in your own words. Each internal control has an owner, frequency, population and evidence, with references to the anchor and to every obligation it serves. One control, many references.
- Map obligations to controls, not frameworks to frameworks. Use publisher mappings (NIST informative references, OLIR) as a starting point, then validate each link against the legal text.
- Keep a residual register. Record obligations no control covers (notification deadlines, registration, board training, penalties for specific roles) and assign them to legal, compliance or the board secretary.
- Test once, report many. Operate a single testing calendar; reuse evidence across audits only where scope, period and population genuinely match.
- Track change on both sides. Watch national transpositions, implementing acts and regulator guidance as closely as framework revisions; re-map when either changes, and keep the old mapping until the new one is approved, so you can roll back.
Decision guidance
- Is NIST CSF mandatory? Not by itself. It becomes required through government policy, contracts or sector regulators that adopt it. Check your contracts and sector rules, not the framework.
- Will ISO/IEC 27001 meet NIS2? It covers much of Article 21 and the NIS2 implementing regulation draws on it, but it does not cover national registration, notification deadlines or management liability, and a certificate scope may not match the NIS2 entity. Use it as the backbone and close the gaps explicitly.
- Certify or self-assess? Certify when customers, tenders or regulators value independent assurance; self-assess against CSF when the goal is internal prioritisation and board reporting.
- Small versus large organisations: smaller organisations gain most from one anchor framework and a short residual register. Large and multinational organisations need jurisdiction-specific overlays and a mapping tool, because national transpositions diverge.
- Prescriptive versus outcome-based rules: where a regulation is prescriptive (a named control or deadline), implement it literally and record it; where it is outcome-based, use the framework and your risk assessment to justify what "appropriate" means, and keep that justification as evidence.
Detection and measurement
- Obligation coverage: percentage of article-level obligations mapped to at least one tested control or a named owner in the residual register.
- Control reuse ratio: average number of obligations served per internal control (higher means less duplication).
- Mapping freshness: days between a regulatory or framework change and an approved updated mapping.
- Audit findings by source: findings from regulators versus certification bodies versus customers; regulator findings on mapped controls suggest the mapping is wrong, not just the control.
- Evidence reuse rate: share of evidence items accepted by more than one assessor without rework.
Common failure patterns
- Certificate as compliance: treating an ISO/IEC 27001 certificate or SOC 2 report as proof of legal compliance, despite GDPR Article 42(4) and the scope limits of each report.
- Framework-to-framework mapping only: mapping ISO to NIST and assuming regulatory coverage, without ever reading the obligation text.
- Scope mismatch: the certified ISMS covers one business unit, while the regulated entity is the whole group.
- Ignoring non-control duties: notification deadlines, registration and management training sit outside every control catalogue and are missed.
- Workforce-only access controls: access and authentication obligations mapped to human identity processes, while service accounts and tokens stay unowned and unrotated.
- Static mappings: mappings built once for an audit and never updated as national laws and implementing acts arrive.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Legal, regulatory and contractual requirements are understood and managed |
| NIST CSF 2.0 | GV.PO-01 | Policy established from context, strategy and priorities |
| NIST SP 800-53 Rev. 5 | PM-9 Risk Management Strategy; CA-2 Control Assessments | Linking requirements to an organisational strategy and assessing controls |
| ISO/IEC 27001:2022 | Clause 4.2; Annex A 5.31 and 5.36 | Interested party requirements; legal, statutory, regulatory and contractual requirements; compliance with policies and standards |
| NIS2 | Articles 20, 21, 24, 25, 32, 34 | Governance, measures, certification, standardisation, supervision and fines |
| GDPR | Articles 32, 42 | Security of processing; certification as an element of demonstrating compliance |
Practitioner checklist
- Maintain an obligation register at article level for every law, regulation and contract in scope.
- Choose one anchor framework and record why it fits your obligations and customers.
- Map from each obligation to internal controls and evidence, never only framework to framework.
- Keep a residual register for duties no control covers, with named owners.
- Check certificate and report scopes against the legal entity and systems each regulation covers.
- Include service accounts, API keys and AI agents in every access and authentication requirement.
- Monitor national transpositions and implementing acts, and re-map when they change.
- Report obligation coverage and mapping freshness to the risk committee each quarter.
Standards and references
- EUR-Lex: Directive (EU) 2022/2555 (NIS2)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2690
- EUR-Lex: Regulation (EU) 2016/679 (GDPR)
- eCFR: 45 CFR 164.306, HIPAA Security standards general rules
- NIST: CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53A Rev. 5, Assessing Security and Privacy Controls
- PCAOB: AS 2201, An Audit of Internal Control Over Financial Reporting
Related NHI Mgmt Group resources: Regulations and Frameworks Guide · Control Mapping Guide · ISO 27001 to NIS2 and DORA Mapping Guide · NIS2 Directive Guide · Control Design vs Operating Effectiveness. This guide summarises NIS2, GDPR and HIPAA provisions and is not legal advice.