The NIST Cybersecurity Framework is the document people cite when they want to describe a security program without committing to a specific control catalog. That flexibility is its strength. It is also why so many teams adopt it in name and then struggle to say what adopting it means.
Version 2.0, published by NIST in February 2024, organizes the framework around six functions: Govern, Identify, Protect, Detect, Respond, and Recover. This article explains what each function covers, how the parts of the framework fit together, and what the CSF does not do, so you can decide where it belongs in your program.
What the CSF is, and what it is not
The CSF is a voluntary framework published by the National Institute of Standards and Technology. Version 1.0 appeared in 2014 with a focus on critical infrastructure. Version 2.0 broadened its stated audience to organizations of any size or sector.
It describes outcomes, not controls. A subcategory says what should be true, such as data at rest being protected. It does not say which encryption, which tool, or how often to check.
Three things it is not:
Not certifiable. No accredited body issues a CSF certification. A consultant or auditor can assess you against it, but the result is an opinion, not a certificate. Treat any "CSF certified" claim with suspicion.
Not a control catalog. For prescriptive controls you need something like NIST SP 800-53 Rev. 5 or the Annex A controls of ISO/IEC 27001. The CSF points to those through informative references.
Not a checklist to complete. It is designed to be tailored. Not every outcome carries the same weight for every organization.
How the core is organized
The CSF Core is a hierarchy with three levels.
Functions. Six top-level groupings of outcomes.
Categories. 22 groupings beneath the functions, each with a two-letter code, such as PR.AA for identity management, authentication, and access control.
Subcategories. Specific outcome statements, numbered within each category, such as PR.AA-01.
Two kinds of supporting material sit alongside the Core. Implementation examples are short, illustrative actions that show one way to achieve a subcategory. Informative references map subcategories to other standards and control sets. For 2.0, NIST publishes both online rather than in the framework document itself, so they can be updated without a new version of the CSF.
The identifiers are worth adopting. When your policies, risk register, and evidence all cite the same subcategory IDs, you can answer "where do we stand on PR.AA" without calling a meeting.
The six functions, one at a time
Govern (GV)
Govern is new in 2.0. It covers how the organization sets its cybersecurity risk strategy, expectations, and policy, and how it checks that they are working. Its categories are organizational context, risk management strategy, roles and responsibilities, policy, oversight, and cybersecurity supply chain risk management.
Much of this existed in 1.1, spread across the Identify function. Pulling it into its own function signals that governance is not a preliminary step. It runs alongside everything else.
Identify (ID)
Identify is about understanding your current cybersecurity risk. Its categories are asset management, risk assessment, and improvement. Improvement is a 2.0 change: lessons from assessments, exercises, and incidents now sit here rather than being scattered across Respond and Recover.
The common failure is an asset inventory that covers servers and misses SaaS applications, data stores, and service accounts. A risk assessment built on a partial inventory is partial too.
Protect (PR)
Protect covers the safeguards that manage cybersecurity risk. Its categories are identity management, authentication, and access control; awareness and training; data security; platform security; and technology infrastructure resilience.
This is where most teams already have the most work done. It is also where they tend to over-report, because a deployed tool is easy to confuse with an achieved outcome.
Detect (DE)
Detect is about finding and analyzing possible attacks and compromises. Its two categories are continuous monitoring and adverse event analysis.
Collecting logs is not detection. The outcome is that someone, or something, looks at the events, decides which ones matter, and escalates them. If nobody would notice an alert at 2 a.m., the outcome is not met.
Respond (RS)
Respond covers the actions taken once an incident is detected. Its categories are incident management, incident analysis, incident response reporting and communication, and incident mitigation.
A written incident response plan is necessary but not sufficient. The outcome includes triage, containment, and communication happening in a coordinated way, which you can only show through exercises or real incident records.
Recover (RC)
Recover covers restoring assets and operations affected by an incident. Its categories are incident recovery plan execution and incident recovery communication.
Backups are the usual evidence offered here, and they are rarely enough on their own. A backup you have never restored is a hope, not a recovery capability.
The functions are not a sequence
The order of the functions reads like a lifecycle, and people treat it as one: govern first, then identify, then protect. NIST does not intend that. The functions are meant to operate concurrently, and NIST's own illustration draws them as a wheel with Govern at the center.
In practice this means you do not finish Identify before starting Detect. A small team with a partial inventory should still have logging and a named incident contact. The functions describe areas of work that all need some attention at once, at depths that suit your risk.
Where profiles and tiers fit
The Core describes which outcomes exist. Two other parts of the framework describe how you use it.
Organizational Profiles describe your current or target state in terms of the Core. A current profile says which outcomes you achieve today and how. A target profile says which outcomes you have chosen to prioritize. The gap between them becomes a plan. Version 2.0 also introduced Community Profiles, which are shared baselines that a sector or other community builds around a common set of concerns.
Tiers characterize how rigorous your cybersecurity risk governance and management practices are, on a four-step scale from Partial to Adaptive. They describe the organization's approach as a whole, not individual controls.
Both deserve a fuller treatment than an overview allows. The point here is that the Core alone is a vocabulary. Profiles and tiers are what turn it into a plan.
Starting with the CSF without boiling the ocean
If you are adopting the CSF for the first time, a workable sequence looks like this.
Decide why you are using it. Board reporting, customer assurance, and internal prioritization lead to different scopes. Write the reason down.
Scope the first profile narrowly. One business unit or one product is easier to assess honestly than the whole company.
Read every subcategory once. Mark each as relevant, possibly relevant, or not relevant for your scope, with a sentence of reasoning.
Describe current practice in plain words. For each relevant subcategory, write what you do today and what evidence would show it.
Pick a small number of gaps to close first. Choose by risk, not by how easy the fix is.
If you already run an ISO 27001 information security management system, much of this work exists in another form, and the CSF can sit on top of it as a reporting view. Our explainer on what an ISMS is covers that structure, and the ISO 27001 framework page outlines how certification works. Terms like subcategory, informative reference, and profile are defined in the glossary, and the NIST CSF framework page shows how the framework relates to NIST SP 800-53 and other standards.
How TrustLynce helps
TrustLynce maps controls across frameworks, so a control you implement once can be tagged to the CSF subcategories and ISO 27001 controls it supports. See compliance automation. Evidence is collected on a schedule, timestamped, and attributed, which gives each subcategory something concrete to point at.