Artifact GuideGLOBALNIST CSF 2.0

NIST CSF 2.0 Implementation Examples Guide

Use as optional prompts, adapt them to one scoped outcome, and define evidence that tests the result.

Begin with the outcome. An example is neither a required control nor proof of achievement, and the online set can change between Profile reviews.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 26, 2026
Overview

are concise, action-oriented, notional illustrations of ways an organization might achieve a CSF outcome. They are online supplementary resources, not required controls, a complete baseline, or proof that the outcome has been achieved. NIST may update them more frequently than the February 26, 2024 CSWP 29 publication, so preserve the retrieved text or export and retrieval date used for each local decision.

Section 1

What an Implementation Example is and is not

NIST defines an Implementation Example as a concise, action-oriented, notional illustration of a way to help achieve a CSF Core outcome. The examples supplement Subcategories; they do not replace the outcome text.

NIST states that the examples are not comprehensive and do not form a baseline of required actions. An organization may adopt, adapt, combine, replace, or reject an example after considering mission, risks, technology, requirements, resources, and existing practices. A separate law, contract, policy, or authority can still require a particular action; preserve that external source instead of attributing the duty to the example.

  • | The desired cybersecurity outcome that the organization is assessing or targeting.
  • Implementation Example | One possible action that may help achieve that outcome; it is not a mandatory control or complete checklist.
  • | A mapping between a Core outcome and another standard, guideline, regulation, or other content; one reference may address only part of a .
  • External requirement | A duty created by the applicable law, regulation, contract, grant, policy, or authority. The CSF example does not create that duty.
  • Evidence | Organization-specific records used to judge how or to what extent the outcome is achieved; the example itself is not evidence.
Section 2

Select and adapt an example without changing the outcome

Start with the Profile boundary and exact . Read the complete outcome before reviewing examples, because an example may address only one way or one part of achieving it.

Write the adapted action in organization-specific terms: actor, action, covered assets or population, frequency or event trigger, system or process, exceptions, and expected record. Preserve a link to the original example and label local additions as organization-defined.

  • Adopt | Use the NIST example as written only when its actor, scope, and action fit the organization's context; still define ownership and evidence.
  • Adapt | Narrow, expand, sequence, or translate the example into local processes without claiming that the local wording is NIST text.
  • Combine | Use several examples or other practices when one action does not cover the full outcome.
  • Replace | Choose a different method that achieves the outcome and record why it fits the risk and constraints.
  • Inapplicable | Record the scope fact or dependency that makes the example unsuitable. This does not automatically make the inapplicable.
Section 3

Implementation record and evidence test

The implementation record should let a reviewer trace from the to the selected action, then to the evidence and conclusion. Do not mark the outcome achieved merely because the action was assigned or performed once.

  • Source fields | identifier and text; NIST example text or export reference; source date; related Informative References or external requirements.
  • Decision fields | Adopt, adapt, combine, replace, or inapplicable; local action; rationale; assumptions; constraints; accountable owner; approver.
  • Operation fields | Covered assets or population; procedure or system; event trigger or frequency; dependencies; exception handling; resources; implementation status.
  • Evidence fields | Expected artifact; custodian and controlled location; covered period; collection method; population or sample; reviewer; exceptions; conclusion and limitations.
  • Review fields | effect; open gap; action owner; acceptance criterion; due date or milestone; reassessment trigger; prior version.
Section 4

Common mistakes and update limits

NIST hosts supplementary resources online so they can be updated more frequently than CSWP 29. Preserve the version or retrieval date used in a decision, and check the Reference Tool when revising the Profile.

  • Do not label an example mandatory, complete, or sufficient; NIST describes the set as not comprehensive and not a baseline of required actions.
  • Do not copy an example into a control library without an owner, scope, trigger, exception path, and expected evidence.
  • Do not treat one example as proof that every part of a compound outcome is achieved.
  • Do not treat an as full coverage when the mapped content addresses only part of the outcome.
  • Do not silently overwrite a locally approved action when NIST updates an online example; review the change and record the decision.
Section 5

Practical workflow and worked example

Example: GV.RM-02 says risk appetite and risk tolerance statements are established, communicated, and maintained. A team might consult the current NIST examples, then define local actions for approval, distribution, and periodic or event-driven review. An approved statement may support 'established'; distribution records may support 'communicated'; version history and completed reviews may support 'maintained.' These artifacts are illustrative organization-specific choices, not NIST-mandated evidence.

Assess the complete outcome after reviewing the records. If only approval is evidenced, qualify the Current state under the organization's method and create actions for the unsupported parts.

  • Step 1 | Outcome | Confirm the Profile boundary, exact , desired result, and any external requirement.
  • Step 2 | Options | Review current NIST and Informative References; list other feasible organization-specific methods.
  • Step 3 | Select | Record adopt, adapt, combine, replace, or inapplicable; assign the action, owner, scope, trigger, exception path, and expected evidence.
  • Step 4 | Operate and test | Perform the action, collect records, test coverage and exceptions, and decide how or to what extent the outcome is achieved.
  • Step 5 | Update | Record gaps and actions, update the when evidence supports it, and recheck online resources at the next material review.
Primary sources

References and citations

doi.org2 citations
Referenced sections
  • Primary source for Implementation Examples, Informative References, online supplementary-resource updates, Current Profiles, and GV.RM-02.
  • Defines Implementation Examples and Informative References, states that examples are not comprehensive or a required baseline, explains that online resources may change more frequently than CSWP 29, and defines Current Profiles.
"does not prescribe how outcomes should be achieved"
doi.org
Referenced sections
  • Adjacent NIST guidance for risk-based analysis and prioritization; it does not make an Implementation Example mandatory or sufficient.
"Guide for Conducting Risk Assessments"
Show all related guides (24)

NIST CSF 2.0 Profile Workshop Template

A fill-in NIST CSF 2.0 Profile workshop template for scope, roles, outcome decisions, evidence gaps, approvals, and follow-up.

NIST CSF 2.0 Profile Workshop Workflow

Prepare and run a NIST CSF 2.0 Profile workshop that produces scoped outcome decisions, evidence requests, and a gap plan with accountable owners.

NIST CSF 2.0 Requirements Mapping Guide

Build a traceable mapping from applicable requirements to NIST CSF 2.0 outcomes, controls, evidence, gaps, and owners without treating the mapping as proof of compliance.

NIST CSF 2.0 vs CIS Controls v8.1: Mapping and Gap Analysis

Map CSF 2.0 outcomes to CIS Controls v8.1 safeguards without confusing a crosswalk with implementation evidence or full outcome achievement.

NIST CSF 2.0 vs CIS Controls v8.1: Which to Use

Choose CSF 2.0 for outcome-based risk governance, CIS Controls v8.1 for prioritized safeguards, or combine them with separate claims and evidence.

NIST CSF 2.0 vs ISO/IEC 27001:2022: Which to Use

Choose CSF 2.0 for outcome-based cyber-risk governance or ISO/IEC 27001:2022 for a requirements-based ISMS and possible certification.

NIST CSF 2.0 vs NIST RMF: practical side-by-side comparison

Decide when to use NIST CSF 2.0 outcomes and Profiles, when to use the seven-step NIST RMF process, and how to connect their evidence.

NIST CSF 2.0 vs SP 800-53 Rev. 5: control mapping and coverage gaps

Map CSF 2.0 outcomes to SP 800-53 Rev. 5 controls while preserving scope, tailoring, assessment, and partial-coverage limits.

NIST CSF 2.0 vs SP 800-53 Rev. 5: Which to Use

Choose CSF 2.0 for outcome-based cybersecurity governance or SP 800-53 Rev. 5 for control selection, tailoring, implementation, and assessment.

NIST CSF 2.0: step-by-step workflow for building current and target profiles

Build compatible NIST CSF 2.0 Current and Target Profiles, analyze each gap, and turn the comparison into a risk-informed action plan.

How should teams handle evidence mapping under NIST CSF 2.0?

Map policies, configurations, tests, logs, approvals, and operating records to specific NIST CSF 2.0 outcomes without treating a reference or policy as proof of performance.

How should teams handle implementation examples under NIST CSF 2.0?

Use NIST CSF 2.0 Implementation Examples as optional, non-exhaustive ways to help achieve a Subcategory outcome, then tailor and test the chosen practice.

How should teams handle supplier risk under NIST CSF 2.0?

Apply NIST CSF 2.0 supplier-risk outcomes across selection, contracting, monitoring, incident coordination, and relationship exit, with effort based on criticality and risk.

How should teams handle target profiles under NIST CSF 2.0?

Build a NIST CSF 2.0 Target Profile by selecting and prioritizing desired Core outcomes, then turn Current-to-Target gaps into risk actions with accountable owners.

How should teams handle tiers under NIST CSF 2.0?

Use NIST CSF 2.0 Tiers to characterize risk governance and management rigor for a defined scope without turning them into certification levels or a universal maturity score.

NIST CSF 2.0 GOVERN Function FAQ

Start the NIST CSF 2.0 GOVERN function by naming decision owners, risk strategy, policy expectations, oversight cadence, and supplier-risk accountability before mapping controls.

What should a NIST CSF 2.0 Current Profile include to be useful for audits and risk decisions?

A useful CSF 2.0 Current Profile should show current outcomes, accountable owners, supporting evidence, known gaps, dependencies, and review dates. It should be specific enough that a reviewer can understand what is true today without re-interviewing every team.

Which NIST CSF 2.0 metrics are useful for board and executive reporting?

Use board-level CSF 2.0 metrics that show risk decisions, business impact, target-profile gaps, and progress against priorities. Avoid only reporting control counts; executives need to see whether cybersecurity outcomes are improving in the context of organizational objectives.