When NIST released version 2.0 of its Cybersecurity Framework in February 2024, it was the most significant revision since the original 2014 release.
The headline change was the addition of a sixth function — GOVERN — but that addition was not cosmetic. It represented a fundamental shift in how NIST characterises cybersecurity: from a technical discipline managed by IT departments to a governance and enterprise risk management concern that starts with the board and flows down through the organisation.
Every other function (Identify, Protect, Detect, Respond, Recover) depends on the governance structures that GOVERN establishes. Controls deployed without leadership mandate, resource allocation, and supply chain oversight are controls operating in a vacuum.
The NIST Cybersecurity Framework is the most widely referenced cybersecurity framework in the United States and increasingly adopted globally — used by 46% of US organisations as their primary framework, required for US federal civilian agencies under Executive Order 14028, and underpinning CMMC 2.0 for defence contractors.
CSF 2.0 also expanded its intended audience: where version 1.1 was written primarily for critical infrastructure operators, version 2.0 explicitly targets organisations of all sizes, sectors, and levels of cybersecurity maturity. A ten-person accountancy firm and a Fortune 500 manufacturer can both use it meaningfully.
This guide covers the complete NIST CSF 2.0: every function's categories and key subcategories with practical implementation guidance; the four implementation tiers with real-world descriptions of what each looks like; how to build Current and Target Profiles and run a gap analysis; a mapping to ISO 27001:2022 and CIS Controls v8; and a phased implementation roadmap that generates measurable progress within 90 days.
- CSF 2.0 structure — functions, categories, and subcategories
- GOVERN — the new sixth function
- IDENTIFY — know your assets and risks
- PROTECT — implement safeguards
- DETECT — find cybersecurity events
- RESPOND — act on detected incidents
- RECOVER — restore operations
- Implementation tiers — measuring maturity
- Profiles — current state vs target state
- Gap analysis template and scoring
- Mapping CSF 2.0 to ISO 27001 and CIS Controls
- Implementation roadmap — 90-day quick-start
- Frequently asked questions
The framework has three levels of specificity. Functions are the six high-level outcomes (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER). Each function contains categories — 22 in total — which are groups of cybersecurity outcomes aligned to programme or operational needs. Each category contains subcategories — 106 in total — which are specific technical or process outcomes. Subcategories are the level at which organisations assess their current state and identify gaps.
| Function | Abbr. | Categories | Subcats | Core question |
|---|---|---|---|---|
| GOVERN ⭐NEW | GV | 6 | 23 | How is cybersecurity risk managed, communicated, and integrated into enterprise decisions? |
| IDENTIFY | ID | 4 | 21 | What assets, risks, and context does the organisation need to understand? |
| PROTECT | PR | 5 | 32 | What safeguards protect critical services and assets from cybersecurity events? |
| DETECT | DE | 3 | 13 | How does the organisation find cybersecurity events when they occur? |
| RESPOND | RS | 4 | 17 | How does the organisation contain and address detected cybersecurity incidents? |
| RECOVER | RC | 2 | 6 | How does the organisation restore capabilities and services after a cybersecurity incident? |
Each subcategory is identified by a three-part code: Function abbreviation, Category abbreviation, and subcategory number. For example, GV.OC-01 = GOVERN function, Organisational Context category, subcategory 01. This coding system allows precise mapping to other frameworks, policies, and controls.
GOVERN is the foundation for everything else in the framework. It establishes the context in which cybersecurity decisions are made — the organisation's mission, regulatory environment, risk appetite, and stakeholder expectations. Without GOVERN, the other five functions are technical activities disconnected from business objectives. GOVERN is what makes cybersecurity a board-level conversation rather than an IT department activity.
Understand the environment in which cybersecurity decisions are made — the organisation's mission, the regulatory requirements it operates under, the stakeholders whose expectations must be met, and the dependencies (suppliers, customers, partners) that create risk.
- GV.OC-01: The organisational mission is understood and informs cybersecurity risk management — cybersecurity decisions are grounded in what the organisation exists to do, not just what IT manages
- GV.OC-02: Internal and external stakeholders are identified, and their needs, expectations, and requirements regarding cybersecurity are understood and considered
- GV.OC-03: Legal, regulatory, contractual, and other cybersecurity obligations of the organisation are understood and managed
- GV.OC-04: Critical objectives, capabilities, and services that stakeholders expect to be delivered are understood and communicated
- GV.OC-05: Outcomes, capabilities, and services that the organisation depends on are understood and communicated — identifies dependencies that create supply chain risk
Define the organisation's approach to managing cybersecurity risk — the risk appetite, risk tolerance, and the strategy for making consistent risk decisions across the organisation.
- GV.RM-01: Risk management objectives are established and agreed to by organisational stakeholders — leadership defines what risk is acceptable
- GV.RM-02: Risk appetite and risk tolerance statements are established, communicated, and maintained — "we will accept risks below X; risks above Y must be escalated to the board"
- GV.RM-03: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes — cybersecurity risk sits alongside operational, financial, and reputational risk
- GV.RM-06: A standardised approach to calculating, documenting, categorising, and prioritising cybersecurity risks is established and communicated
- GV.RM-07: Strategic opportunities (positive risks) are characterised and are included in organisational cybersecurity risk discussions
The supply chain categories were significantly expanded in CSF 2.0, reflecting how supply chain attacks (SolarWinds, XZ Utils, 3CX) have become a dominant threat vector. Every organisation's cybersecurity posture is partly determined by the security of its suppliers, software vendors, cloud providers, and managed service providers.
- 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-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 — not all suppliers represent equal risk; tier them by what they access
- GV.SC-06: Planning and due diligence are performed 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, and communicated to appropriate stakeholders
- 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
You cannot protect what you do not know you have. IDENTIFY establishes the foundation for all security decisions by inventorying assets, understanding business dependencies, and conducting risk assessments that inform what to protect and how intensely.
- ID.AM-01: Inventories of hardware managed by the organisation are maintained — every endpoint, server, network device, and IoT device
- ID.AM-02: Inventories of software, services, and systems managed by the organisation are maintained — including cloud services (SaaS, PaaS, IaaS)
- ID.AM-03: Representations of the organisation's authorised network communication and internal and external network data flows are maintained — network topology diagrams, data flow maps
- ID.AM-04: Inventories of services provided by suppliers are maintained — third-party services that process or store organisational data
- ID.AM-05: Assets are prioritised based on classification, criticality, resources, and impact on the mission — not all assets are equal; tier them by business impact
- ID.AM-07: Inventories of data and corresponding metadata for designated data types are maintained — know where sensitive data lives
- ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles — procurement through secure disposal
- ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded — ongoing vulnerability scanning and assessment
- ID.RA-02: Cyber threat intelligence is received from information-sharing forums and sources — ISAC memberships, CISA alerts, threat intel feeds
- ID.RA-03: Internal and external threats to the organisation are identified and recorded — both technical threats and human/environmental threats
- ID.RA-04: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded — formal risk scoring
- ID.RA-05: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform prioritisation — the risk register drives the programme
- ID.RA-06: Risk responses are chosen, prioritised, planned, tracked, and communicated — risk treatment decisions are made and monitored
- ID.RA-07: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked — change management feeds risk awareness
New in CSF 2.0: Improvement recognises that cybersecurity programmes must continuously learn and adapt from incidents, exercises, and assessments.
- ID.IM-01: Improvements are identified from evaluations — vulnerability scans, penetration tests, and assessments inform programme improvements
- 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, procedures, and activities — lessons learned from day-to-day operations
- ID.IM-04: Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
PROTECT contains the largest number of subcategories (32) because it covers all the technical and procedural controls that prevent or limit the impact of cybersecurity events. It is the function most familiar to security teams — but CSF 2.0 reorganised it significantly, renaming Access Control to Identity Management and Access Control (PR.AA) and adding Technology Infrastructure Resilience (PR.IR) as a new category.
- PR.AA-01: Identities and credentials for authorised users, services, and hardware are managed by the organisation — complete identity lifecycle management
- PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions — identity verification commensurate with risk
- PR.AA-03: Users, services, and hardware are authenticated — MFA for privileged access; phishing-resistant MFA for high-risk accounts
- PR.AA-04: Identity assertions are protected, conveyed, and verified — token security, certificate management, federation
- PR.AA-05: Access permissions, entitlements, and authorisations are defined in a policy, managed, enforced, and reviewed — least-privilege access with regular review
- PR.AA-06: Physical access to assets is managed, monitored, and enforced commensurate with risk — badge access, visitor logs, server room controls
- PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected — encryption of sensitive data at rest
- PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected — TLS for all data in transit; VPN for remote access
- PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected — memory protection, secure enclaves for sensitive processing
- PR.DS-11: Backups of data are created, protected, maintained, and tested — 3-2-1 backup rule; quarterly restoration tests with documented results
- PR.PS-01: Configuration management practices are established and applied — hardened baseline configurations for all systems; CIS Benchmarks as reference
- PR.PS-02: Software is maintained, replaced, and removed commensurate with risk — patch management with defined SLAs; end-of-life software retired
- PR.PS-03: Hardware is maintained, replaced, and removed commensurate with risk — hardware lifecycle management; secure disposal
- PR.PS-04: Log records are generated and made available for continuous monitoring — centralised logging; SIEM for correlation and alerting
- PR.PS-05: Installation and execution of unauthorised software are prevented — application whitelisting or allowlisting; endpoint protection
- PR.PS-06: Secure software development practices are established and integrated into the software development life cycle — DevSecOps; SAST/SCA/DAST in CI/CD
New in CSF 2.0: Infrastructure resilience recognises that cybersecurity must account for availability and continuity — not just confidentiality and integrity.
- PR.IR-01: Networks and environments are protected from unauthorised logical access and usage — network segmentation, firewall rules, zero trust principles
- PR.IR-02: The organisation's technology assets are protected from environmental threats — physical security, environmental controls, power resilience
- PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations — redundancy, failover, load balancing
- PR.IR-04: Adequate resource capacity to ensure availability is maintained — capacity planning; cloud auto-scaling; DoS mitigation
DETECT covers monitoring and analysis — the function that tells the organisation that something is happening. CSF 2.0 simplified DETECT from three categories to two, focusing on continuous monitoring (collecting and reviewing security signals) and adverse event analysis (determining whether a detected anomaly is actually a cybersecurity incident).
- DE.CM-01: Networks and network services are monitored to find potentially adverse events — network traffic analysis, IDS/IPS, NetFlow monitoring
- DE.CM-02: The physical environment is monitored to find potentially adverse events — CCTV, access control logs, environmental sensors
- DE.CM-03: Personnel activity and technology usage are monitored to find potentially adverse events — UEBA, DLP, endpoint telemetry
- DE.CM-06: External service provider activities and services are monitored to find potentially adverse events — MSSP monitoring, cloud security posture management (CSPM)
- DE.CM-09: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events — EDR telemetry, SIEM correlation rules, container runtime monitoring (Falco)
- DE.AE-02: Potentially adverse events are analysed to better understand associated activities — SIEM triage; SOC analyst investigation; threat hunting
- DE.AE-03: Information is correlated from multiple sources — log aggregation; SIEM correlation rules; enrichment with threat intelligence
- DE.AE-04: The estimated impact and scope of adverse events are understood — blast radius assessment; affected asset count; data involved
- DE.AE-06: Information on adverse events is provided to authorised staff and tools — escalation to CSIRT; integration with SOAR for automated response
- DE.AE-07: Cyber threat intelligence and other contextual information are integrated into the analysis of adverse events — TIP integration; IOC enrichment in SIEM
- DE.AE-08: Incidents are declared when adverse events meet the defined incident criteria — clear incident declaration thresholds documented in the IRP
RESPOND covers the actions taken once an incident is declared. The key addition in CSF 2.0 is RS.CO — communications — which reflects hard lessons from high-profile incidents where poor communications (late notification of customers, failure to notify regulators within mandatory windows) amplified the damage beyond the technical breach itself.
- RS.MA-01: The incident response plan is executed in coordination with relevant third parties once an incident is declared — activate IRP; engage IR retainer; notify legal
- RS.MA-02: Incident reports are triaged to support analysis of incidents, prioritisation of incident response activities, and coordination with relevant third parties
- RS.MA-03: Incidents are categorised and prioritised — P1 (critical, all hands), P2 (significant, team response), P3 (minor, normal handling)
- RS.MA-04: Incidents are escalated or elevated as needed — clear escalation criteria; CISO, legal, and board notification thresholds defined
- RS.MA-05: The criteria for initiating incident recovery are established — when is it safe to restore? Who authorises recovery commencement?
- RS.CO-02: Internal and external stakeholders are notified of incidents in a timely manner — regulatory notification (ICO: 72h for GDPR breaches; SEC: 4 business days for material incidents); customer notification SLAs
- RS.CO-03: Information is shared with designated internal and external stakeholders as defined in the incident response plan — ISAC sharing, law enforcement, CISA reporting
- RS.AN-03: Analysis is performed to establish what has occurred during an incident and the root cause of the incident — forensic investigation; log analysis; timeline construction
- RS.AN-06: Actions performed during an investigation are recorded, and the records integrity and provenance are preserved — chain of custody for forensic evidence
- RS.AN-07: Suspected and detected incidents are analysed to determine root cause — five whys; attack path reconstruction; indicator hunting
- RS.AN-08: Incidents are catalogued in a manner that supports the categorisation of incidents to inform business impact assessments and response prioritisation
- RS.MI-01: Incidents are contained — isolate affected systems; revoke compromised credentials; block attacker infrastructure
- RS.MI-02: Incidents are eradicated — remove malware; patch exploited vulnerability; rebuild compromised systems from clean baseline
RECOVER focuses on restoring normal operations in a controlled, verified manner after an incident is contained and eradicated. Restoration without verification — bringing systems back online before confirming the attacker has been removed — is a common cause of reinfection during ransomware incidents. RECOVER also includes communicating to stakeholders that operations are restored, which is as important to reputation management as the technical restoration itself.
- RC.RP-01: The recovery portion of the incident response plan is executed once initiated from the incident response process — Recovery Plan is a distinct document from the IRP; triggered by RS.MA-05
- RC.RP-02: Recovery actions are selected, scoped, prioritised, and performed — restore most critical systems first per the BIA; verify integrity before reconnecting
- RC.RP-03: The integrity of backups and other restoration assets is verified before using them for restoration — confirm backups are clean before restoring; test in isolation first
- RC.RP-04: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms — heightened monitoring post-recovery; lessons-learned session scheduled
- RC.RP-05: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed — do not declare "all clear" until evidence-based verification complete
- RC.RP-06: The end of incident recovery is declared based on criteria, and incident-related documentation is completed — formal closure with sign-off from CISO and impacted business units
- RC.CO-03: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders — status page updates; customer communications; board briefing
- RC.CO-04: Public updates regarding the recovery from a cybersecurity incident are shared using approved messages and channels — PR-approved communications; no unauthorised statements from technical staff
Implementation tiers describe the degree to which an organisation's cybersecurity risk management practices exhibit the characteristics defined in the framework. They are not a maturity model in the sense that Tier 4 is always the goal — the appropriate tier depends on the organisation's risk profile, sector requirements, and the cost-benefit of additional controls. However, Tier 1 is never acceptable for any organisation handling sensitive data.
A CSF Profile is a selection of Framework outcomes (subcategories) that an organisation has prioritised for its specific context. The Current Profile describes what outcomes are currently being achieved. The Target Profile describes the outcomes needed to meet the organisation's cybersecurity risk management goals. The gap between them is the action plan.
Review all 106 subcategories. For each, ask: is this outcome relevant to our organisation? If yes, what tier (1–4) should we achieve for this outcome given our risk profile and sector? The result is a table of subcategories with target tier ratings. Reference sector-specific profiles published by NIST (financial services, healthcare, manufacturing) and align with any regulatory requirements (HIPAA, PCI DSS, CMMC) that map to CSF subcategories.
For each subcategory in the Target Profile, assess the current tier achieved. This is a structured self-assessment — review evidence of current practice for each subcategory: policies, procedures, logs, test records, vendor agreements. Interview system owners and department heads. Be honest about the current state — optimism in the assessment produces a plan that fails at implementation.
Every subcategory where Current Tier < Target Tier is a gap requiring remediation. Prioritise gaps by: risk impact (which gaps expose the highest-risk assets or most critical business functions), effort (quick wins — some gaps are documentations of existing practice rather than new controls), and regulatory obligation (gaps that create compliance exposure must be closed within regulatory timelines).
| Function | Current tier | Target tier | Gap | Biggest gap areas | Priority |
|---|---|---|---|---|---|
| GV — GOVERN | __ | 3 | __ | Risk appetite, supply chain risk programme, board reporting | __ |
| ID — IDENTIFY | __ | 3 | __ | Asset inventory completeness, risk assessment formality | __ |
| PR — PROTECT | __ | 3 | __ | MFA coverage, patch SLAs, configuration baselines | __ |
| DE — DETECT | __ | 3 | __ | SIEM coverage, alert tuning, threat hunting capability | __ |
| RS — RESPOND | __ | 3 | __ | IRP tested, comms plan, regulatory notification process | __ |
| RC — RECOVER | __ | 3 | __ | Recovery plan, backup restoration testing, comms | __ |
- GOVERN: no formal programme
- IDENTIFY: partial asset list
- PROTECT: basic AV, no MFA
- DETECT: no SIEM
- RESPOND: verbal-only IRP
- RECOVER: untested backups
- GOVERN: informal risk mgmt
- IDENTIFY: asset inventory partial
- PROTECT: MFA partial, patching inconsistent
- DETECT: basic log review
- RESPOND: IRP exists, not tested
- RECOVER: backups exist, untested
- GOVERN: board reporting needed
- IDENTIFY: risk register exists
- PROTECT: MFA deployed, gaps remain
- DETECT: SIEM deployed, tuning needed
- RESPOND: IRP tested annually
- RECOVER: DR tested, comms weak
- GOVERN: board programme, risk appetite
- IDENTIFY: CMDB + SBOM
- PROTECT: phishing-resistant MFA
- DETECT: 24/7 SOC + threat hunting
- RESPOND: playbooks per incident type
- RECOVER: quarterly DR tests
NIST publishes official mapping documents between CSF 2.0 and other major frameworks. If your organisation is pursuing multiple frameworks simultaneously, the mappings let you identify where a single control or policy satisfies requirements in both — avoiding duplicate effort. The mappings are available at the NIST CSF 2.0 reference tool (csrc.nist.gov/projects/cybersecurity-framework).
| CSF 2.0 Function / Category | ISO 27001:2022 Annex A | CIS Controls v8 | Notes |
|---|---|---|---|
| GV.OC — Organisational Context | Clause 4 (Context), 5.2 (Policy), A.5.1 | CIS 17 (Incident Response), CIS 18 (Penetration Testing) | ISO Clause 4 directly maps; CIS has no direct governance control — closest is programme management |
| GV.RM — Risk Management Strategy | Clause 6 (Planning), A.5.1, A.5.35 | No direct CIS mapping — CIS assumes controls, not risk strategy | ISO 27001 Clause 6 and the risk assessment methodology are the closest ISO equivalent |
| GV.SC — Supply Chain Risk | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 | CIS 15 (Service Provider Management) | CSF 2.0 expanded supply chain significantly; ISO A.5.19–5.23 maps closely |
| ID.AM — Asset Management | A.5.9, A.5.10, A.5.11, A.5.12 | CIS 1 (Inventory of Enterprise Assets), CIS 2 (Software Assets) | Strong mapping — CIS Controls 1 and 2 directly address ID.AM subcategories |
| ID.RA — Risk Assessment | Clause 6.1.2, A.5.35 | CIS 18 (Penetration Testing), CIS 7 (Vuln Management) | ISO Clause 6.1.2 requires the same formal risk assessment process |
| PR.AA — Identity Mgmt & Access Control | A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.5 | CIS 5 (Account Management), CIS 6 (Access Control) | Very strong mapping — ISO A.5.15–5.18 and CIS 5–6 cover the same ground |
| PR.AT — Awareness and Training | A.6.3, A.6.4, Clause 7.2, 7.3 | CIS 14 (Security Awareness and Skills Training) | Direct mapping — all three require security awareness training with records |
| PR.DS — Data Security | A.5.12, A.5.13, A.5.14, A.8.10, A.8.11, A.8.24 | CIS 3 (Data Protection) | ISO A.8.10 (deletion) and A.8.11 (masking) are new 2022 controls that map to PR.DS |
| PR.PS — Platform Security | A.8.8, A.8.9, A.8.19, A.8.25, A.8.28, A.8.32 | CIS 4 (Secure Config), CIS 7 (Vuln Mgmt), CIS 16 (App Dev Security) | Strong mapping — CIS 4 and 7 are the most directly comparable controls |
| DE.CM — Continuous Monitoring | A.8.15, A.8.16, Clause 9.1 | CIS 8 (Audit Log Management), CIS 13 (Network Monitoring) | ISO A.8.16 (monitoring) is a new 2022 control directly matching DE.CM |
| DE.AE — Adverse Event Analysis | A.5.25, A.5.26, A.8.16 | CIS 8, CIS 17 | SIEM use for DE.AE maps to ISO A.5.25 (assess IS events) and A.8.15 (logging) |
| RS — RESPOND (all categories) | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28 | CIS 17 (Incident Response Management) | ISO A.5.24–5.28 collectively cover the entire RESPOND function |
| RC — RECOVER (all categories) | A.5.29, A.5.30, A.8.13, A.8.14 | CIS 11 (Data Recovery) | ISO A.5.30 (ICT readiness for BC, new in 2022) maps directly to RC.RP |
The first 30 days establish governance and visibility. Without a documented risk appetite and a complete asset inventory, every subsequent decision is made without an accurate picture of what exists and what risk is acceptable.
- Week 1: Conduct the CSF Profile gap assessment across all 106 subcategories. Score each subcategory 1–4 for current and target tier. Produce a gap report for leadership with priorities, estimated effort, and the risk narrative for the top 10 gaps.
- Week 2: Draft and get leadership approval for a risk appetite statement (GV.RM-02). One page: what risks will we accept, what will we treat, what is our tolerance for downtime, data loss, and financial impact from a cyber incident? This drives every subsequent prioritisation decision.
- Week 3: Start the hardware and software asset inventory (ID.AM-01, ID.AM-02). Use existing CMDB data, scan the network with a discovery tool (Nmap, Lansweeper, or cloud-provider asset inventory), and build a register with owner, classification, and criticality rating for each asset.
- Week 4: Build the supplier register (GV.SC-04). List every supplier, cloud provider, and SaaS tool. Tier them by criticality: Tier 1 = access to sensitive data or critical infrastructure; Tier 2 = significant business dependency; Tier 3 = low impact. Tier 1 suppliers need security assessments within 90 days.
The middle 30 days implement the highest-impact technical controls in PROTECT and stand up basic detection capability.
- Week 5: Enforce MFA for all user accounts — push with number matching for all staff, hardware FIDO2 for privileged accounts (PR.AA-03). Block legacy authentication protocols that bypass MFA. This single control addresses the most common initial access vector.
- Week 6: Establish vulnerability scanning on a defined schedule — weekly for internet-facing assets, monthly for internal systems (PR.PS-02, ID.RA-01). Define patch SLAs: CRITICAL 48h, HIGH 7d, MEDIUM 30d. Run the first scan and triage findings against the risk appetite.
- Week 7: Deploy or configure centralised logging (PR.PS-04, DE.CM-09). If a SIEM is already in place, tune it — enable the five highest-value alert rules: failed login bursts, new admin account creation, large data transfers, connections to known-bad IPs, and log clearing events. If no SIEM exists, start with cloud-native options (Microsoft Sentinel, Splunk Cloud, AWS Security Hub).
- Week 8: Conduct a configuration baseline review for the three most critical system types (AD/Entra ID, cloud environment, endpoint standard build). Compare against CIS Benchmarks. Identify and remediate the highest-risk deviations (PR.PS-01).
The final 30 days focus on response capability — ensuring that when an incident occurs (and it will), the organisation can detect, contain, and recover in a structured, evidence-based manner.
- Week 9: Review or write the Incident Response Plan (RS.MA-01, ID.IM-04). Minimum viable IRP: incident declaration criteria, RACI chart for incident roles, communication templates (internal escalation, regulatory notification, customer notification), and contact list for legal, IR retainer, and insurance. Keep it to 10 pages — people read 10-page documents during incidents; they do not read 80-page ones.
- Week 10: Document the regulatory notification process (RS.CO-02). Map every applicable regulation to its notification timeline: GDPR 72h to ICO; SEC material incident 4 business days; HIPAA breach notification 60 days; PCI DSS 24h to card brands. Create pre-approved notification templates for each. This is the most commonly failed control in real incident response.
- Week 11: Run a tabletop exercise against the most likely incident scenario (ransomware is a sensible default for most organisations). Walk through the IRP with IT, legal, communications, and a business representative. Document findings. Close gaps before the exercise becomes a real incident response.
- Week 12: Verify backup restoration (RC.RP-03, PR.DS-11). Pick your most critical system. Restore it from backup in a test environment. Measure the RTO actually achieved versus the RTO you thought you had. Document the result. Most organisations discover during this exercise that their assumed RTO is significantly optimistic.
At 90 days, re-run the gap assessment against the CSF Profile. Measure the tier improvement per function. Report to leadership: "We moved from Tier 1.8 to Tier 2.4 average, with specific improvements in GOVERN (risk appetite established), PROTECT (MFA deployed to 100% of users), and RESPOND (IRP tested for first time)." This evidence-based progress narrative is what turns cybersecurity from a cost centre into a governable risk function. Repeat quarterly.
⚡ Start your NIST CSF 2.0 programme — first four actions
- Download the official CSF 2.0 document and reference tool — both free. The full framework document is available at nist.gov/cyberframework. The online reference tool at the NIST CSF website lets you browse subcategories, filter by function, and export cross-framework mappings. Spend one hour reading the GOVERN function first — it is the section most organisations have never engaged with and where the biggest governance gaps typically lie.
- Run the six quick-assessment questions from Section 10 with your leadership team. Print the six questions (one per function), bring them to your next security meeting, and answer them honestly. The pattern of answers tells you your approximate tier per function and where to concentrate the first 30 days of effort. GOVERN is almost always the biggest gap — and the cheapest to close (it is mostly documentation and process, not technology spend).
- Build your Current Profile using the template in Section 9. Score all 106 subcategories 1–4 for current tier. This takes approximately half a day for a small team familiar with the environment. The output is a gap report that prioritises the year's work, can be reported to the board as a heat map, and provides the baseline against which progress is measured quarterly. Without the baseline, you cannot demonstrate improvement.
- Connect the CSF to your existing framework work. If you are pursuing ISO 27001, use the mapping in Section 11 to avoid duplicating effort — a control that satisfies an ISO 27001 Annex A requirement likely satisfies a CSF subcategory too. If you are subject to US regulation (CMMC, HIPAA, FISMA), the relevant framework maps to CSF — a single control library can serve multiple compliance requirements simultaneously. ISO 27001 implementation → | Vulnerability management → | Incident response plan → | SIEM explained →
The NIST Cybersecurity Framework (CSF) is a voluntary framework developed by the US National Institute of Standards and Technology to help organisations manage and reduce cybersecurity risk. Version 2.0, released in February 2024, organises cybersecurity outcomes into six functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER), 22 categories, and 106 subcategories. Unlike ISO 27001, it has no certification body and produces no certificate — it is a flexible reference framework that organisations use to structure their security programme, identify gaps, and communicate risk to leadership. It is designed for organisations of all sizes, sectors, and maturity levels, making it the most broadly applicable cybersecurity framework available. US federal agencies are required to use it under Executive Order 14028; it is also the basis for CMMC for US defence contractors. Internationally, 89 countries reference it in national cybersecurity strategy.
The major changes in CSF 2.0 (February 2024) are: the addition of GOVERN as a sixth function (covering risk management strategy, organisational context, roles and responsibilities, policy, oversight, and supply chain risk management); significantly expanded supply chain risk management content throughout the framework; a broadened intended audience from critical infrastructure to all organisations; reorganisation and renaming of several categories and subcategories (Access Control became Identity Management and Access Control; a new Technology Infrastructure Resilience category was added to PROTECT; Improvement was added as a new IDENTIFY category); new Improvement subcategories that formalise lessons-learned processes; and the introduction of Community Profiles — pre-built sector-specific profiles that organisations can use as starting points. The total subcategory count changed from 108 in v1.1 to 106 in v2.0 due to consolidation and additions.
NIST CSF and ISO 27001 address the same underlying need — structured cybersecurity risk management — but differ in key ways. ISO 27001 is an international standard with a certification scheme: an accredited certification body audits your ISMS against the standard's requirements and issues a certificate valid for three years. NIST CSF is a voluntary US framework with no certification — it produces a profile and gap assessment, not a certificate. ISO 27001 is prescriptive about the management system (you must have a risk register, an SoA, internal audits, management reviews) and provides 93 Annex A controls. NIST CSF is more flexible — it provides 106 subcategories as outcomes and lets organisations choose which are relevant to their risk context. ISO 27001 is stronger for international market access (particularly EU/UK/APAC); NIST CSF is essential for US federal contractors and broadly used across US industry. The frameworks map approximately 70% to the same controls — organisations often implement both simultaneously with 30% incremental additional effort beyond one framework alone.
The four implementation tiers describe how an organisation's cybersecurity risk management practices compare to the framework's characteristics. Tier 1 (Partial): risk management is ad-hoc and reactive, no formal programme. Tier 2 (Risk Informed): practices are approved by management but inconsistently applied. Tier 3 (Repeatable): formally approved policies consistently implemented, regularly updated, supply chain risk management in place, incident response tested. Tier 4 (Adaptive): continuously improved based on threat intelligence and lessons learned, board-level oversight, active participation in information-sharing communities. The tiers are not a maturity score to maximise — the target tier should be proportionate to the organisation's risk profile. Tier 3 is appropriate for most organisations; Tier 4 is appropriate for critical infrastructure and regulated financial institutions. Tiers should be assessed per function, not as a single organisation-wide score.
A CSF Profile is a customised view of the framework's subcategories relevant to an organisation's specific risk context, sector, and objectives. A Current Profile describes the cybersecurity outcomes currently achieved. A Target Profile describes the outcomes needed to meet the organisation's goals. The gap between them is the action plan. To build one: review all 106 subcategories and determine which are relevant; for each relevant subcategory, assign a target tier (1–4) based on your risk profile and regulatory obligations; conduct an honest assessment of the current tier for each subcategory using evidence; document the gap and assign owners and target dates for remediation. NIST publishes Community Profiles — pre-built Target Profiles for specific sectors (small business, healthcare, financial services, elections) that significantly reduce the profiling effort.
The NIST CSF is voluntary for most organisations but mandatory or effectively required in several specific contexts. US federal civilian agencies are required to use it under Executive Order 14028 (2021) and related OMB guidance. DoD contractors subject to CMMC (Cybersecurity Maturity Model Certification) must implement CMMC controls, which map directly to NIST SP 800-171 and the CSF. Critical infrastructure operators in sectors regulated by CISA (energy, water, healthcare, financial services) face increasing regulatory pressure to align with CSF through sector-specific regulations. Some state-level regulations (New York's NYDFS 500, for example) reference CSF alignment as an acceptable compliance pathway. Internationally, CSF alignment is increasingly referenced in procurement contracts and enterprise supplier questionnaires as an expectation, even where not strictly mandated.