Before last quarter's board prep, I re-cut our security operations budget against the six functions of NIST CSF 2.0. It took one afternoon, and it was the least comfortable afternoon of the quarter. Detection and response tooling, the line items I write the biggest checks for, dominated the sheet. Recovery had almost nothing against it, and governance wasn't a line at all, just an assumption.
A checklist framing turns NIST CSF 2.0 into the wrong kind of tool. NIST itself describes the CSF as outcomes to prioritize, which matters for operations and compliance language alike. A SecOps leader who reads it as a checklist will spend budget in the wrong order, because the framework's real payload for an operations team is a shared vocabulary for arguing about priorities.
In brief:
- CSF 2.0 gives teams a prioritization vocabulary for sequencing security work. NIST says so in the framework itself, and the checklist reading is how detection ends up overfunded while recovery starves.
- Govern is the new sixth function, and it's where security operations center (SOC) decision rights (who authorizes containment, who declares an incident) finally get written down instead of living in convention.
- Detect is the function SOC teams already own, and the detection-source data says nearly half of organizations still learn of a compromise from outside.
- Function-mapped budgets often make Detect visible while Recover remains easy to starve. Most private programs should check whether they have the same imbalance.
NIST CSF 2.0 is a voluntary cybersecurity framework organized into six functions, published February 26, 2024, and applicable to organizations of any size or sector. That textbook definition describes a document, while the operational value sits in the decision tool. For operations, CSF 2.0 gives teams a common language for stating a Current Profile and a Target Profile, and teams use the gap between them to sequence spend.
What changed from NIST CSF 1.1, and why it matters from the operations seat
The biggest change is that NIST CSF 1.1 had five functions, while 2.0 has six. Other changes include:
- Categories dropped from 23 to 22
- Subcategories went from 108 to 106
- Governance was pulled out into a dedicated Govern function (instead of buried inside Identify as ID.GV)
- Supply chain risk management moved from Identify into Govern (GV.SC), identity and access control got its own Protect category (PR.AA), and incident recovery plan execution (RC.RP) was significantly expanded.
- Scope widened too: 1.1 was written for critical infrastructure operators, while 2.0 applies to all organizations.
From the operations seat, the pattern behind those changes matters more than the changes themselves. Version 2.0 emphasizes decision rights and accountability, with spending mapped to risk. It turns governance from a policy appendix into an operating constraint.
Reading the six functions as operational levers for SOC decisions
The six functions read differently from the operations seat than from an auditor's workbook. For each function, ask what a SOC actually owns, then compare investment with the function's implied responsibilities and identify the operating-model changes. That keeps the mapping tied to operational decisions.
Govern: the function that didn't exist in 1.1 and where most teams will under-invest first
Govern has six categories, and the one that matters most on the SOC floor is GV.RR: roles, responsibilities, and authorities. GV.RR-02 requires roles to be established, communicated, understood, and enforced, which in SOC terms means written decision rights for containment authorization and incident declaration, with recovery ownership in the same matrix.
In the mid-market environments I've worked in, those decisions live in informal convention, and convention breaks during the first serious incident. Teams under-invest here first because it reads as governance, risk, and compliance (GRC) paperwork, but GV.RR is the category that decides who acts at 2 am.
GV.SC also affects SOC operations, because your managed detection and response (MDR) relationship now lives there. GV.SC-05 puts cybersecurity requirements into contracts, and GV.SC-07 requires supplier risk to be monitored across the relationship, so the provider's investigation quality becomes part of the operating review before renewal.
I've renegotiated MDR escalation service-level agreements (SLAs) twice, and both times the sticking point was exactly what GV.RR names: nobody on our side had written down who could approve a containment action the provider recommended. The framework makes fixing that a named outcome for the first time.
Identify: what asset and risk visibility actually requires before the framework helps
NIST's small business guidance states the dependency plainly: the asset inventory forms the foundation for the rest of the security program, and detection scope is bounded by it. DE.CM cannot monitor what ID.AM never documented, which means every SOC's coverage is incomplete by an unknown amount. Coverage claims often look better than operational coverage, because unknown or uninstrumented assets and missing telemetry sit outside the measurement.
Teams usually under-invest in telemetry verification more than in the inventory spreadsheet. A SOC can miss detections when the relevant logs were never forwarded from the affected systems, and even perfect detection logic produces nothing if the logs aren't flowing. Before buying more detection content, verify that telemetry actually arrives from everything the inventory says exists.
Protect: where the framework's sequencing breaks for mid-market SOC teams
CSF 2.0 tells organizations to address the functions concurrently, yet Protect begins from the premise that assets and risks have already been identified and prioritized. A mid-market team reading that literally will finish inventory before hardening anything, and that sequencing is wrong.
Complete asset discovery is one of the hardest problems in security, and waiting on it delays the identity controls attackers exploit today. The framework got the emphasis right, though: 2.0 broke identity management, authentication, and access control into its own category, PR.AA, which 1.1 left undifferentiated.
For resource-constrained teams, CSF's outcomes pair better with CIS Controls guidance than with a pure mapping exercise: CSF describes what to achieve, CIS is prescriptive about how. Much of what gets sold into Protect is rebadged cloud hygiene, misconfiguration dressed up as protection. Ship multifactor authentication (MFA) and identity controls now, improve the inventory in parallel, and read Protect claims with the hygiene question in hand.
Detect: the function SecOps teams think they own and the gaps they don't see
The SOC owns Detect: DE.CM (continuous monitoring) and DE.AE (adverse event analysis) are the operational core of the job. The data says ownership still lags. In Mandiant's M-Trends 2026, only 52% of organizations detected a compromise internally, so nearly half still learned of it from an external entity or the attacker.
The gaps sit where coverage claims aren't tested: broad MITRE ATT&CK coverage can still fail to prove identity coverage, and software-as-a-service (SaaS) and cloud attack surfaces need the same proof. Open Authorization (OAuth) abuse and application programming interface (API) exfiltration can play out entirely off the endpoint, as can attacks through compromised collaboration tools.
Treat detection engineering as a discipline with coverage measurement, and fund it as primary SOC work. The most budget-efficient approach is to cover the techniques threat actors use most often in your industry first, because a smaller set of well-tuned detections beats a larger set of noisy ones that feed alert fatigue. And DE.AE-08 requires incidents to be declared against defined criteria, which I still see handled by feel.
Respond: the playbooks the framework assumes you already have
RS.MA, incident management, covers alert triage and validation. It also covers categorization and escalation, plus the criteria for moving into recovery. That is playbook territory, and without built and tested response processes, people improvise under pressure. NIST finalized Special Publication (SP) 800-61r3 in 2025 as a CSF Community Profile, which makes it the closest thing NIST publishes to an operations manual for this function.
Outsourcing doesn't move the requirement. MDR contracts can improve monitoring and triage, but buyers still need internal incident response policies to get full value. RS.CO, the reporting and communication category covering regulatory notification plus legal and human resources (HR) handoffs, never leaves your building regardless of who runs triage. If your incident response plan doesn't name who executes those handoffs, the MDR contract won't cover it.
Recover: the function that gets cut from tabletops and why that matters
Recover is the function NIST expanded most, and the one operations teams underfund. RC.RP in 2.0 covers backup integrity verification, restoration prioritization by mission criticality, and recovery-completion declaration. NIST's expansion addresses a familiar failure mode: backup integrity and restoration timelines look stronger on paper than they perform during an actual incident, and recovery ownership often does too.
The investment imbalance shows up when teams use CSF as literal budget vocabulary. Function-mapped budgets can put Detect far ahead of Recover, the same pattern I see when private teams map spend by function. Recovery is easy to cut from tabletops because the SOC doesn't own it and the teams that do rarely attend. Run your next tabletop through the recovery declaration, with an actual restore test, and invite the people who own the backups.
The one change from 1.1 that SecOps leaders should act on first
Act on Govern first, in two moves, both cheap. First, write the GV.RR decision-rights matrix, naming the containment authorizer, the incident declarer, and the person who signs off that recovery is complete. That takes one working session, and it pays off in the first real incident. Second, build a Current and Target Profile and use the gap as your budget argument, the mechanism NIST's profile guidance describes for deciding what gets resourced.
Every other recommendation in this article costs money. Govern costs authority and an afternoon, and it's the mechanism that funds the rest. When I brought our function-mapped budget back to the chief information security officer (CISO) with a target profile beside it, the recovery shortfall stopped being an awkward observation and became a line item with an owner and a quarter attached. That is what the framework is built to do.
How to use the framework without turning it into a scorecard
Most private organizations use the CSF voluntarily. NIST publishes standards and guidance, and the hard mandate applies to United States (US) federal agencies under Executive Order 13800. The pressure you'll actually feel often comes from cyber insurance, where carriers increasingly ask for framework-aligned evidence over simple attestation. Use the CSF Implementation Tiers to characterize how risk gets governed.
Use the CSF to force decisions. Teams often map controls to subcategories and color a heat map, then let the artifact replace the decision the mapping was supposed to force. I've sat through too many quarterly business reviews (QBRs) where a color-coded heat map stood in for a decision. Skip the heat map this quarter and write the containment responsible, accountable, consulted, informed (RACI) instead; it costs nothing and settles who acts before an incident does.
Frequently asked questions about NIST CSF 2.0
When the framework leaves the policy document and hits the SOC roadmap, the useful answers come down to ownership and budget sequencing.
How should a SecOps team read NIST CSF 2.0?
For a SecOps team, the current framework version is the NIST Cybersecurity Framework published February 26, 2024. It organizes cybersecurity outcomes into six functions (Govern, Identify, Protect, Detect, Respond, Recover). The Core also has 22 categories and 106 subcategories, and it extends beyond critical infrastructure to organizations of any size and sector. NIST describes the outcomes as things to prioritize through Organizational Profiles.
What changed from NIST CSF 1.1 to 2.0?
The Govern function is the headline addition: governance moved out of Identify (where it lived as ID.GV) and expanded into six categories, including supply chain risk management (GV.SC). Identity and access control got a dedicated Protect category (PR.AA), and incident recovery plan execution (RC.RP) grew substantially. Scope widened to all organizations. The counts shifted from five to six functions, 23 to 22 categories, and 108 to 106 subcategories.
How does NIST CSF 2.0 apply to a security operations team?
A SOC directly owns Detect (DE.CM and DE.AE) and most of Respond (RS.MA, RS.AN, RS.MI), contributes to Identify and Recover, and feeds operational data upward into Govern. Outsourcing to an MDR provider shifts execution of Detect and parts of Respond but leaves the customer accountable for internal incident response (IR) policy and regulatory communication (RS.CO), along with governance of the MDR relationship itself under GV.SC.
Do I need to be compliant with NIST CSF 2.0?
Most private organizations use the CSF voluntarily. NIST publishes standards and guidance, while US federal agencies must use it under Executive Order 13800. In practice, cyber insurance carriers increasingly build underwriting questionnaires around CSF 2.0 and ask for documented evidence at renewal, so alignment becomes a de facto requirement for many buyers even without a legal mandate.