NIST CSF 2.0
the six functions, the GOVERN addition, and the audit-ready evidence

NIST Cybersecurity Framework 2.0 explained

NIST Cybersecurity Framework 2.0 is the February 2024 revision of the NIST CSF, published as NIST CSWP 29. It is the first material revision since CSF 1.1 in 2018, and it changes the framework in four substantive ways. GOVERN is promoted to a sixth first-class function on equal footing with Identify, Protect, Detect, Respond, and Recover. The framing moves from critical-infrastructure-specific to sector-agnostic so adopters in healthcare, retail, education, software, manufacturing, and small business read against their context directly. Cybersecurity Supply Chain Risk Management (formerly ID.SC) moves into the new GOVERN function as GV.SC. Implementation Examples ship beneath each subcategory, the Profile model is formalised with Community Profiles for sectors and use cases, and a family of Quick-Start Guides translates the framework into actionable starting points for small business, enterprise risk management, supply chain risk, and several other contexts.

For internal AppSec teams, vulnerability management functions, GRC owners, security engineering teams, and CISOs, CSF 2.0 is the universal vocabulary that lets a single engagement record be read against multiple regulators, customers, and standards. Programmes that already operate against ISO 27001, NIST SP 800-53, or SOC 2 do not need to migrate; CSF 2.0 sits on top of the underlying control catalogue through the Informative References cross-walk.

The six core functions of CSF 2.0

CSF 2.0 organises cybersecurity activity into six core functions that together describe the lifecycle of a cybersecurity programme. The function names are the highest-level vocabulary the framework uses; the categories and subcategories beneath each function are what the work is actually planned and reported against.

The new GOVERN function in operating practice

GOVERN is the headline change in CSF 2.0. The function consolidates and expands the governance practices that were dispersed across CSF 1.1 categories, with six subcategory groups that name the operating discipline a cybersecurity programme is expected to record against. The list below is the practical content of the function, expressed in the vocabulary the framework uses and what each group looks like in a workspace-driven programme.

How CSF 2.0 differs from CSF 1.1

Programmes already operating against CSF 1.1 can adopt CSF 2.0 incrementally; the core ideas (functions, categories, subcategories, Tiers, Profiles) are stable, and the Informative References preserve the cross-walk to the underlying control catalogues. The differences below are the substantive ones the planning and the evidence pack will need to reflect.

Implementation Tiers

The four Tiers describe the rigour and integration of cybersecurity risk management practices, not the maturity of any individual control. CSF 2.0 explicitly notes that not every organisation needs Tier 4; the right Tier depends on the risk environment, the regulatory exposure, and the resourcing the GOVERN function makes available. The Tier choice is a leadership conversation that lives in GV.RM rather than a default-upward target every programme aims for.

The Profile model: Current, Target, and Community Profiles

Profiles are the planning instrument CSF 2.0 uses to translate the categories and subcategories into the organisation-specific posture. A Profile is a selection of subcategories the programme is operating against, with the evidence references that support each. Programmes that take Profiles seriously gain a planning instrument that scales across business units; programmes that treat the Profile as an annual paperwork exercise lose the prioritisation the model is designed for.

How a CSF 2.0 programme operates across the cycle

A CSF 2.0 programme runs as a structured engagement rather than an annual report. The cycle below is the practical ordering most teams follow when CSF 2.0 is treated as the operating framework rather than a reporting wrapper. The cycle compounds: each re-baseline starts from the prior Current Profile, the gap closes year over year, and the evidence pack accumulates rather than being rebuilt.

1. 1Establish the GOVERN baseline. Name the executive owner, document the cybersecurity risk management strategy, record the risk tolerance, publish the policy hierarchy, and capture the supplier oversight model. The GOVERN baseline is the input every other function reads against.
2. 2Build the Current Profile. Walk the six functions and the categories beneath each, capture what the organisation does today against each subcategory, and link the supporting evidence (control documentation, configuration baselines, scan output, training records, incident logs). The Current Profile is the honest inventory.
3. 3Build the Target Profile. Decide which subcategories the next planning cycle will move on, informed by GOVERN-stated risk tolerance, and record the destination state with the evidence the Target subcategory will produce. Borrow from a relevant Community Profile where one applies.
4. 4Run the gap analysis. Compare Current to Target subcategory by subcategory, prioritise by risk and dependency, and produce the action plan with named owners and deadlines. The gap analysis is the artefact that drives the cycle.
5. 5Operate against the action plan. Run the work as a structured engagement rather than a spreadsheet. Capture the per-action evidence as it is produced (a configuration change, a closed finding, a published policy, a completed training cohort, a tabletop exercise transcript), tagged to the subcategory it supports.
6. 6Report and re-baseline. Roll the per-subcategory progress into the leadership report, refresh the Current Profile to reflect the new state, and start the next cycle from the new baseline rather than from a blank page. The re-baseline is what makes the framework durable across leadership turnover.

Failure modes the framework is designed to surface

CSF 2.0 is forgiving on the choice of controls, the choice of Tier, and the choice of Profile. It is unforgiving about a small number of patterns that make the framework cosmetic rather than operational. The patterns below are the ones that recur across adoptions and that erode the year-over-year continuity the framework relies on.

Evidence the framework expects to see, organised against the functions

The CSF 2.0 evidence pack reads well when it is built as a side effect of the operating work rather than reconstructed at the year-end. The minimum set below maps to the subcategories examiners and customer auditors most often ask against, and the same artefacts feed parallel reads under ISO 27001, SOC 2, NIST SP 800-53, PCI DSS, and Cyber Essentials when the underlying record is structured.

How CSF 2.0 relates to ISO 27001, NIST SP 800-53, SOC 2, and the wider regime

CSF 2.0 is an outcome framework, not a control catalogue. The Informative References published with the framework cross-walk every subcategory to NIST SP 800-53, ISO 27001, COBIT, and other widely adopted standards, so a programme already operating against one of those catalogues uses CSF 2.0 as the outcome overlay rather than a competing framework. The relationships below are the ones programmes most often need to read together.

• The ISO 27001 framework page covers the certifiable Information Security Management System standard. Annex A controls map cleanly to CSF 2.0 subcategories through the Informative References, so an ISO 27001 ISMS produces most of the evidence a CSF 2.0 Profile reads against. Adoption order is usually ISO 27001 first, CSF 2.0 as the outcome overlay second.
• The NIST SP 800-53 framework page covers the security and privacy controls catalogue used for FISMA and FedRAMP. SP 800-53 is the control catalogue underneath; CSF 2.0 is the outcome framework on top. Federal and federally regulated programmes typically operate both, with SP 800-53 supplying the control selection and CSF 2.0 supplying the leadership communication.
• The SOC 2 framework page covers the AICPA Trust Services Criteria. SOC 2 examinations read against the same underlying control evidence a CSF 2.0 Profile uses; programmes operating SOC 2 already hold most of the GV.PO, GV.OV, and PR-side artefacts CSF 2.0 expects.
• The NIST CSF (1.1) framework page covers the previous CSF revision for organisations that have not yet migrated. Most of the structural concepts (functions, categories, subcategories, Tiers, Profiles) carry forward; the GOVERN function and the C-SCRM relocation are the substantive items that need explicit re-baselining when the migration runs.
• The NIST SSDF implementation guide covers SP 800-218 for software producers. SSDF practices PO, PS, PW, and RV align against CSF 2.0 subcategories under PR (Protect) and ID (Identify), so a software producer evidencing SSDF holds material evidence that reads against the CSF 2.0 Profile for the production posture.
• The CISA Secure by Design framework page covers the principles and pledge for software manufacturers. The Secure by Design executive ownership principle reads directly against CSF 2.0 GV.RR and GV.OV; the published roadmap reads against GV.PO; the Vulnerability Disclosure Policy reads against ID.RA and RS.CO.
• The CIS Controls framework page covers the prioritised defensive actions published by the Center for Internet Security. CIS Controls v8.1 maps across CSF 2.0 functions through the Informative References, and the Implementation Group (IG1, IG2, IG3) selection serves as a useful complement to the CSF 2.0 Tier and Profile decisions.
• The CISA Cybersecurity Performance Goals (CPGs) framework page covers the prioritised, voluntary baseline CISA recommends for critical infrastructure and any organisation with a comparable risk profile. CPGs v2.0 is structured against the same six CSF 2.0 functions (GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER), so the goal-to-subcategory mapping is published rather than improvised; programmes adopt CSF 2.0 as the long-term framework and the CPGs as the prioritised first wave.
• The PCI DSS framework page covers the Payment Card Industry Data Security Standard. PCI DSS requirements read against CSF 2.0 PR (Protect), DE (Detect), and RS (Respond) subcategories; a PCI DSS programme already running v4.0.1 holds material evidence that satisfies the CSF 2.0 Profile entries for in-scope cardholder data environments.

Where SecPortal fits in a CSF 2.0 programme

SecPortal is the operating layer for the CSF 2.0 cycle, not a replacement for the NIST framework or for the underlying control catalogues. The platform handles the Current Profile, the Target Profile, the gap analysis, the action plan, the per-subcategory evidence, and the leadership reporting so the cycle runs as a structured workflow rather than a slide deck refreshed quarterly. The same workspace that hosts the Profile work hosts the SAST, SCA, authenticated DAST, external scanning, and pentest evidence the DETECT and PROTECT functions consume, so the line from artefact to outcome stays traceable.

The DETECT and RESPOND functions are where most of the day-to-day vulnerability and incident work lives. Findings raised against the DE.CM (continuous monitoring) and DE.AE (adverse event analysis) subcategories need owners, deadlines, and verification evidence that walks back to the subcategory they affect. The remediation tracking workflow keeps that line auditable. The vulnerability prioritisation workflow connects the GOVERN-stated risk tolerance (GV.RM) to the per-finding action the vulnerability management function takes. The vulnerability acceptance and exception management workflow records the documented exceptions GV.RM and GV.PO require. The security leadership reporting workflow carries the GV.OV oversight cadence the new GOVERN function expects.

For internal teams running the programme, the internal security teams workspace bundles the platform with the engagement structure CSF 2.0 expects across the cycle. For the application security function that owns PR.AA, PR.DS, and the per-release authenticated DAST and SAST work the PROTECT function consumes, the AppSec teams workspace covers the same mechanics from the engineering-adjacent angle. For the GRC function that carries the cross-framework evidence pack and the GV.SC supplier risk record, the GRC and compliance teams workspace covers the audit-side discipline that turns the artefacts into a portable evidence pack. For the vulnerability management function that runs the find-track-fix-verify queue feeding DE.CM and RS.MI, the vulnerability management teams workspace covers the lifecycle-layer work the engagement record carries forward.

For security leaders carrying the GV.OV oversight cadence and the GV.RR executive accountability the new GOVERN function expects, the CISOs and security leaders workspace covers the program-level reporting model that sits on top of the CSF 2.0 operating record. For programmes that want continuous detection and trend evidence to feed the DE.CM subcategory between annual Profile re-baselines, the continuous monitoring capability and the code scanning capability produce the cadence and coverage record the function reads against. For analytical context on how vulnerability programmes age across cycles, the vulnerability management programme maturity model research covers the operating discipline that pairs with the CSF 2.0 Tier choice, and the security control drift research covers the erosion patterns that surface when the Current Profile is not refreshed across the cycle.