NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them

The CSF is a taxonomy of cybersecurity outcomes for organizations of any size. It says what should be true, such as “Inventories of software, services, and systems managed by the organization are maintained” (ID.AM-02), and leaves the how to you. NIST publishes implementation examples and informative references to standards such as SP 800-53 and the SSDF online, next to the framework. The CSF is not a control catalog, a maturity model or a certification scheme, and nobody is assessed against it.

Version 2.0 kept the five functions of version 1.1 and added GOVERN, which holds the strategy, roles, policy, oversight and supply-chain outcomes the other functions depend on. For a product team the useful move is to choose the subcategories its engineering work produces evidence for, and point organization-wide outcomes, such as risk appetite, to the owners the organization names under GV.RR.

Most GOVERN outcomes belong to leadership, but four reach a product team directly. GV.RR-02 asks that “Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced”: for a product, that means a named security owner, a release approver and an incident lead, recorded where the team works. GV.PO-01 asks for a policy that is “communicated and enforced”, which is the difference between a wiki page and a branch ruleset that blocks unreviewed merges. GV.OV-01 asks that strategy outcomes are reviewed to adjust direction, so the product's measures, such as fix times and escaped defects, should reach the people who set it.

GV.OC-03, under which legal, regulatory and contractual cybersecurity requirements “are understood and managed”, is where obligations such as the EU Cyber Resilience Act, PCI DSS or a customer's contract enter the profile. NIST's SSDF-to-CSF reference relates it to SSDF tasks PO.1.1 and PO.1.2: identify and document the security requirements for the organization's infrastructure and processes, and for the software it develops.

GV.SC has ten subcategories. GV.SC-01 and GV.SC-03 are program-level, but the product team holds most of the evidence for the rest: it knows which components, hosted services and contractors the product depends on, and it writes what they must provide. The outcome text below is NIST's; the evidence column gives examples.

Outside GOVERN, these subcategories map most directly to engineering work. The outcome is quoted or closely paraphrased from CSF 2.0; the practice is one way to achieve it, and the last column links the guide here that covers it.

NIST's quick-start guide to Organizational Profiles (SP 1301) describes five steps: scope the profile, gather the information it needs, create the Current and Target profiles, analyze the gaps and write an action plan, then implement the plan and update the profile. Nothing stops you scoping a profile to one product, as long as the product's profile and the organization's agree on who owns shared outcomes.

Keep the profile as data in the repository, one row per subcategory, with a state, the current and target outcome in your own words, evidence and an owner. Don't put a Tier in a row: Tiers describe how the organization governs and manages cybersecurity risk as a whole, so “PR.PS-06: Tier 3” mixes two scales.

{
  "profile": "Payments API: current and target",
  "framework": "NIST CSF 2.0",
  "scope": "payments-api, its build pipeline and the components it ships",
  "updated": "2026-10-10",
  "rows": [
    {
      "id": "ID.AM-02",
      "state": "partial",
      "current": "CycloneDX SBOM for tagged releases; hotfix builds have none",
      "target": "An SBOM for every build that reaches production, kept with the release",
      "evidence": ["releases/4.12.0/sbom.cdx.json"],
      "owner": "platform team"
    },
    {
      "id": "ID.RA-08",
      "state": "achieved",
      "current": "Published disclosure policy and security.txt; reports triaged in the PSIRT queue",
      "target": "Unchanged; triage within 5 working days, measured monthly",
      "evidence": ["psirt/metrics-2026-09.csv"],
      "owner": "product security"
    },
    {
      "id": "PR.PS-06",
      "state": "partial",
      "current": "Review and SAST required on the default branch",
      "target": "Threat-model review for every new endpoint; findings tracked per release",
      "evidence": ["rulesets/payments-default-branch.json"],
      "owner": "payments engineering lead"
    },
    {
      "id": "GV.SC-04",
      "state": "not started",
      "current": "No list of suppliers or hosted dependencies",
      "target": "Every supplier and hosted dependency ranked by criticality",
      "owner": "engineering manager"
    }
  ]
}

NIST publishes CSF 2.0 as an OSCAL catalog in its oscal-content repository. Release v1.5.0 of 13 May 2026 holds the 106 current subcategories and the withdrawn CSF 1.1 ones, each withdrawn entry marked with a status property and linked to the subcategories that replaced it. Download it from a pinned tag, as you would pin a dependency: curl -fsSLO https://raw.githubusercontent.com/usnistgov/oscal-content/v1.5.0/nist.gov/CSF/v2.0/json/NIST_CSF_v2.0_catalog.json.

The script rejects unknown and withdrawn identifiers, rows without an owner or a target, and any row marked achieved or partial that cites no evidence. For the profile above it prints profile OK; a row that still says PR.AC-01 fails with the replacement IDs, PR.AA-01 and PR.AA-05.

"""Check a product team's CSF 2.0 profile against NIST's OSCAL catalog of the framework.

Usage: python3 check_profile.py NIST_CSF_v2.0_catalog.json product-profile.json
"""

import json
import sys

STATES = {"achieved", "partial", "not started"}


def subcategories(catalog):
    """Map each subcategory ID to None if current, or to its CSF 2.0 successors if withdrawn."""
    found = {}

    def walk(controls):
        for control in controls:
            if control.get("class") == "subcategory":
                withdrawn = any(
                    p["name"] == "status" and p["value"] == "withdrawn"
                    for p in control.get("props", [])
                )
                links = [link["href"] for link in control.get("links", [])]
                found[control["id"]] = links if withdrawn else None
            walk(control.get("controls", []))

    for group in catalog["catalog"]["groups"]:
        walk(group.get("controls", []))
    return found


def problems(profile, known):
    found = []
    for row in profile["rows"]:
        sid = row.get("id", "")
        if sid not in known:
            found.append(f"{sid}: not a CSF subcategory")
        elif known[sid] is not None:
            found.append(f"{sid}: withdrawn in CSF 2.0; see {', '.join(known[sid]) or 'notes'}")
        for field in ("current", "target", "owner"):
            if not row.get(field):
                found.append(f"{sid}: no {field}")
        if row.get("state") not in STATES:
            found.append(f"{sid}: state must be one of {sorted(STATES)}")
        elif row["state"] != "not started" and not row.get("evidence"):
            found.append(f"{sid}: {row['state']} needs evidence")
    return found


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        known = subcategories(json.load(f))
    with open(sys.argv[2], encoding="utf-8") as f:
        issues = problems(json.load(f), known)
    print("\n".join(issues) or "profile OK")
    sys.exit(1 if issues else 0)

The CSF points to other documents instead of repeating them. NIST's informative reference from SSDF 1.1 to CSF 2.0, posted on 28 March 2024, shows how implementing the CSF can support SSDF practices and tasks. For example, it relates GV.SC-05 to PO.1.3, communicating requirements to third parties who provide software, and PR.IR-01, protecting environments from unauthorized access, to PO.5.1, separating and protecting each development environment. NIST's catalog of informative references also relates CSF 2.0 to SP 800-53 controls.

Treat these mappings as starting points. They relate concepts, not your implementation, so the evidence still comes from your product, and a broad match such as “supports” never means one passing control satisfies the other framework. The method for writing and checking such rows is in /frameworks/control-mapping-and-evidence/. For AI features, NIST IR 8596, the Cyber AI Profile, was still an initial preliminary draft of 16 December 2025 on 10 October 2026: follow it, but don't adopt a draft as your baseline.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0 (26 February 2024)
2. NIST CSF 2.0 (PDF), Appendix A: CSF Core. 26 February 2024.
3. NIST SP 1301: CSF 2.0 Quick-Start Guide for Creating and Using Organizational Profiles. February 2024.
4. NIST SP 1305: CSF 2.0 Quick-Start Guide for Cybersecurity Supply Chain Risk Management. October 2024.
5. NIST CSF 2.0 Reference Tool
6. NIST OLIR: SSDF version 1.1 to Cybersecurity Framework version 2.0 (informative reference). Version 1.0.0, posted 28 March 2024.
7. usnistgov/oscal-content v1.5.0: CSF 2.0 OSCAL catalog. 13 May 2026.
8. NIST IR 8596 (initial preliminary draft): Cyber AI Profile. Initial preliminary draft, 16 December 2025.

Reference information

Tags

Supply chain attacksCompliance and assurance evidence

SDLC phase

Security program

Role

AppSec engineersSecurity leaders

Download this guide as Markdown

Continue exploring