Skip to main content
Guide

The framework that maps to everything else.

NIST CSF 2.0 is the most practical starting point for any security program. It organizes security into six functions that map cleanly to SOC 2, ISO 27001, HIPAA, and nearly every other compliance framework you will encounter.

More Guides
What is NIST CSF? (quick definition)
Short reference: the six core functions, implementation tiers, mandatory or voluntary.
Build a Security Program
A step-by-step guide for solo IT managers and small teams starting from scratch.
SOC 2 Compliance
What SOC 2 means, the trust service criteria, and how to prepare without a consultant.
HIPAA Compliance
What HIPAA requires from tech companies, the three safeguard categories, and common mistakes.
Managing Multiple Frameworks
How to handle SOC 2, ISO 27001, and HIPAA without duplicating work.
Vendor Risk Management
Build a third-party risk program that scales without spreadsheet chaos.
Evidence Management
Organize compliance evidence with version control and cryptographic verification.
Security Questionnaire Responses
Answer vendor security assessments in minutes instead of days.

What changed in CSF 2.0.

NIST released CSF 2.0 in February 2024, and the update is more significant than a version bump. The original framework, published in 2014, was designed for critical infrastructure sectors like energy, water, and financial services. CSF 2.0 broadens the scope explicitly to all organizations, regardless of size or sector. If you are a 50-person SaaS company, this framework was designed with you in mind.

The biggest structural change is the addition of a sixth core function: Govern. The original five functions (Identify, Protect, Detect, Respond, Recover) focused on the operational side of cybersecurity. Govern adds the organizational context that was always implied but never formalized: risk management strategy, roles and responsibilities, policy oversight, and supply chain risk management.

Other notable changes include expanded supply chain risk management guidance, improved alignment with other frameworks and standards (making cross-mapping easier), new emphasis on continuous improvement and cybersecurity measurement, and better guidance on using the framework's implementation tiers as a maturity model rather than a compliance checklist.

If you built your program around CSF 1.1, the transition to 2.0 is not a complete overhaul. Your existing controls map forward. The main work is incorporating the Govern function and updating your documentation to reflect the new subcategory structure. For organizations starting fresh, CSF 2.0 provides a cleaner, more comprehensive starting point.

The six core functions explained.

The six functions are not sequential steps. They operate continuously and in parallel. Think of them as six lenses through which you examine your security program, each addressing a different dimension of how your organization manages cyber risk.

  • Govern (GV) establishes the organizational context for cybersecurity. It covers your risk management strategy, the roles and responsibilities of people involved in security decisions, the policies that guide your program, and how you manage supply chain risk. Govern is the foundation that the other five functions build on. Without clear governance, the operational functions lack direction and accountability.
  • Identify (ID) is about understanding what you need to protect. Asset management, risk assessment, business environment, and improvement processes all live here. You cannot protect what you do not know about, so Identify ensures you have a current inventory of systems, data, and third parties, along with an understanding of the risks each faces.
  • Protect (PR) covers the safeguards you implement to ensure delivery of critical services. Identity management and access control, security awareness training, data security, platform security, and technology infrastructure resilience all fall under Protect. These are the controls that prevent or limit the impact of potential cybersecurity events.
  • Detect (DE) defines how you discover cybersecurity events when they occur. Continuous monitoring, adverse event analysis, and security event detection make up this function. A strong Detect capability means you discover incidents quickly, ideally through automated alerting rather than customer reports.
  • Respond (RS) addresses what you do when an incident is detected. Incident management, analysis, reporting, mitigation, and communication are the subcategories here. Your incident response plan, communication templates, and escalation procedures all map to Respond.
  • Recover (RC) focuses on restoring services after an incident. Incident recovery plan execution and communication during recovery are the core activities. Recovery is the function most organizations under-invest in until they experience a real incident and realize their backup and restoration processes have never been tested. LukaGRC's BC/DR module instruments this function directly — BIAs, recovery plans with RTO/RPO targets, tabletop exercises, dependencies, and crisis communications. The exercise log alone closes the gap most CSF audits surface here. Open the BC/DR module ›

You can explore how these functions map to specific controls in our frameworks library, which shows the subcategory structure and cross-references to other standards you may already be working toward.

Implementation tiers — which tier to target.

NIST CSF defines four implementation tiers that describe how an organization's cybersecurity risk management practices compare to the characteristics described in the framework. These are not maturity levels in the traditional sense, and NIST explicitly states that higher tiers are not necessarily better for every organization. The right tier depends on your risk environment, your regulatory requirements, and your resources.

  • Tier 1: Partial. Risk management is ad hoc and reactive. Security decisions happen on a case-by-case basis without formal processes. There is limited awareness of cybersecurity risk at the organizational level. Most early-stage startups operate here, and that is acceptable if you do not handle sensitive data.
  • Tier 2: Risk Informed. Risk management practices are approved by management but may not be established as organizational-wide policy. There is awareness of risk, and decisions are informed by risk assessments, but processes may not be consistently applied across the organization. This is where most growing companies land after their first compliance initiative.
  • Tier 3: Repeatable. Formal policies are in place, regularly updated, and consistently applied. Risk management practices are integrated into organizational processes. The organization actively shares information with partners about cybersecurity threats. This tier is where most organizations with compliance obligations (SOC 2, HIPAA, ISO 27001) should aim.
  • Tier 4: Adaptive. The organization adapts its cybersecurity practices based on lessons learned, predictive indicators, and real-time information. Risk management is part of organizational culture and evolves continuously. This tier represents mature security programs and is typically found at larger enterprises with dedicated security teams.
Practical tip

For most small and mid-size companies, targeting Tier 3 (Repeatable) is the pragmatic choice. It demonstrates that you have formal, documented, consistently-applied security practices without requiring the investment of a Tier 4 program. When customers or auditors ask about your security maturity, being able to say you operate at NIST CSF Tier 3 with documented controls is a strong position.

Using NIST CSF as your compliance backbone.

One of the most powerful aspects of NIST CSF is that its structure maps naturally to other compliance frameworks. If you implement NIST CSF thoroughly, you have covered significant ground toward SOC 2, ISO 27001, HIPAA, and other standards. This makes it an excellent foundation for organizations that need to satisfy multiple compliance requirements.

Here is how the mapping works in practice:

  • SOC 2 Trust Services Criteria map directly to NIST CSF functions. The Security criterion (CC6, CC7, CC8) aligns with Protect and Detect. Availability maps to Protect and Recover. Confidentiality maps to Identify and Protect. If you have implemented the NIST CSF Protect function with strong access controls, encryption, and monitoring, you have covered a substantial portion of SOC 2 Security requirements.
  • ISO 27001 Annex A controls align with NIST CSF subcategories. ISO 27001's risk-based approach mirrors the Identify and Govern functions. The information security controls in Annex A map to Protect, Detect, and Respond subcategories. Organizations pursuing ISO 27001 certification after implementing NIST CSF typically find that 60-70% of the control work is already done.
  • HIPAA Security Rule safeguards correspond to specific NIST CSF subcategories. Administrative safeguards align with Govern and Identify. Technical safeguards map to Protect and Detect. The risk assessment requirement maps directly to the Identify function's risk assessment subcategory.

The practical benefit is that you implement one control once and map it to multiple frameworks rather than maintaining separate, parallel compliance programs. Our guide on managing multiple frameworks covers this in more detail, and the features overview shows how control mapping works in practice across frameworks.

Getting started with NIST CSF.

Adopting NIST CSF does not require buying expensive tools or hiring consultants. It requires a structured approach to assessing where you are, deciding where you want to be, and closing the gaps. Here is the practical process.

Step 1: Create your current profile. Assess your organization against each CSF function and subcategory. For each subcategory, document whether you have controls in place, whether they are partially implemented, or whether they do not exist yet. Be honest. This is not a document for customers or auditors. It is your internal baseline.

Step 2: Define your target profile. Based on your business requirements, regulatory obligations, and risk tolerance, decide which subcategories need to be at which implementation tier. Not every subcategory needs to be at Tier 3. A SaaS company that does not handle payment data may not need robust payment card controls. Focus your target profile on the risks that actually matter to your business.

Step 3: Conduct a gap analysis. Compare your current profile to your target profile. The gaps are your action items. Prioritize them by risk: which gaps expose you to the most significant threats? Which are required by your contractual or regulatory obligations? Which can be addressed quickly with low effort?

Step 4: Build your implementation roadmap. Turn the prioritized gaps into a project plan with owners, timelines, and measurable outcomes. Group related controls together so that work on one subcategory advances others. For example, implementing a centralized identity provider (Protect function) also supports your access review process (Govern function) and audit logging (Detect function).

Step 5: Collect evidence continuously. As you implement controls, document them with timestamped evidence mapped to the relevant CSF subcategories. This evidence becomes the proof that your controls work when it is time for an audit, a customer security review, or an internal assessment of progress.

Practical tip

Start with the Govern and Identify functions. They force you to define the organizational context that every other function depends on. A common mistake is jumping straight to Protect (implementing technical controls) without first understanding what you are protecting and why. The first two functions take the least technical effort but provide the most strategic value.

Map your controls to NIST CSF 2.0 today.

Track all six functions, map to other frameworks, and close gaps with a platform built for practitioners.

Start free trial → See how it works