The NIST Cybersecurity Framework turned two in February 2026, counting from the 2.0 publication date. In those two years a remarkable number of organisations have “adopted CSF 2.0” by running a workshop, producing a slide deck, and mapping their existing ISO 27001 or SOC 2 controls to the six functions. That’s not adoption. That’s a PowerPoint exercise.
CSF 2.0 is a voluntary framework and it does not come with a certification audit. This is a problem for organisations that treat frameworks as things auditors force you to adopt, because there’s no auditor here telling you to stop skipping the hard parts. The hard parts of CSF 2.0 are the new Govern function, the Tier model that nobody reads carefully, and the Target Profile exercise that forces a security leader to articulate an opinion about where they want their programme to be in eighteen months.
This article is the programme-management schedule — the view of CSF 2.0 as something you implement over twelve to eighteen months with phased milestones, not something you “map to.” Written for CISOs, security programme managers, and deputy CISOs at US enterprises running real CSF 2.0 programmes, including the ones layering the Cyber AI Profile on top as it matures through 2026.
What’s different in CSF 2.0
Five things actually changed between CSF 1.1 and CSF 2.0. If you absorb nothing else from this section, absorb these.
The Govern function. CSF 2.0 added a sixth function alongside the original five (Identify, Protect, Detect, Respond, Recover). Govern is not a tacked-on extra. It’s a first-among-equals function covering organisational context, risk management strategy, roles and responsibilities, policy, cybersecurity supply chain risk, and oversight. It’s also the function where the most first-time CSF 2.0 adopters get stuck, because it demands governance artefacts that many security programmes don’t have in a form the framework recognises.
Audience expansion. CSF 1.1 was written with critical-infrastructure operators in mind. CSF 2.0 is explicitly written to be useful for any organisation of any size. In practice this means the language is looser in places and the applicability guidance wider. Useful; it also means that “we use CSF 2.0” means less about your organisation than it used to mean about a critical-infrastructure operator using CSF 1.1.
Profile-centric framing. The heart of CSF 2.0 adoption is the Profile concept. A Current Profile describes where you are; a Target Profile describes where you intend to be; the gap between them is your programme. Community Profiles (including the Cyber AI Profile and the sector-specific profiles NIST has published for manufacturing, financial services, and telecommunications) provide pre-built starting points.
Tier model clarified. CSF still uses a four-tier implementation model (Partial, Risk Informed, Repeatable, Adaptive), but the 2.0 revision makes clear these are not maturity ratings. Tier 4 (Adaptive) is not a goal state for every organisation — for many, Tier 3 (Repeatable) is the appropriate target given their risk appetite and resources. This distinction matters, and most organisations get it wrong.
Informative References. The underlying mappings to NIST SP 800-53, ISO 27001, and other frameworks are now maintained as a separate, frequently-updated resource rather than baked into the framework itself. This makes cross-mapping easier and more current but means you’ll want to pull the latest Informative References when you start your programme rather than relying on what the framework PDF shows.
The programme schedule at a glance
Twelve to fourteen months is realistic for a substantive CSF 2.0 programme at a mid-sized enterprise (500–5,000 employees). Organisations with mature existing security programmes can compress to ten; organisations starting from scratch routinely run sixteen to eighteen.
Phase 1: Current state profile Months 1–2
Phase 2: Target state and gap analysis Months 2–4
Phase 3: Implementation across 6 functions Months 3–12
Phase 4: Ongoing improvement Month 12+The shape to notice: Phase 3 runs long and overlaps Phase 2 heavily. The framework is not something you design fully before implementing; gap work in Phase 2 shapes implementation priorities in Phase 3 while implementation in Phase 3 reveals gaps Phase 2 missed. Plan for iteration.
Phase 1: Current state profile (months 1–2)
Two months to produce an honest Current Profile.
A Current Profile is a CSF 2.0 self-assessment against the framework’s Subcategories — the level below Categories, which sit beneath Functions. Each Subcategory gets an evaluation: is this outcome being achieved, partially achieved, or not achieved? Supporting evidence, observations about how the outcome is achieved (or isn’t), and notes on dependencies.
The honest work in Phase 1 is resisting the temptation to score everything “partially achieved.” Security programmes that have never done this exercise have a consistent failure mode: when in doubt, split the difference. An “achieved” rating needs evidence; a “not achieved” rating needs acknowledgement; “partially achieved” needs description of what’s partial and why. A Current Profile where every Subcategory is partially achieved is a document nobody can act on.
Scope. The Profile applies to an organisational unit — which can be the whole enterprise, a business unit, or a specific system. For first-time programmes, a business unit or product line is a better starting scope than “the whole company.” Expand in later cycles.
Organisational context (the Govern warm-up). Before or alongside the Subcategory assessment, document the organisation’s mission, objectives, internal and external stakeholders, legal and regulatory requirements, risk appetite, and cybersecurity roles. This is where the Govern function starts getting built, and where many programmes realise their existing governance artefacts are scattered across a dozen documents written in different styles.
Evidence gathering. The Subcategory ratings are only as good as the evidence behind them. Pull control documentation from whatever frameworks you already operate (SOC 2, ISO 27001, HIPAA, PCI DSS). If a Subcategory maps to a control you already run, the evidence exists somewhere. If it doesn’t map, either the Subcategory is genuinely a gap or your existing framework doesn’t cover the outcome CSF cares about — worth noting either way.
Phase 2: Target state profile and gap analysis (months 2–4)
Two months to decide what “good” looks like and measure the distance to it.
The Target Profile is an opinion, not a calculation. It says: given our mission, risk appetite, stakeholder requirements, and resources, here is the state we intend to reach in the time horizon of this programme. It specifies which Subcategories we expect to achieve, which we expect to partially achieve, which we consciously choose to leave unaddressed, and what Tier we’re targeting.
Most programmes struggle here because most programmes have never been asked to state a position this directly. It feels risky to write “we accept that we will not achieve this outcome” on paper. It feels safer to aspire to achievement on every Subcategory. Aspirational Target Profiles are the second-most common failure mode in CSF 2.0 adoption (after theatre-only Current Profiles).
The right approach: rank Subcategories by the combination of risk reduction and feasibility. Target fully the top third. Target partial achievement on the middle third. Explicitly de-prioritise the bottom third with a documented rationale. The rationale is usually a combination of low residual risk, acceptable compensating controls, or resource constraint — and it’s an auditable artefact in its own right.
Community Profiles. If a NIST Community Profile exists for your sector, start from it. The Manufacturing Profile, Financial Services Profile, and Telecommunications Profile each pre-map Subcategory targets to sector-specific threats and obligations. Using a Community Profile as a starting point is not lazy — it’s sensible. Customise from the baseline rather than building from blank.
Gap analysis. For each Subcategory where Current differs from Target, document the gap, the work required to close it, the estimated effort, the dependencies, and the risk accepted if the gap remains open. The gap register becomes the input to Phase 3.
Tier selection. Pick a Tier that matches your risk appetite. Tier 2 (Risk Informed) is appropriate for most mid-sized organisations without high regulatory exposure. Tier 3 (Repeatable) is appropriate for regulated organisations and larger enterprises. Tier 4 (Adaptive) is expensive to achieve and maintain and is appropriate for critical-infrastructure operators, defence contractors, and organisations whose business model depends on adaptive security (major financial services, for example). Choosing Tier 4 because it sounds best is a common expensive mistake.
Phase 3: Implementation across the six functions (months 3–12)
Nine months of delivery against the gap register. Some observations by function.
Govern. The heaviest lift for organisations new to CSF 2.0. Expect to produce or substantially refresh: an information security policy, a cybersecurity risk management strategy, a supply chain risk management programme, a roles-and-responsibilities document, and an oversight mechanism (typically a reporting line to the board or a board committee). None of these are technical controls. All of them are governance artefacts, and none of them exist in a form NIST recognises unless someone writes them.
Identify. Asset management (hardware, software, data, services), business environment mapping, governance (overlaps with Govern), risk assessment, risk management strategy. Existing SOC 2 or ISO 27001 programmes typically cover 60–70% of this function; the gaps are usually in asset inventory completeness and in the formality of the risk assessment methodology.
Protect. The biggest function by volume of Subcategories. Identity management, awareness and training, data security, information protection processes, maintenance, protective technology. Most existing security programmes have substantial Protect coverage already; CSF 2.0 implementation is typically about filling narrow gaps rather than standing up the function from scratch.
Detect. Anomalies and events, continuous monitoring, detection processes. This function is where resource-constrained programmes often have real gaps — particularly in continuous monitoring breadth and in formal detection process documentation.
Respond. Response planning, communications, analysis, mitigation, improvements. Incident response plans exist in most organisations; incident response plans that satisfy CSF 2.0’s specificity requirements — documented communications procedures, defined stakeholder roles, post-incident improvement processes — are rarer.
Recover. Recovery planning, improvements, communications. The smallest function and the one most commonly under-developed. Recovery plans exist in name in most organisations and meaningfully in few. Business continuity documentation is relevant here, and integration between security recovery and IT disaster recovery is a common gap.
The pragmatic position: don’t implement the functions in order. Implement in dependency order — Govern first (because everything else depends on the governance foundation), then Identify (because you can’t protect what you haven’t catalogued), then the other four functions in parallel based on where your biggest risks sit.
Phase 4: Ongoing improvement (month 12+)
CSF 2.0 is built around continuous improvement. The framework expects you to refresh the Current Profile annually (or after significant changes), update the Target Profile as strategy evolves, run gap analyses on a rolling basis, and adjust Tier targeting as the organisation matures.
In practice, a healthy ongoing cycle looks like: quarterly Current Profile sampling (a rotating subset of Subcategories reassessed each quarter), annual Target Profile review (is the target still right?), a rolling risk register that feeds back into gap prioritisation, and a yearly board-level or executive-level governance review.
Where the Cyber AI Profile layers in
In December 2025, NIST published the preliminary draft of NISTIR 8596, the Cybersecurity Framework Profile for Artificial Intelligence (the Cyber AI Profile). The public comment period closed on 30 January 2026. An initial public draft is expected later in 2026, followed by a final version.
What it is: a Community Profile applying CSF 2.0 to three focus areas — securing AI systems, using AI to enhance cyber defence, and defending against AI-enabled cyber attacks. In parallel, NIST is developing SP 800-53 Control Overlays for Securing AI Systems (COSAiS) to provide implementation-level control guidance alongside the Profile’s outcome-oriented approach.
How it fits into a CSF 2.0 programme: the Cyber AI Profile is an overlay on your existing Profile work. It does not replace Phase 1 through Phase 4 of the programme described above. It adds AI-specific considerations to the Current Profile assessment (are we achieving outcomes related to AI system security, AI-enabled defence, and AI-attack resilience?), adds AI-specific targets to the Target Profile, and adds AI-specific gap work to Phase 3 implementation.
The honest guidance for organisations starting CSF 2.0 programmes now: do not wait for the Cyber AI Profile to finalise. The framework is voluntary and iterative — you can adopt CSF 2.0 core now and layer the Cyber AI Profile in later, or you can use the preliminary draft as input to your Target Profile work today and refresh as the final publishes. What you should not do is stall a twelve-month programme on a document that is still several months from final.
Cross-mapping to ISO 27001 and NIST 800-53
CSF 2.0 Informative References map Subcategories to controls in other frameworks. The mappings to ISO/IEC 27001:2022 Annex A and to NIST SP 800-53 are the most commonly used.
For an organisation running both ISO 27001 and CSF 2.0: the crosswalk is your friend. Where your ISO 27001 programme already addresses an Annex A control that maps to a CSF 2.0 Subcategory, your CSF 2.0 Subcategory assessment is largely done. For organisations running NIST 800-53 (federal contractors, FedRAMP-authorised SaaS): the mappings are denser and the overlap is higher. An organisation at NIST 800-53 Moderate or High baseline is typically well-placed for Tier 3 CSF 2.0 achievement with limited additional work.
The mapping document is maintained and updated between framework revisions. Always pull the current version from NIST rather than relying on an older static export.
Common CSF 2.0 adoption mistakes
Five patterns account for most CSF 2.0 programmes that don’t deliver real value.
PowerPoint adoption. A workshop, a slide deck, a mapping-to-existing-controls exercise, and a declaration of adoption. No Current Profile, no Target Profile, no gap register, no implementation schedule. Adoption by announcement rather than by delivery. Mitigation: treat CSF 2.0 as a twelve-month programme with deliverables, not as a communications exercise.
Targeting Tier 4 because it sounds best. Organisations whose risk profile and resources genuinely suit Tier 2 or Tier 3 target Adaptive, fall short, and declare the programme a failure. Mitigation: select the Tier that matches your risk appetite and stick with it. Tier advancement is a deliberate multi-year project, not a Target Profile default.
Skipping the Govern function because it feels abstract. Govern is the function where the real governance artefacts live — policy, strategy, roles, oversight. It’s also the function where writing is hard. Programmes that skip it or treat it as overhead discover at Phase 4 review that their CSF 2.0 adoption is technically comprehensive and governance-hollow. Mitigation: sequence Govern first in Phase 3. Write the documents.
Mapping without measuring. Existing controls get mapped to CSF Subcategories, and the mapping itself gets treated as evidence that the Subcategory is achieved. But an existing control can partially address a Subcategory, or address it in a different context, or address a different outcome entirely. Mitigation: every Subcategory rating needs a specific evidence reference, not a mapping reference.
Treating CSF 2.0 as a regulatory substitute. It isn’t. CSF 2.0 doesn’t certify you against anything and doesn’t replace SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP, or any other compliance obligation. Running CSF 2.0 alongside existing obligations is the useful pattern; using CSF 2.0 to avoid running them is not.
The underlying pattern: CSF 2.0 rewards programmes that treat it as a strategic exercise and punishes programmes that treat it as a compliance one. There is no auditor at the end forcing rigour. If you want rigour, you bring it yourself.
FAQ
Is CSF 2.0 mandatory?
No. It’s a voluntary framework. There is no external certification. Federal agencies are required to implement CSF via Executive Order 14028, and some federal contractors carry flowdown requirements, but the core framework is voluntary for most organisations.
What changed between CSF 1.1 and CSF 2.0?
The most significant change is the addition of the Govern function alongside the original five (Identify, Protect, Detect, Respond, Recover). CSF 2.0 also broadened the audience beyond critical infrastructure, restructured Tier guidance, and reorganised the Profile concept as the central adoption tool.
Do I need CSF 2.0 if I already have ISO 27001 or SOC 2?
You don’t need it. You may still want it. CSF 2.0 is useful as a strategic and governance framework sitting alongside control-focused frameworks like ISO 27001 or SOC 2. It provides a vocabulary for board-level cybersecurity conversation that ISO 27001 doesn’t provide as naturally.
What’s the Cyber AI Profile?
A Community Profile (NISTIR 8596) applying CSF 2.0 to AI-specific cybersecurity concerns. The preliminary draft was published December 2025; the initial public draft is expected later in 2026.
What are CSF Tiers, really?
They describe how well-integrated cybersecurity risk management is with broader enterprise risk management. Tier 1 (Partial) is ad-hoc; Tier 4 (Adaptive) is continuously improving and risk-informed at every level. Tiers are not maturity ratings and most organisations should target Tier 2 or Tier 3.
How long does CSF 2.0 implementation take?
Twelve to fourteen months is realistic for a first-time programme at a mid-sized enterprise. Mature organisations compress; starting-from-scratch organisations run sixteen to eighteen.
Is CSF 2.0 certification a thing?
No. CSF 2.0 is a voluntary framework without a formal certification regime. Some consultancies offer “CSF 2.0 readiness assessments” or “CSF 2.0 maturity assessments,” but these are commercial services, not certifications recognised by NIST.
How does CSF 2.0 map to SP 800-53?
The Informative References document maintained by NIST provides the current mapping. Every CSF 2.0 Subcategory maps to one or more SP 800-53 controls. Pull the current version from NIST; the mappings update between framework revisions.
Does CSF 2.0 replace the AI Risk Management Framework?
No. The AI RMF (AI 100-1) and the Cyber AI Profile are complementary — AI RMF addresses AI risks broadly; the Cyber AI Profile addresses the cybersecurity-specific intersection between AI and the CSF. Organisations running serious AI programmes typically use both.
Is CSF 2.0 right for a small business?
Yes, though the effort is proportional. A 50-person company won’t run the twelve-month programme described here — a compressed three-month version covering just the core functions is more appropriate. The framework is designed to scale down.