NIST CSF 2.0 Explorer

Aspect	NIST CSF 2.0	ISO 27001	NIS2	DORA
Type	Voluntary framework	Voluntary standard (certifiable)	EU Directive (binding)	EU Regulation (binding)
Scope	All organisations, all sectors	All organisations	18 critical sectors (EU)	Financial services (EU)
Structure	6 Functions, 22 Categories, 106 Subcategories	93 Annex A controls, 4 themes	46 Articles, 5 pillars	64 Articles, 5 pillars
Governance	Dedicated Govern function (new in 2.0)	Management commitment clause	Art. 20 management liability	Art. 5 management body
Risk Tiers	4 Implementation Tiers	Risk-based ISMS	Essential vs Important	Proportionality principle
Enforcement	None (voluntary)	Certification audit	Fines up to EUR 10M / 2%	Fines per national law

Category	Description	Subcategories
GV.OC — Organisational Context	The circumstances — mission, stakeholder expectations, dependencies, legal/regulatory/contractual requirements — surrounding the organisation's cybersecurity risk management decisions are understood	5
GV.RM — Risk Management Strategy	The organisation's priorities, constraints, risk tolerance and appetite statements, and assumptions are established, communicated, and used to support operational risk decisions	7
GV.RR — Roles, Responsibilities & Authorities	Cybersecurity roles, responsibilities, and authorities to foster accountability, performance assessment, and continuous improvement are established and communicated	4
GV.PO — Policy	Organisational cybersecurity policy is established, communicated, and enforced	2
GV.OV — Oversight	Results of organisation-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy	3
GV.SC — Cybersecurity Supply Chain Risk Management	Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organisational stakeholders	10

Category	Description	Subcategories
ID.AM — Asset Management	Assets (data, hardware, software, systems, facilities, services, people) that enable the organisation to achieve business purposes are identified and managed consistent with their relative importance to organisational objectives and risk strategy	8
ID.RA — Risk Assessment	The cybersecurity risk to the organisation, assets, and individuals is understood	6
ID.IM — Improvement	Improvements to organisational cybersecurity risk management processes, procedures, and activities are identified across all CSF Functions	3

Category	Description	Subcategories
PR.AA — Identity Management, Authentication & Access Control	Access to physical and logical assets is limited to authorised users, services, and hardware and managed commensurate with the assessed risk of unauthorised access	6
PR.AT — Awareness & Training	The organisation's personnel are provided cybersecurity awareness and training so they can perform their cybersecurity-related duties	2
PR.DS — Data Security	Data are managed consistent with the organisation's risk strategy to protect the confidentiality, integrity, and availability of information	10
PR.PS — Platform Security	The hardware, software, and services of physical and virtual platforms are managed consistent with the organisation's risk strategy to protect their confidentiality, integrity, and availability	6
PR.IR — Technology Infrastructure Resilience	Security architectures are managed with the organisation's risk strategy to protect asset confidentiality, integrity, and availability, and organisational resilience	4

Category	Description	Subcategories
DE.CM — Continuous Monitoring	Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events	9
DE.AE — Adverse Event Analysis	Anomalies, indicators of compromise, and other potentially adverse events are analysed to characterise the events and detect cybersecurity incidents	8

Category	Description	Subcategories
RS.MA — Incident Management	Responses to detected cybersecurity incidents are managed	5
RS.AN — Incident Analysis	Investigations are conducted to ensure effective response and support forensics and recovery activities	3
RS.CO — Incident Response Reporting & Communication	Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies	3
RS.MI — Incident Mitigation	Activities are performed to prevent expansion of an event and mitigate its effects	2

Category	Description	Subcategories
RC.RP — Incident Recovery Plan Execution	Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents	6
RC.CO — Incident Recovery Communication	Restoration activities are coordinated with internal and external parties	4

GV.OC Organisational Context Core ▶

The circumstances surrounding the organisation's cybersecurity risk management decisions are understood. This includes mission, stakeholder expectations, and dependencies.

Key Subcategories

GV.OC-01: The organisational mission is understood and informs cybersecurity risk management
GV.OC-02: Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
GV.OC-03: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed
GV.OC-04: Critical objectives, capabilities, and services that external stakeholders depend on or expect are understood and communicated
GV.OC-05: Outcomes, capabilities, and services that the organisation depends on are understood and communicated

Security Engineer Takeaway: GV.OC is about knowing why you exist and what you're protecting. Map your critical business services, understand regulatory obligations (NIS2, DORA, GDPR, sector-specific regulations), and identify dependencies on external providers. This context drives risk appetite and prioritisation for everything else in the framework.

References: NIST CSF GV.OC

GV.RM Risk Management Strategy Core ▶

The organisation's priorities, constraints, risk tolerance and appetite statements, and assumptions are established, communicated, and used to support operational risk decisions.

Key Subcategories

GV.RM-01: Risk management objectives are established and agreed to by organisational stakeholders
GV.RM-02: Risk appetite and risk tolerance statements are established, communicated, and maintained
GV.RM-03: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
GV.RM-04: Strategic direction that describes appropriate risk response options is established and communicated
GV.RM-05: Lines of communication across the organisation are established for cybersecurity risks, including risks from suppliers and other third parties
GV.RM-06: A standardised method for calculating, documenting, categorising, and prioritising cybersecurity risks is established and communicated
GV.RM-07: Strategic opportunities (i.e., positive risks) are characterised and are included in organisational cybersecurity risk discussions

Security Engineer Takeaway: This is where you document your risk appetite. "We accept no more than X hours of downtime for critical services" or "We will not accept risks rated above Y without explicit board approval." Make risk tolerance actionable, not aspirational. Integrate cybersecurity risks into your enterprise risk register and ensure risk communication flows both up (to the board) and down (to operational teams).

GV.RR Roles, Responsibilities & Authorities Important ▶

Cybersecurity roles, responsibilities, and authorities to foster accountability, performance assessment, and continuous improvement are established and communicated.

Key Subcategories

GV.RR-01: Organisational leadership is responsible and accountable for cybersecurity risk and fosters a culture of cybersecurity risk awareness
GV.RR-02: Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
GV.RR-03: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
GV.RR-04: Cybersecurity is included in human resources practices

Security Engineer Takeaway: Ensure the CISO has a clear mandate, adequate budget, and direct reporting line to senior leadership. GV.RR-01 explicitly states leadership must be "responsible and accountable" — use this to push for board-level cybersecurity governance. GV.RR-04 means security in hiring (background checks), onboarding (security awareness), and offboarding (access revocation).

GV.PO Policy Important ▶

Organisational cybersecurity policy is established, communicated, and enforced.

Key Subcategories

GV.PO-01: Policy for managing cybersecurity risks is established based on organisational context, cybersecurity strategy, and priorities and is communicated and enforced
GV.PO-02: Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organisational mission

Security Engineer Takeaway: Policies must be living documents, not shelf-ware. Review annually at minimum, and update after significant incidents, organisational changes, or new regulations. Make sure policies are communicated effectively (not just posted on an intranet nobody reads) and that enforcement mechanisms exist (monitoring, auditing, consequences for non-compliance).

GV.OV Oversight Important ▶

Results of organisation-wide cybersecurity risk management activities and performance are used to inform, improve, and adjust the risk management strategy.

Key Subcategories

GV.OV-01: Cybersecurity risk management strategy outcome is reviewed to inform and adjust strategy and direction
GV.OV-02: The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organisational requirements and risks
GV.OV-03: Organisational cybersecurity risk management performance is evaluated and reviewed for adjustments needed

Security Engineer Takeaway: Oversight means measuring outcomes, not just activities. Establish KPIs: mean time to detect, mean time to respond, patch compliance rates, training completion, risk reduction over time. Report these to leadership quarterly and use the data to adjust strategy. If your MTTD is 200 days, your strategy needs adjusting regardless of how many tools you have deployed.

GV.SC Cybersecurity Supply Chain Risk Management Core ▶

Cyber supply chain risk management processes are identified, established, managed, monitored, and improved by organisational stakeholders.

Key Subcategories

GV.SC-01: A cybersecurity supply chain risk management programme, strategy, objectives, policies, and processes are established and agreed to by organisational stakeholders
GV.SC-02: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
GV.SC-03: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
GV.SC-04: Suppliers are known and prioritised by criticality
GV.SC-05: Requirements to address cybersecurity risks in supply chains are established, prioritised, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
GV.SC-06: Planning and due diligence are conducted to reduce risks before entering into formal supplier or other third-party relationships
GV.SC-07: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritised, assessed, responded to, and monitored over the course of the relationship
GV.SC-08: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
GV.SC-09: Supply chain security practices are integrated into cybersecurity and enterprise risk management programmes, and their performance is monitored throughout the technology product and service life cycle
GV.SC-10: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement

Security Engineer Takeaway: GV.SC is the most expanded area in CSF 2.0 with 10 subcategories. This reflects the increasing reality that your security posture is only as strong as your weakest supplier. Key actions: (1) inventory all suppliers by criticality, (2) include security requirements in contracts, (3) conduct due diligence before onboarding, (4) include suppliers in your IR plans, (5) plan for supplier exit/transition. Align with NIS2 Art. 21(2)(d) and DORA Art. 28–30 if those regulations apply to you.

References: NIST CSF GV.SC NIST SP 800-161r1 C-SCRM

ID.AM Asset Management Core ▶

Assets that enable the organisation to achieve business purposes are identified and managed consistent with their relative importance to organisational objectives and risk strategy.

Key Subcategories

ID.AM-01: Inventories of hardware managed by the organisation are maintained
ID.AM-02: Inventories of software, services, and systems managed by the organisation are maintained
ID.AM-03: Representations of the organisation's authorised network communication and internal and external network data flows are maintained
ID.AM-04: Inventories of services provided by suppliers are maintained
ID.AM-05: Assets are prioritised based on classification, criticality, resources, and impact on the mission
ID.AM-07: Inventories of data and corresponding metadata for designated data types are maintained
ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles

Security Engineer Takeaway: Asset management is foundational. You cannot protect assets you don't know about. Maintain automated discovery tools (network scanners, CMDB, cloud asset inventories), classify assets by criticality, and track lifecycle from procurement to decommissioning. The new ID.AM-07 on data inventories is critical for data governance and privacy compliance.

ID.RA Risk Assessment Core ▶

The cybersecurity risk to the organisation, assets, and individuals is understood.

Key Subcategories

ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded
ID.RA-02: Cyber threat intelligence is received from information sharing forums and sources
ID.RA-03: Internal and external threats to the organisation are identified and recorded
ID.RA-04: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
ID.RA-05: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritisation
ID.RA-06: Risk responses are chosen, prioritised, planned, tracked, and communicated

Security Engineer Takeaway: Run vulnerability scans continuously, not just quarterly. Integrate threat intelligence (MITRE ATT&CK, ISACs, commercial feeds) into your risk assessments. Use a consistent risk scoring methodology (CVSS for vulnerabilities, a qualitative/quantitative risk matrix for broader risks). Document risk responses: accept, mitigate, transfer, or avoid — and track them to closure.

ID.IM Improvement Standard ▶

Improvements to organisational cybersecurity risk management processes, procedures, and activities are identified across all CSF Functions.

Key Subcategories

ID.IM-01: Improvements are identified from evaluations
ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
ID.IM-03: Improvements are identified from execution of operational processes

Security Engineer Takeaway: New in CSF 2.0, ID.IM formalises continuous improvement. After every incident, exercise, audit, or pen test, conduct a lessons-learned review and track improvement actions to completion. This feeds back into all other functions. Build a culture where finding gaps is rewarded, not punished.

PR.AA Identity Management, Authentication & Access Control Core ▶

Access to physical and logical assets is limited to authorised users, services, and hardware and managed commensurate with the assessed risk of unauthorised access.

Key Subcategories

PR.AA-01: Identities and credentials for authorised users, services, and hardware are managed by the organisation
PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions
PR.AA-03: Users, services, and hardware are authenticated
PR.AA-04: Identity assertions are protected, conveyed, and verified
PR.AA-05: Access permissions, entitlements, and authorisations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
PR.AA-06: Physical access to assets is managed, monitored, and enforced commensurate with risk

Security Engineer Takeaway: Identity is the new perimeter. Deploy MFA everywhere (prefer FIDO2/WebAuthn), implement least-privilege access, conduct quarterly access reviews for privileged accounts, and work toward zero-trust architecture. PR.AA-06 reminds us that physical access control matters too — server rooms, network closets, and data centres need the same rigour as logical access.

PR.AT Awareness & Training Important ▶

The organisation's personnel are provided cybersecurity awareness and training so they can perform their cybersecurity-related duties.

Key Subcategories

PR.AT-01: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
PR.AT-02: Individuals in specialised roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind

Security Engineer Takeaway: One-size-fits-all training doesn't work. PR.AT-01 covers general awareness (phishing, passwords, social engineering) for all staff. PR.AT-02 is role-specific: secure coding for developers, cloud security for architects, IR procedures for SOC analysts, and risk management for executives. Run phishing simulations monthly and track metrics.

PR.DS Data Security Core ▶

Data are managed consistent with the organisation's risk strategy to protect the confidentiality, integrity, and availability of information.

Key Subcategories

PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected
PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected
PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected
PR.DS-11: Backups of data are created, protected, maintained, and tested

Security Engineer Takeaway: Data security is a core priority. Encrypt data at rest (AES-256), in transit (TLS 1.3), and explore confidential computing for data in use. PR.DS-11 on backups is critical for ransomware resilience: maintain 3-2-1 backup strategy (3 copies, 2 media types, 1 offsite), test restores quarterly, and ensure at least one copy is immutable/air-gapped.

PR.PS Platform Security Important ▶

The hardware, software, and services of physical and virtual platforms are managed consistent with the organisation's risk strategy.

Key Subcategories

PR.PS-01: Configuration management practices are established and applied
PR.PS-02: Software is maintained, replaced, and removed commensurate with risk
PR.PS-03: Hardware is maintained, replaced, and removed commensurate with risk
PR.PS-04: Log records are generated and made available for continuous monitoring
PR.PS-05: Installation and execution of unauthorised software are prevented
PR.PS-06: Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle

Security Engineer Takeaway: PR.PS is the new consolidated category for platform hardening. Use CIS Benchmarks for baseline configurations, implement application allowlisting (PR.PS-05), maintain a patching cadence with SLAs (critical: 72h, high: 14d, medium: 30d), and integrate SAST/DAST into CI/CD pipelines (PR.PS-06). PR.PS-04 on logging is critical for feeding your SIEM and enabling detection.

PR.IR Technology Infrastructure Resilience Important ▶

Security architectures are managed with the organisation's risk strategy to protect asset confidentiality, integrity, and availability, and organisational resilience.

Key Subcategories

PR.IR-01: Networks and environments are protected from unauthorised logical access and usage
PR.IR-02: The organisation's technology assets are protected from environmental threats
PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
PR.IR-04: Adequate resource capacity to ensure availability is maintained

Security Engineer Takeaway: Build for resilience, not just security. Network segmentation (PR.IR-01), environmental controls (PR.IR-02), redundancy and failover (PR.IR-03), and capacity planning (PR.IR-04) are all essential. Design your architecture assuming breach — microsegmentation limits blast radius, and resilience mechanisms ensure you can continue operations during an active incident.

DE.CM Continuous Monitoring Core ▶

Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events.

Key Subcategories

DE.CM-01: Networks and network services are monitored to find potentially adverse events
DE.CM-02: The physical environment is monitored to find potentially adverse events
DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events
DE.CM-06: External service provider activities and services are monitored to find potentially adverse events
DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events

Security Engineer Takeaway: Deploy layered monitoring: SIEM for log aggregation and correlation, EDR for endpoint visibility, NDR for network traffic analysis, and UEBA for anomalous behaviour detection. Don't forget to monitor third-party/cloud services (DE.CM-06). The goal is visibility across all attack surfaces — you can't respond to what you can't see.

DE.AE Adverse Event Analysis Important ▶

Anomalies, indicators of compromise, and other potentially adverse events are analysed to characterise the events and detect cybersecurity incidents.

Key Subcategories

DE.AE-02: Potentially adverse events are analysed to better understand associated activities
DE.AE-03: Information is correlated from multiple sources
DE.AE-04: The estimated impact and scope of adverse events are understood
DE.AE-06: Information on adverse events is provided to authorised staff and tools
DE.AE-07: Cyber threat intelligence and other contextual information are integrated into the analysis
DE.AE-08: Incidents are declared when adverse events meet the defined incident criteria

Security Engineer Takeaway: Analysis turns raw alerts into actionable incidents. Build correlation rules, integrate threat intelligence feeds (MITRE ATT&CK, ISACs), and establish clear incident declaration criteria (DE.AE-08). Key metrics: false positive rate, mean time from alert to triage, and percentage of alerts auto-resolved. Use SOAR platforms to automate repetitive analysis tasks and free analysts for complex investigations.

RS.MA Incident Management Core ▶

Responses to detected cybersecurity incidents are managed.

Key Subcategories

RS.MA-01: The incident response plan is executed in coordination with relevant third parties once an incident is declared
RS.MA-02: Incident reports are triaged and validated
RS.MA-03: Incidents are categorised and prioritised
RS.MA-04: Incidents are escalated or elevated as needed
RS.MA-05: The criteria for initiating incident recovery are applied

Security Engineer Takeaway: Your IR plan must be tested, not just documented. Conduct tabletop exercises quarterly and full-scale simulations annually. Key processes: triage (is it real?), categorisation (what type?), prioritisation (how urgent?), escalation (who needs to know?), and recovery initiation criteria (when do we shift from response to recovery?). Integrate regulatory reporting timelines (NIS2 24h, DORA 4h) into your escalation procedures.

RS.AN Incident Analysis Core ▶

Investigations are conducted to ensure effective response and support forensics and recovery activities.

Key Subcategories

RS.AN-03: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
RS.AN-06: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
RS.AN-07: Incident data and metadata are collected, and their integrity and provenance are preserved
RS.AN-08: An incident's magnitude is estimated and validated

Security Engineer Takeaway: Forensic readiness is key. Ensure you can collect and preserve evidence (memory dumps, disk images, network captures, logs) with chain-of-custody procedures. Use forensic tools that maintain evidence integrity. RS.AN-03 on root cause analysis should feed into ID.IM (Improvement) to prevent recurrence. Document everything — your investigation records may be required by regulators or law enforcement.

RS.CO Incident Response Reporting & Communication Important ▶

Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies.

Key Subcategories

RS.CO-02: Internal and external stakeholders are notified of incidents
RS.CO-03: Information is shared with designated internal and external stakeholders

Security Engineer Takeaway: Communication during incidents is often the weakest link. Prepare communication templates for different stakeholders: technical teams, management, customers, regulators, media. Know your regulatory reporting obligations cold: NIS2 (24h early warning), DORA (4h initial notification), GDPR (72h breach notification). Establish an out-of-band communication channel for when primary systems are compromised.

RS.MI Incident Mitigation Important ▶

Activities are performed to prevent expansion of an event and mitigate its effects.

Key Subcategories

RS.MI-01: Incidents are contained
RS.MI-02: Incidents are eradicated

Security Engineer Takeaway: Containment and eradication are time-critical. Pre-define containment actions in your playbooks: network isolation, account disablement, endpoint quarantine, DNS sinkholing. For eradication: remove malware, patch exploited vulnerabilities, reset compromised credentials, and rebuild affected systems. Validate that containment is effective before declaring the incident contained.

RC.RP Incident Recovery Plan Execution Core ▶

Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents.

Key Subcategories

RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process
RC.RP-02: Recovery actions are selected, scoped, prioritised, and performed
RC.RP-03: The integrity of backups and other restoration assets is verified before using them for restoration
RC.RP-04: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
RC.RP-05: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
RC.RP-06: The end of incident recovery is declared based on criteria, and incident-related documentation is completed

Security Engineer Takeaway: Recovery is where your DR plans are put to the test. RC.RP-03 is critical — verify backup integrity before restoring (attackers may have compromised backups). Define clear RTOs and RPOs for each critical service. RC.RP-05 reminds us to validate that restored systems are clean and functioning before returning to production. Always conduct a post-recovery verification to confirm the threat has been fully eradicated.

RC.CO Incident Recovery Communication Important ▶

Restoration activities are coordinated with internal and external parties.

Key Subcategories

RC.CO-03: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
RC.CO-04: Public updates on incident recovery are shared using approved methods and messaging

Security Engineer Takeaway: Transparent communication during recovery builds trust. Provide regular status updates to affected parties with estimated restoration timelines. For public-facing incidents, coordinate messaging with PR/communications teams and legal. RC.CO-04 acknowledges that public communication is often necessary — have pre-approved templates and a designated spokesperson ready.

Tier	Name	Risk Management Process	Integrated Risk Programme	External Participation
Tier 1	Partial	Ad hoc, reactive, not formalised	Limited awareness of risk at org level	Organisation does not understand its supply chain role
Tier 2	Risk Informed	Approved but not organisation-wide policy	Awareness at org level but not enterprise-wide	Understands its role but doesn't formalise participation
Tier 3	Repeatable	Formal, regularly updated, risk-informed	Enterprise-wide approach to risk management	Understands and acts upon relationships and dependencies
Tier 4	Adaptive	Adapts based on lessons learned and predictive indicators	Risk-informed culture with continuous improvement	Actively manages supply chain risks with real-time info sharing

Step	Activity	Output
1	Scope the target organisational profile based on mission, risk appetite, and regulatory requirements	Target Profile
2	Assess current state against the framework subcategories	Current Profile
3	Determine the appropriate tier for each category or overall	Tier Selection
4	Compare Current to Target and identify gaps	Gap Analysis
5	Prioritise gaps, allocate resources, and build a roadmap	Implementation Plan
6	Implement changes and measure progress over time	Continuous Improvement

Community	How They Use CSF	Key Driver
US Federal Agencies	Required by Executive Order (NIST RMF integrates with CSF)	Regulatory requirement
US Critical Infrastructure	Originally the primary audience; widely adopted across all 16 CI sectors	Best practice / Regulatory expectation
International Organisations	Used globally as a common cybersecurity language and benchmark	Best practice / Board reporting
Small & Medium Businesses	CSF 2.0 explicitly expanded scope; Small Business Quick Start Guide available	Risk management baseline
Healthcare	HIPAA crosswalk, Health Industry Cybersecurity Practices (HICP) aligned	Regulatory alignment
Financial Services	Used alongside FFIEC, SOC 2, DORA; CSF provides overarching framework	Multi-framework alignment
Technology Companies	SOC 2 / ISO 27001 mapping; customer assurance and trust reporting	Customer requirements
Education & Research	Framework for developing cybersecurity programmes at universities and labs	Grant requirements, best practice

Framework / Standard	Mapping Status	Coverage	Use Case
ISO/IEC 27001:2022	Official NIST mapping available	High — strong overlap with all functions	Multi-framework compliance; certification alignment
CIS Controls v8	Community mapping available	High — controls map to Protect and Detect	Prioritised technical controls implementation
MITRE ATT&CK	Community mapping available	Strong for Detect and Respond functions	Threat-informed defence; detection engineering
COBIT 2019	ISACA mapping available	Strong for Govern function	IT governance and management alignment
NIS2 Directive	ENISA mapping in progress	CSF covers all NIS2 Art. 21 measures	EU regulatory compliance
DORA (EU 2022/2554)	Community mapping emerging	Good coverage across functions	Financial sector EU compliance
SOC 2 Trust Criteria	AICPA mapping available	High — five trust service criteria align well	Third-party assurance reporting

Aspect	NIST CSF 2.0	NIS2	DORA	ISO 27001
Legal Status	Voluntary	Mandatory (EU Directive)	Mandatory (EU Regulation)	Voluntary (Certifiable)
Penalties	None	Up to EUR 10M / 2%	Per national law	Loss of certification
Enforcement Body	None	National competent authorities	Financial supervisors	Certification body
Who Must Comply	No one (but widely expected)	18 sectors, medium+	Financial entities	Organisations seeking certification
Key Benefit	Common language, flexibility	Legal certainty, harmonisation	Sector-specific rigour	Certification assurance
Complementary Use	Umbrella framework	Maps to CSF functions	Maps to CSF functions	Detailed control set

NIST Cybersecurity Framework 2.0 at a Glance

The Six Functions

Govern (GV) — NEW in 2.0

Identify (ID)

Protect (PR)

Detect (DE)

Respond (RS)

Recover (RC)

What Changed in CSF 2.0?

New Govern Function

Expanded Scope

Supply Chain Focus

Implementation Examples

NIST CSF 2.0 vs. Other Frameworks

The Six Functions — Deep Dive

Govern (GV) — NEW in CSF 2.0

Govern Categories

Identify (ID)

Identify Categories

Protect (PR)

Protect Categories

Detect (DE)

Detect Categories

Respond (RS)

Respond Categories

Recover (RC)

Recover Categories

Category Explorer

Govern (GV) — 6 Categories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Identify (ID) — 3 Categories

Key Subcategories

Key Subcategories

Key Subcategories

Protect (PR) — 5 Categories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Detect (DE) — 2 Categories

Key Subcategories

Key Subcategories

Respond (RS) — 4 Categories

Key Subcategories

Key Subcategories

Key Subcategories

Key Subcategories

Recover (RC) — 2 Categories

Key Subcategories

Key Subcategories

Implementation Tiers & Profiles

The Four Implementation Tiers

Framework Profiles

Current Profile

Target Profile

Gap Analysis

Community Profiles

Using Tiers and Profiles Together

Key Dates & Timeline

Implementation Checklist

Govern (GV)

Identify (ID)

Protect (PR)

Detect (DE)

Respond (RS)

Recover (RC)

Who Uses NIST CSF 2.0?

Primary User Communities

Regulatory References to NIST CSF

US Executive Orders

Sector-Specific Regulators

International Adoption

Industry Standards

Informative References & Mappings