NIST CSF is the framework most other frameworks quietly borrow structure from, even when they don't cite it directly — an auditor asking about your "detection" capability or your "recovery" plan is usually reasoning in NIST CSF's vocabulary whether or not the engagement is formally scoped to it. This article covers what NIST CSF actually is, the six functions in CSF 2.0, how it differs from being a compliance mandate in its own right, and how organizations typically put it to use.
What NIST CSF is
The NIST Cybersecurity Framework, published by the U.S. National Institute of Standards and Technology, is a voluntary framework for organizing and communicating cybersecurity risk management. It does not prescribe specific technical controls the way CIS Controls does (see CIS Controls Overview); instead it provides a common structure and vocabulary for describing a security program's maturity across a defined set of functions. That structure is precisely why it gets used as an organizing layer underneath other frameworks — an auditor evaluating HIPAA or SOC 2 controls, or a cyber insurance questionnaire, is frequently implicitly mapping questions to NIST CSF functions even when the assessment itself is branded differently.
The six functions in CSF 2.0
CSF 2.0, released in 2024, added a sixth function — Govern — that sits explicitly alongside the original five, reflecting a shift toward treating cybersecurity risk management as a leadership and organizational responsibility, not purely a technical one.
| Function | What It Covers |
|---|---|
| Govern | Organizational context, risk strategy, roles and responsibilities, policy — the leadership layer that shapes how the other five functions get resourced and prioritized. |
| Identify | Understanding the assets, data, systems, and risks that need protecting — asset inventory, risk assessment, business context. |
| Protect | Safeguards that limit or contain a security event — access control, awareness training, data security, protective technology. |
| Detect | Timely discovery of security events — continuous monitoring, anomaly detection, detection process definition. |
| Respond | Actions taken once an incident is detected — response planning, communications, mitigation, analysis. |
| Recover | Restoring capabilities and services impaired by an incident — recovery planning, improvements, communications during recovery. |
Govern being added as its own function in CSF 2.0 is worth sitting with: previous versions treated governance as embedded within Identify, which understated how much a program's effectiveness depends on leadership accountability, budget decisions, and policy maintenance rather than technical execution alone. That's also the connecting thread to Governance vs. Compliance elsewhere in this cluster — NIST CSF's own 2.0 revision effectively formalized the argument that governance is a distinct, necessary function rather than an afterthought.
NIST CSF has no formal certification
Unlike SOC 2, there is no third party that certifies an organization as "NIST CSF compliant," and no formal audit produces a pass/fail result against it. NIST CSF is a framework and self-assessment structure, not an attestation program. Organizations that need a certifiable outcome typically use NIST CSF to organize the underlying program, then pursue SOC 2, a regulatory attestation, or a specific NIST publication (like 800-171 for federal contract requirements) for anything that requires formal certification.
How NIST CSF differs from being a compliance mandate
No law or contract, on its own, requires "NIST CSF compliance" in the way PCI DSS or HIPAA impose direct mandates. NIST CSF becomes relevant in three practical ways instead: some regulatory guidance and cyber insurance applications reference it as a reasonable baseline to demonstrate against; auditors and customers frequently use its six-function vocabulary to structure due-diligence conversations even under a different named framework; and organizations building a security program from scratch use it as the organizing skeleton before layering in framework-specific requirements.
How organizations typically use it
- Self-assessment — scoring current maturity against each function to identify the biggest gaps, often as the first step before a more formal readiness assessment.
- Vendor risk conversations — describing a security posture to a customer or partner's due-diligence team using shared, recognizable vocabulary rather than an internally invented framework.
- Structuring a security program — organizing budget, staffing, and roadmap decisions around the six functions so that investment isn't skewed entirely toward Protect while Detect, Respond, and Recover are neglected, which is a common and expensive imbalance.
Common mistakes
- Treating NIST CSF as something you can be "certified" in. There is no certification body; claiming certification is a factual misstatement that will not withstand scrutiny during a real due-diligence review.
- Over-indexing on Protect while neglecting Detect, Respond, and Recover. Preventive controls get the most attention and budget, but an organization with strong prevention and no tested recovery plan is still exposed to prolonged downtime after an incident.
- Skipping Govern as "just paperwork." CSF 2.0 elevated Govern to its own function specifically because programs without leadership-level ownership and policy maintenance tend to degrade over time, regardless of how strong the technical controls started out.
- Using NIST CSF language on a compliance questionnaire without an underlying program to back it up. Auditors and enterprise security teams increasingly ask for evidence mapped to specific functions, not just a claim of alignment.
FAQ
Is NIST CSF mandatory for our business? Not directly, for most private-sector organizations — it's voluntary. It becomes practically relevant when a regulator, insurer, or customer references it as an expected baseline, or when you choose to use it to structure your own program.
How is NIST CSF different from NIST 800-53 or 800-171? NIST CSF is a high-level organizing framework across six functions. NIST 800-53 and 800-171 are much more detailed, prescriptive control catalogs, with 800-171 specifically relevant to organizations handling Controlled Unclassified Information under federal contracts. Many organizations use CSF as the umbrella and one of the detailed publications for specific control implementation.
How does NIST CSF relate to Zero Trust? Zero Trust is an architectural approach concentrated heavily in the Protect (and to a degree, Detect) functions — continuous verification of identity and device trust rather than implicit network-based trust. See Zero Trust in Microsoft 365 for how that architecture is implemented in a Microsoft 365 environment specifically.