NIST CSF 2.0 checklist: outcomes to cover by Function

What a NIST CSF 2.0 checklist covers and why NIST says it is not one

When a customer, contract or board asks for NIST CSF 2.0 alignment, the working checklist is the 106 Subcategories of the CSF Core, spread across six Functions (Govern, Identify, Protect, Detect, Respond and Recover), with each outcome recorded in an Organizational Profile. NIST itself says the CSF is not a checklist. Its outcomes do not prescribe how they are achieved, and the order of Functions, Categories and Subcategories implies neither sequence nor importance. Govern is listed first because it frames the others, not because it must be finished before work starts on Protect or Detect.

The 363 Implementation Examples in NIST's Reference Tool export are notional, action-oriented steps, such as documenting, monitoring or exercising a capability. NIST says they are neither a complete list of actions nor a baseline of required actions, so an organization should not treat every example as a pass or fail test. The practical reading is that each Subcategory is an outcome the organization must decide how to meet, and the examples are a source of ideas to consider. Before building the list, confirm the exact counts for your Function and Category selection against the current Reference Tool export, since the same dataset also carries the informative references to other standards.

The organization owns its outcomes, its risk decisions and the status it records for each one. An implementation partner can help build the Profile, collect the artifacts that show a practice exists and prepare the evidence. CSF has no certification, and NIST has no conformity assessment program. Any report on your alignment comes from an independent assessor or auditor you engage under your own contract, and that party should state in writing what was tested and against which Subcategories. Ask any provider to confirm, before work starts, who writes the Profile, who signs off the ratings and who issues any external opinion.

How many outcomes each Function holds

The CSF 2.0 Core holds 22 Categories and 106 Subcategories across six Functions. Use these counts to size each Function's share of the working list, and expect Govern and Protect to carry the most Subcategories and Implementation Examples.

Govern: the broadest Function

Govern has 6 Categories and 31 Subcategories, the most of any Function, and its 119 Implementation Examples are also the most in NIST's Reference Tool export. It covers organizational context, risk management strategy, roles, policy, oversight and supply chain risk. Govern sets the risk strategy the other Functions answer to, so assign an owner to each of its 31 Subcategories before you start scoring the rest. The order of Functions does not imply sequence.

Identify: asset and risk inputs

Identify has 3 Categories (asset management, risk assessment and improvement) and 21 Subcategories, the sum of its outcome groups. Its asset inventories and network and data flow maps feed the Protect, Detect and Respond work. Its risk assessment Subcategories cover vulnerabilities, threats and supplier assessment. Pull this Function's Implementation Example count from the Reference Tool export before you estimate effort.

Protect: the most outcomes after Govern

Protect has 5 Categories and 22 Subcategories, with 77 Implementation Examples in the Reference Tool export. Its Categories cover identity and access, awareness and training, data security, platform security and infrastructure resilience. Two checks often reveal gaps quickly: multifactor authentication on every account that offers it (PR.AA-03) and tested backups (PR.DS-11). Confirm that each check has evidence an assessor can inspect.

Detect: monitoring and event analysis

Detect has 2 Categories, continuous monitoring and adverse event analysis, and 11 Subcategories in total. Its outcomes ask whether you monitor networks, personnel activity, external providers and runtime environments, and whether events are correlated, assessed for impact and declared as incidents. Because Detect outcomes depend on logs produced under Protect, check log generation before you assess monitoring coverage.

Respond: four incident Categories

Respond has 4 Categories: incident management, incident analysis, incident response reporting and communication, and incident mitigation. Together they hold 13 Subcategories, covering response plan execution, root cause analysis, evidence preservation, containment and stakeholder notification. Respond is the Function where outcomes most often require a tested plan, so confirm that each Subcategory points to a plan that has been exercised.

Recover: restoration and communication

Recover has 2 Categories, recovery plan execution and recovery communication, with 8 Subcategories in total. Its recovery plan outcomes include verifying backups and restored assets and declaring recovery complete. The communication Subcategories cover progress updates to stakeholders and public statements. Recover shares evidence with Protect's backup controls, so review the two Functions together when you check restoration proof.

Subcategories to cover in each Function

Govern is the Function NIST added in CSF 2.0, and it frames the other five. The Reference Tool export lists six Categories and 31 Subcategories for it, more than any other Function. The Categories cover the context in which risk decisions are made, the risk management strategy, roles and authorities, policy, oversight and supply chain risk.

GV.OC Organizational context: the mission, stakeholder expectations, dependencies and legal, regulatory and contractual requirements that shape cybersecurity decisions.
GV.RM Risk management strategy: objectives, risk appetite and tolerance, and how cybersecurity risk fits into enterprise risk management.
GV.RR Roles, responsibilities and authorities: leadership accountability, defined cybersecurity roles and adequate resourcing.
GV.PO Policy and GV.OV Oversight: the policy that records the risk strategy and the review of strategy outcomes, all three oversight Subcategories being new in CSF 2.0.
GV.SC Supply chain risk management: supplier prioritization, contract terms, due diligence, monitoring and offboarding.

Confirm your Govern coverage against the exact Subcategory text in the NIST CSF 2.0 Reference Tool export, since many Govern outcomes are evidenced by documents that leadership approves.

Turning 106 outcomes into a working list

Start from the CSF 2.0 Core itself, not from a generic control catalog. The 106 Subcategories are the unit of work, and each one should be assigned to the person or team that owns the outcome and to the systems where the evidence will live. A practical first pass groups Subcategories by owner (for example, GV.RR items with HR and executive leadership, PR.AA items with the identity team, DE.CM items with the security operations team) and then by system (identity provider, endpoint fleet, backup platform, logging stack). Once grouped, attach the Implementation Examples from NIST's Reference Tool export as candidate actions. Treat them as a starting menu. Keep the ones that fit your environment, rewrite the ones that do not, and add actions the examples miss, such as obligations from your own contracts or regulators. Record the result in a working list that also feeds the Organizational Profile template in NIST SP 1301, so the same list serves as both planning tool and status record.

The Implementation Examples are written as notional, action-oriented steps: they use verbs such as share, document, develop, perform, monitor, analyze, assess and exercise. CSWP 29 says they are neither a complete list of actions nor a baseline of required actions, so an example is a prompt for a decision, not an obligation to satisfy. Read each verb as a question. Does the organization need to document this decision, or does it only need the outcome to be true? A tested backup (PR.DS-11) is a clear example of outcome plus verification, while a "document" example may be met by a short, approved record. When an outcome does not apply, such as a Subcategory for a physical environment your organization does not operate, do not silently delete it. Record a short justification with the owner, the date, the reason it is out of scope, and the risk decision that accepted it. Ask your auditor or assessor, before the work starts, which justifications they expect to see in writing, since the answer varies by the framework your customers use.

Where to start each Function with NIST's starting actions

This sequence turns NIST's suggested first actions for GOVERN and PROTECT into an ordered working list, so the organization sets its risk direction before choosing the technical outcomes it will evidence first. Each step ends with a named artifact that can be checked before the next step begins.

Understand risks and organizational needs
Leadership and the people who own mission, legal and operational risk describe what the organization does, which services and data matter most, and what would stop them from operating. NIST's Resource and Overview Guide, SP 1299, suggests starting GOVERN here, before any control decisions. The output is a short written statement of mission priorities and the main cybersecurity risks, approved by a named executive. You know the step is done when each later GOVERN decision can point back to that statement.
Draft a tailored cybersecurity risk strategy
Using the risk statement, the executive sponsor and risk owners set risk objectives, the level of risk the organization will accept, and how risk decisions connect to enterprise risk management. SP 1299 describes this as a strategy reviewed at regular intervals, so the document should name a review owner and a review trigger. The output is a risk strategy document with dated approval. The check is whether someone outside the security team can state what the organization will and will not accept.
Write management-approved policies for legal duties
Policy owners draft the cybersecurity policies that put the strategy into rules, mapping each one to the legal, regulatory and contractual obligations the organization already carries, such as customer security clauses or sector rules. Legal and contract managers confirm the obligations list, since missing one is a common gap. The output is an approved policy set with an obligations register that links each policy to its source requirement. The check is that every policy has an owner, an approval record and a review date.
Write supply chain requirements into contracts
Procurement, legal and the security lead identify suppliers whose services or access could affect the organization's risks, then add cybersecurity requirements to new and renewed contracts. Existing agreements are reviewed against the same list, and gaps are logged for renegotiation. The output is a supplier tier list and a clause set that covers security expectations, incident notification and right to assess. The check is that a sample of contracts for critical suppliers contains each clause, and that the supplier list is reviewed on a set cycle.
Enforce multifactor authentication on supported accounts
The identity owner turns on multifactor authentication for every account that offers it, starting with administrative, remote access and email accounts, then extends to the rest. SP 1300, the Small Business Quick-Start Guide, lists this under PR.AA-03. Exceptions for accounts that cannot use it are recorded with a compensating measure and an owner. The output is an account report showing MFA status by account type. The check is that the report matches the exception register with no unexplained gaps.
Change default manufacturer passwords
The administrator inventories devices, appliances and software accounts that ship with default credentials and replaces each one with a unique credential stored in an approved password or secrets manager. SP 1300 associates this action with PR.AA-01. The output is a record of each default account, the date it was changed and who holds the new credential. The check is a configuration scan or manual review confirming that no vendor default credentials still work.
Turn on regular patching with automatic updates
The platform team enables automatic updates where the vendor supports them and sets a regular patching schedule for systems that need change control. SP 1300 links this to PR.PS-02. Systems that cannot take automatic updates are listed with their patch owner and review point. The output is a patch status report by system and a list of exceptions. The check is that the report shows current patch levels for internet-facing and administrative systems.
Test backups and encrypt laptops and tablets
The operations owner restores sample backups to a test environment on a recurring basis, recording what was restored and how long it took, which maps to PR.DS-11. In parallel, the endpoint owner confirms full-disk encryption on laptops and tablets under PR.DS-01, with recovery keys held in a controlled store. The output is a restore test record and an encryption coverage report for managed devices. The check is that the most recent restore test succeeded and every managed laptop and tablet appears in the encryption report.

What the Organizational Profile template records for each outcome

NIST's Organizational Profile template turns a list of CSF outcomes into a record someone can review. Each row ties an outcome to what the organization does today, how well it is done and what it intends to reach, so the same row can serve internal planning and outside reading.

Current practices and artifacts

The Practices field describes what the organization actually does to achieve a given outcome, such as how access reviews are run or how backups are tested. It may point to artifacts that evidence the outcome, for example a signed policy, a ticket export or a test report. Check that each artifact is dated, owned and retrievable, because a customer or assessor will ask to see it.

Status of each outcome

Status records where the outcome stands today, so a reader can see which Subcategories are in place, partly in place or missing. Keep the wording consistent across the profile, since a status that says "in progress" with no dated artifact behind it will not satisfy a reviewer. Ask who signs off on each status change before the profile is shared outside the organization.

Rating on a chosen scale

The Rating field scores each outcome on a scale that the organization selects, such as 1 to 5 or 0 to 100 percent. NIST gives these as examples, so the scale is a local decision and should be written down with its definitions. A rating only means something if the team applies the same rule to every row and can explain it.

Priority and target goals

Priority ranks which outcomes to address first, usually based on risk, legal obligations and contractual commitments. Target Goals set the level the organization wants to reach for each outcome, which becomes the basis of a gap analysis between the Current and Target Profiles. Confirm that priorities trace back to the risk strategy so the gap list does not become a generic wish list.

Named owner for each row

NIST's template leaves room for the organization to assign who is accountable for each outcome, which is not one of the fixed fields in SP 1301 but is needed to make the other fields accountable. An owner keeps the artifact current and answers questions during a customer review. Ask for the owner's role, not a personal name, so the profile survives staff changes.

Who owns the outcomes and who prepares the evidence

The organization owns every outcome on the list, and only its leaders can decide whether an outcome is met, partly met or not started. NIST's CSF 2.0 materials make clear that the framework does not prescribe how outcomes are achieved and that its Implementation Examples are neither a complete list nor a required baseline. That means the status column in your working list is a management judgment, signed by a named owner for each Subcategory, such as the CISO for PR.AA-03 on multifactor authentication or the CFO or COO for GV.RR decisions on resourcing. Before any outside party touches the list, confirm internally who owns each row and who approves a change in status.

An implementation partner such as DeployOpen can prepare the systems, configurations and records that show an outcome's status. In practice that can mean building the asset inventory behind ID.AM, exporting identity and MFA settings for PR.AA, collecting backup restore test records for PR.DS-11, and filing the change and exception decisions that support GV.PO. The partner works inside your environment and hands over evidence you can review. It does not decide the rating, and it does not declare an outcome complete on your behalf. Ask any partner to show, in writing, which artifacts it will produce for each row and where they will be stored.

Only an independent auditor, assessor or other qualified third party issues a report on your position against the framework. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services and has no plans for a conformity assessment program, so no document that a vendor or consultant produces is a NIST certification. Be cautious with any offer that uses the word certified in connection with NIST CSF 2.0. Your contract with a partner should say that its deliverables are preparation materials, and any independent review should be scoped and paid for separately.

Questions buyers ask about the NIST CSF 2.0 checklist

Is there a required NIST CSF 2.0 checklist?

No. NIST states in CSWP 29 that the CSF does not prescribe how outcomes should be achieved and that its outcomes are not a checklist. The order of Functions, Categories and Subcategories does not imply sequence or importance. NIST does not certify organizations against the framework, so there is no official list an assessor will tick off. What you need is a working list you build from the Core, scoped to your organization and recorded in an Organizational Profile. Treat the list as your own record of decisions, and document why each outcome is in scope, partly in scope or not applicable.

How many NIST CSF 2.0 outcomes should we cover?

Start from the full Core. The CSF 2.0 Core contains 106 Subcategories across six Functions, 22 Categories in total, according to NIST's CSF 2.0 dataset. Plan to assess all 106 unless you can justify excluding one for a documented reason, such as a service that does not exist in your environment. Exclusions should be written down with the rationale and the owner who approved them. Scope decisions about which business units, systems and suppliers the outcomes apply to matter more than the raw count, and those decisions should be reflected in the Profile.

Are the NIST CSF 2.0 Implementation Examples mandatory?

No. CSWP 29 describes Implementation Examples as notional, action-oriented steps, such as share, document, develop, perform, monitor, analyze, assess and exercise. NIST says they are neither a complete list of possible actions nor a baseline of required actions. NIST's Reference Tool export lists 363 of them. Use them as prompts when you write practices for each Subcategory, then choose the actions that fit your risk, technology and size. An assessor or customer will ask whether an outcome is achieved and how you know, not whether you performed every example.

How long does building the outcome list take?

The duration depends on scope, not on a fixed number. The main drivers are the number of business units, systems, cloud accounts and suppliers in scope, how many current policies, asset inventories and risk records already exist, and how much evidence each outcome needs before a reviewer will accept it. An organization with current inventories and documented policies will move faster than one that must first find out what it runs. Ask any provider for a written timeline tied to a written scope, and confirm which of the inputs you need to supply yourselves.

Can our own team build the NIST CSF 2.0 checklist?

Yes, most organizations can start with internal staff, because NIST publishes the Core, Quick-Start Guides, the Reference Tool and the Organizational Profile template at no charge. The work needs people who know the systems, the risk owners who can accept decisions, and someone who can maintain the Profile over time. Internal teams often struggle with independence when they grade their own controls, and with time when security staff are busy with operations. An outside implementation partner can prepare systems and evidence, but the organization still owns its controls and the Profile, and only an independent assessor can issue a report.

Can we answer a customer questionnaire from our Profile?

Partly, and only if the Profile is kept current and linked to evidence. The NIST Organizational Profile template records, for each outcome, the current practices, which may include artifacts that evidence the outcome, a status, a rating, a priority and target goals. A customer questionnaire that asks about a specific control will often map to one or more Subcategories, and you can answer from the matching rows. Where a question asks about something the Core does not cover, or asks for a certification, you will need to answer separately. Check with the customer how they want the mapping presented before you send it.

What evidence should back each outcome on the list?

Evidence should show that the practice exists, is operating and is reviewed. Typical items include a current asset inventory export, an approved policy with a review date, a configuration baseline, access review records, a backup restore test log, and an incident exercise report. NIST's examples for Protect include multifactor authentication on accounts that offer it (PR.AA-03), changing default manufacturer passwords (PR.AA-01), regular patching with automatic updates (PR.PS-02), tested backups (PR.DS-11) and full-disk encryption on laptops and tablets (PR.DS-01). Record the artifact location and owner for each outcome so an assessor can trace it.

Where should we start if the list feels too large?

Start with GOVERN, because NIST suggests it as the entry point. NIST's Resource and Overview Guide, SP 1299, recommends understanding your risks and needs, developing a risk strategy that is reviewed at set intervals, approving policies that reflect legal, regulatory and contractual obligations, and writing supply chain requirements into contracts. GOVERN has 6 Categories, 31 Subcategories and 119 Implementation Examples in NIST's export, the most of any Function. Completing the governance decisions first gives the rest of the list an owner, a risk basis and a set of approved policies to measure against.

What usually makes the checklist stall or misleads

A list of 106 outcomes is easy to turn into a tick-box exercise that looks complete but measures little. The five patterns below are where working lists most often stall, mislead, or produce evidence that an assessor will not accept.

Treating examples as a baseline

The 363 Implementation Examples read like a shopping list, so teams often assume every one must be done before a Subcategory counts as met. NIST says the examples are neither a complete list of actions nor a baseline of required actions. Use them as prompts for how an outcome might be achieved, then record the actions your organization actually chose and why. Ask your team to name, for each Subcategory, the action they selected and any example they deliberately set aside.

Reading Function order as priority

Govern is listed first, so some teams read it as the place to begin and the rest as later stages. NIST states that the order of Functions, Categories and Subcategories does not imply sequence or importance. A working list should set priority from your risks, your current Profile and your obligations, not from the printed order. Before scheduling work, ask who set the priority for each Function and which risk or requirement drove that choice.

Rating outcomes without artifacts

A score of 4 out of 5 on a Subcategory means little if nobody can show what supports it. Profile templates allow practices and artifacts to be recorded next to each rating, and an assessor will ask for that evidence. For every outcome rated above a baseline, attach a named artifact such as a policy version, a configuration export, a test record or a review log, with an owner and a date. Ratings without these links should be marked as unverified.

Copying crosswalk mappings as facts

The Reference Tool links CSF Subcategories to informative references such as SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022 and CIS Controls v8.1. Teams often copy these links into their own list and treat them as proven equivalence. A mapping shows a relationship that someone chose to publish, and it may not match your implementation or the wording an auditor applies. Confirm each mapping you rely on against the source document and your own controls before you cite it in a report or contract response.

Leaving Subcategory ownership unassigned

A checklist with 106 rows and no named owner tends to stall, because each outcome spans technology, process and people. Assign one accountable owner to every Subcategory, separate from whoever performs the work, and record the review date. Owners should be able to say which practice and evidence they maintain. In smaller teams, one person can own several rows, but no row should have an empty owner field when the list goes to leadership.

What to confirm against the current NIST sources

Before you finalize a checklist built from the CSF 2.0 Core, confirm what has changed since you last looked. The Core itself is stable, but the material that sits around it is not. NIST publishes Quick-Start Guides, Community Profiles and informative reference mappings online, and it can update them more often than the framework document. The NIST Cybersecurity Framework updates archive is the place to see what has been added since February 2024, and it records no revision of the CSF 2.0 Core as of October 2026. Check that page first, then note any new Quick-Start Guide or Community Profile that covers a Function or threat relevant to your organization.

Next, re-export the outcome data from the CSF 2.0 Reference Tool rather than relying on a copy saved from an earlier project. The export lists the 106 Subcategories, the 363 Implementation Examples and the informative references to standards such as SP 800-53 Rev. 5.2.0, ISO/IEC 27001:2022, SP 800-171 Rev. 3, CIS Controls v8.1 and PCI DSS. Compare the export against your working list. Look for changed Implementation Example wording, new or removed informative references, and any mapping to a standard your customers or regulators use. Record the export date in your Current Profile so an assessor can tell which version of the outcomes your evidence was measured against.

Finally, decide who owns this check and how often it runs. A named owner, typically the person who maintains the Organizational Profile, should review the archive and the export before any board report, customer questionnaire or assessment, and again whenever a new Quick-Start Guide appears. If you use an implementation partner or consultant, ask them in writing which NIST sources they used and when they last checked them. Treat any mapping or example that does not appear in the NIST export as your own interpretation, and say so in the documentation.

How DeployOpen prepares systems and evidence against the outcomes

DeployOpen treats the NIST CSF 2.0 outcomes as a working list that the organization owns, not a pass or fail test. We prepare the systems, controls and evidence behind each Subcategory you select, inside your own infrastructure, and hand the record back for your team and an independent assessor to review.

How we scope

Each engagement starts with a written scope that names the Functions, Categories and Subcategories in play.
We agree which systems, business units and environments fall inside the Current Profile before any work begins.
Deliverables, timelines and responsibilities are fixed in writing, so the quote follows directly from the agreed scope.
Ongoing support, upgrades and continuous testing can be added later as a retainer, once the scope is stable.

How we build

We deploy self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
We configure each platform to produce the logs, inventories and reports that evidence the chosen outcomes.
We run security testing against the systems in scope and record the findings against the relevant Subcategories.
We align implementation notes with NIST's Implementation Examples, treating them as optional steps rather than required actions.

How we hand over

You receive documentation mapping each in-scope Subcategory to its configuration, owner and supporting artifact.
Your team gets an Organizational Profile workbook that records current practices, status and target goals.
We document the remaining gaps and suggested priorities so your leadership can decide what to fund next.
We prepare evidence packages for independent assessors, but your organization owns its controls and any assessment result.

How we support

Post-handover support is available under a retainer scoped in writing with your team.
We can update configurations and documentation when platforms are upgraded or when NIST revises its online resources.
Continuous testing and periodic reassessment of the in-scope outcomes can be added as the program matures.
Questions about which evidence an assessor or customer expects should go to that assessor or customer, and we will help you prepare for them.