--- key: "nist-csf-2-for-product-teams" title: "NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them" url: "https://softwaresecurity.com/frameworks/nist-csf-2-for-product-teams/" api: "https://softwaresecurity.com/api/v1/articles/nist-csf-2-for-product-teams.json" domain: "governance" topic: "Governance \u0026 frameworks" type: "Guide" identifiers: [] tags: ["Supply chain attacks","Compliance and assurance evidence"] stages: ["govern"] roles: ["appsec-engineer","security-leader"] license: "CC-BY-4.0" license_url: "https://creativecommons.org/licenses/by/4.0/" code_license: "MIT" --- # NIST CSF 2.0 for product teams: the outcomes you own and the evidence for them Find the CSF 2.0 outcomes a product team actually owns, including GOVERN and supply-chain risk management (GV.SC), write a current and target profile for one product, and check it against NIST's own catalog in CI. Canonical URL: https://softwaresecurity.com/frameworks/nist-csf-2-for-product-teams/ ## In short CSF 2.0 (NIST CSWP 29, 26 February 2024) is a set of outcomes, not controls or a certification: 6 functions, 22 categories and 106 subcategories. A product team owns a slice of it, such as software inventories (ID.AM-02), vulnerability intake and disclosure (ID.RA-01, ID.RA-08), secure development (PR.PS-06), supplier requirements (GV.SC-04 to GV.SC-07) and runtime monitoring (DE.CM-09). Write a current and target profile for the product, link every claimed outcome to evidence, and leave Tiers to the organization. - CSF 2.0 added GOVERN (GV) to Identify, Protect, Detect, Respond and Recover. Supply-chain risk management now sits in GOVERN as GV.SC, with 10 subcategories. - A subcategory is an outcome, such as PR.PS-06: secure software development practices are integrated, and their performance is monitored throughout the life cycle. How you achieve it is up to you. - CSF 1.1 identifiers such as PR.AC-01 were withdrawn; access control is now PR.AA. NIST's OSCAL catalog marks withdrawn IDs and links them to their successors. - An Organizational Profile describes a Current and a Target state. Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe the organization's risk governance and management, not one product's controls. - NIST publishes an informative reference from SSDF 1.1 to CSF 2.0, so secure-development evidence can answer PR.PS-06 and several GV.SC rows without a second collection. - Nobody is certified against the CSF. A self-assessed profile is a claim, and its value is the evidence behind each row. ## Recommended defaults | Setting | Value | Note | Source | | --- | --- | --- | --- | | Current edition | CSF 2.0, NIST CSWP 29, published 26 February 2024 | No revision had been announced by 10 October 2026. | NIST CSRC: CSWP 29 | | Structure | 6 functions, 22 categories, 106 subcategories | — | CSF 2.0, Appendix A | | Profiles | Current and Target Organizational Profiles; Community Profiles for shared needs | — | CSF 2.0; NIST SP 1301 | | Tiers | Partial, Risk Informed, Repeatable, Adaptive | Characterize the organization's cybersecurity risk governance and management practices. | CSF 2.0 | | Secure development mapping | NIST informative reference from SSDF 1.1 to CSF 2.0, posted 28 March 2024 | — | NIST OLIR catalog | | Machine-readable catalog | OSCAL catalog in usnistgov/oscal-content v1.5.0 | Also contains the withdrawn CSF 1.1 categories and subcategories, marked with a status property. | usnistgov/oscal-content | | AI profile | NIST IR 8596, Cyber AI Profile: initial preliminary draft of 16 December 2025 | A draft; no final version by 10 October 2026. | NIST CSRC: IR 8596 | ## Verify it 1. Run the profile check against the pinned OSCAL catalog in CI and confirm it fails on a withdrawn identifier such as PR.AC-01. 2. Open the evidence for two rows marked achieved and confirm each belongs to this product and a recent release. 3. Confirm the GV.SC-04 supplier list traces to the SBOM, contracts and the cloud bill, and includes hosted services as well as libraries. 4. Check that no row carries a Tier, and that organization-wide outcomes such as GV.RM-02 name an owner outside the team. 5. Pick one partial row and confirm the gap has an owner and a date in the action plan. ## What you will learn - Pick the CSF 2.0 subcategories that a product team's engineering work answers, and leave organization-wide outcomes to their owners. - Turn GV.SC supply-chain outcomes into supplier lists, contract requirements and monitoring a team can show. - Keep a current and target profile as data and validate its identifiers against NIST's OSCAL catalog. Audience: Engineering leads, product security engineers and the people who answer customer questions about the NIST Cybersecurity Framework Before you start: - Know which services, components and suppliers make up your product. - Read a JSON file and run a Python script in CI. Time: About 31 minutes: 9 to read and 22 for the exercise ## What does CSF 2.0 give a product team? 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. | Function | Categories | What a product team usually contributes | | --- | --- | --- | | GOVERN (GV) | GV.OC, GV.RM, GV.RR, GV.PO, GV.OV, GV.SC | Named owners for the product's security, supplier requirements, the product's obligations and its metrics | | IDENTIFY (ID) | ID.AM, ID.RA, ID.IM | SBOMs and service inventories, vulnerability intake and disclosure, threat models, lessons from tests and incidents | | PROTECT (PR) | PR.AA, PR.AT, PR.DS, PR.PS, PR.IR | Access design, encryption, configuration management, logging and the secure development life cycle | | DETECT (DE) | DE.CM, DE.AE | Runtime and application monitoring, alert analysis | | RESPOND (RS) | RS.MA, RS.AN, RS.CO, RS.MI | Product incident handling, root-cause analysis, customer notices, fixes and mitigations | | RECOVER (RC) | RC.RP, RC.CO | Restore and rollback procedures, recovery communication | ## What does GOVERN ask of the people who build software? 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. ## What does GV.SC mean for the software you build and buy? 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. | Subcategory | Outcome (CSF 2.0 text) | Product-team evidence | | --- | --- | --- | | GV.SC-02 | Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally | An owner for each supplier relationship, and the security contact you give customers | | GV.SC-04 | Suppliers are known and prioritized by criticality | A supplier list built from the SBOM, contracts and the cloud bill, each entry ranked by what it can reach | | GV.SC-05 | Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties | Contract clauses: an SBOM per release, a vulnerability notification time, signed updates, audit or report rights | | GV.SC-06 | Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships | An intake review before adopting a library or vendor: maintenance, provenance, report scope | | GV.SC-07 | The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship | Dependency scanning with VEX review, report renewals and periodic access reviews | | GV.SC-08 | Relevant suppliers and other third parties are included in incident planning, response, and recovery activities | Supplier contacts and escalation paths in the product incident runbook; joint exercises | | GV.SC-09 | Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle | Provenance verification, pinned dependencies and SBOM checks in CI, with their pass rates over time | | GV.SC-10 | Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement | Exit steps: revoke credentials, recover and delete data, replace components that reach end of life | ## Which other subcategories does engineering evidence answer? 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. | Subcategory | Outcome | Practice and evidence | Guide | | --- | --- | --- | --- | | ID.AM-02 | Inventories of software, services, and systems are maintained | An SBOM for every release and a service catalog | /domains/supply-chain/sbom/generate-release-inventory/ | | ID.RA-01 | Vulnerabilities in assets are identified, validated, and recorded | Scanner findings triaged into a tracked queue | /frameworks/vulnerability-prioritization/ | | ID.RA-08 | Processes for receiving, analyzing, and responding to vulnerability disclosures are established | A disclosure policy, `security.txt` and triage records with response times | /domains/appsec/vulnerability-response/coordinated-disclosure/ | | ID.RA-09 | The authenticity and integrity of hardware and software are assessed prior to acquisition and use | Signature and provenance verification before deployment | /domains/supply-chain/provenance/artifact-signature-policy/ | | PR.AA-05 | Access permissions are managed with least privilege and separation of duties | Roles defined in code, access review exports | /domains/identity-crypto/identity/authorization-models/ | | PR.PS-01 | Configuration management practices are established and applied | Infrastructure as code with drift detection | /domains/runtime/cloud-posture/iac-policy-drift/ | | PR.PS-04 | Log records are generated and made available for continuous monitoring | A security event specification and tests for the log pipeline | /domains/runtime/detection/security-event-logging/ | | PR.PS-06 | Secure software development practices are integrated, and their performance is monitored throughout the life cycle | An SSDF evidence matrix: reviews, analysis and tests bound to each release | /frameworks/ssdf-product-lifecycle/ | | DE.CM-09 | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events | Runtime detection rules and application alerts with an owner | /domains/runtime/detection/runtime-detection-response/ | | RS.AN-03 | Analysis establishes what took place during an incident and its root cause | Post-incident reviews with a root cause and a prevention action | /domains/runtime/detection/runtime-detection-response/ | ## How do you write a profile for one product? 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. ```json { "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" } ] } ``` ## How do you keep the profile valid in CI? 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. ```python """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) ``` ## How do CSF, SSDF and SP 800-53 fit together? 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. ## Guided practice A product lead wants the Ledger API team's CSF 2.0 profile in the next customer security review. Review the draft rows, fix what the framework doesn't allow and decide what evidence each claim needs. ### Supplied material ```text Draft profile, Ledger API (fictional), 2026-10-10 R1 PR.AC-01 achieved "SSO for all engineers" evidence: none R2 PR.PS-06 Tier 3 "We follow a secure SDLC" evidence: SDLC policy v2 (wiki page) R3 ID.AM-02 partial "SBOM for tagged releases" evidence: releases/2.8.0/sbom.cdx.json R4 GV.SC-04 achieved "Suppliers known" evidence: list of 14 npm packages R5 ID.RA-08 achieved "security.txt published" evidence: /.well-known/security.txt; no triage records R6 GV.RM-02 target "Set the company's risk appetite" owner: Ledger API tech lead Facts: the API runs on a managed database service and calls a third-party fraud-scoring API under contract. The build pulls 212 npm packages, direct and transitive. A customer asks whether the product is "CSF certified". ``` ### 1. Fix the identifiers Check R1 against CSF 2.0 and rewrite it. Worked answer: PR.AC-01 is a CSF 1.1 subcategory that 2.0 withdrew; NIST's catalog links it to PR.AA-01 (identities and credentials are managed) and PR.AA-05 (permissions follow least privilege and separation of duties). Rewrite R1 as PR.AA-01 and attach the identity provider's configuration export. Achieved with no evidence fails the CI check either way. ### 2. Separate Tiers from outcomes Decide what state R2 should have and what evidence it needs. Worked answer: Tiers describe the organization's risk governance and management overall, so Tier 3 isn't a state of PR.PS-06. Mark it partial or achieved, and replace the policy page with operating evidence: review records, analysis results and test runs bound to a release, for example an SSDF evidence matrix. A policy shows intent, not that the practice is integrated and monitored. ### 3. Complete the supplier list Judge R4 against GV.SC-04. Worked answer: GV.SC-04 asks that suppliers are known and prioritized by criticality. Fourteen direct packages miss the transitive packages in the SBOM, the managed database provider and the fraud-scoring vendor, and nothing is ranked. Mark R4 partial, generate the component list from the SBOM, add services from contracts and the cloud bill, and rank each by the data and systems it can reach. ### 4. Judge the disclosure claim Decide whether R5 supports achieved. Worked answer: No. ID.RA-08 covers processes for receiving, analyzing and responding to disclosures. A `security.txt` file shows a contact point, not that reports are analyzed and answered. Mark R5 partial until triage records or a time-to-triage measure exist. ### 5. Assign ownership and answer the customer Fix R6 and write the reply about certification. Worked answer: Risk appetite and tolerance statements (GV.RM-02) are organizational; the team should cite the organization's profile and the executive who owns it, not claim the row. Tell the customer that the CSF has no certification: offer the profile as a self-assessment with its evidence, and point to any independent report the company holds, such as a SOC 2 Type 2 report, with its scope. Deliverable: A corrected six-row profile with valid CSF 2.0 identifiers, states, evidence and owners, and a two-sentence answer to the certification question. Scope: The product, suppliers and evidence are fictional. The outcome text is NIST's; the practices and evidence are this site's examples, not NIST requirements. Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security. ## Sources - [NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0 (26 February 2024)](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) - [NIST CSF 2.0 (PDF), Appendix A: CSF Core](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf). 26 February 2024. - [NIST SP 1301: CSF 2.0 Quick-Start Guide for Creating and Using Organizational Profiles](https://csrc.nist.gov/pubs/sp/1301/final). February 2024. - [NIST SP 1305: CSF 2.0 Quick-Start Guide for Cybersecurity Supply Chain Risk Management](https://csrc.nist.gov/pubs/sp/1305/final). October 2024. - [NIST CSF 2.0 Reference Tool](https://csrc.nist.gov/Projects/cybersecurity-framework/Filters) - [NIST OLIR: SSDF version 1.1 to Cybersecurity Framework version 2.0 (informative reference)](https://csrc.nist.gov/projects/olir/informative-reference-catalog/details?referenceId=196). Version 1.0.0, posted 28 March 2024. - [usnistgov/oscal-content v1.5.0: CSF 2.0 OSCAL catalog](https://github.com/usnistgov/oscal-content/blob/v1.5.0/nist.gov/CSF/v2.0/json/NIST_CSF_v2.0_catalog.json). 13 May 2026. - [NIST IR 8596 (initial preliminary draft): Cyber AI Profile](https://csrc.nist.gov/pubs/ir/8596/iprd). Initial preliminary draft, 16 December 2025.