We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALNIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1 C-SCRM Governance Guide

Connect enterprise direction to mission and business-process decisions, then to system and supplier execution, with operational findings flowing back to leadership.

A is an optional service model. It can coordinate work, but it does not replace assigned executive, mission/business, acquisition, system, or risk-acceptance authority.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections1 primary sources
Overview

NIST SP 800-161 Rev. 1 Update 1 treats as an enterprise-wide activity shared across leadership, enterprise risk, mission and business owners, acquisition, legal, engineering, cybersecurity, privacy, operations, and assurance. Governance should make their decision rights explicit and connect the publication's three risk-management levels through direction, escalation, and feedback. The publication is voluntary guidance for nongovernmental organizations; federal agencies must also apply the laws, OMB direction, acquisition rules, and agency requirements that govern their systems and procurements.

Section 1

What each risk-management level owns

Level 1 is the enterprise view. NIST uses "enterprise" for the top of the risk-management hierarchy, which may be a company, federal agency, or another organization; a large enterprise can have subordinate organizations with their own Level 1 activities. Senior leaders and the risk executive function establish strategy, policy, governance, risk appetite and tolerance, priorities, resources, delegation, escalation, and enterprise-wide reporting. Level 2 mission and business-process owners tailor that direction into requirements, dependencies, priorities, implementation plans, and risk responses for the work they own.

Level 3 is the operational view. System owners, program managers, acquisition teams, engineers, developers, integrators, operators, and control assessors apply requirements throughout the system development life cycle and acquisition process. They maintain system-level plans, implement and assess tailored controls, and report material findings to Level 2 so higher-level strategy and plans can be revised.

  • Level 1 approves enterprise strategy, policy, risk boundaries, common services, funding, and reporting expectations.
  • Level 2 identifies mission-critical dependencies, tailors enterprise direction, prioritizes risk, and escalates decisions beyond its authority.
  • Level 3 implements plans and controls for systems and supplier relationships and reports material changes, exceptions, and evidence upward.
Section 2

Choose a PMO and council model without obscuring accountability

NIST permits centralized, decentralized, and hybrid operating models. One option is a program management office that provides advisory services, tools, training, supplier assessments, information sharing, risk-register support, governance staffing, performance management, and executive reporting. The office may sit at Level 1 or Level 2 and should include cross-disciplinary representation.

The supports rather than replaces assigned responsibilities. Keep a decision-rights matrix that states who owns the risk, who may accept residual risk, who writes requirements, who awards and manages contracts, who assesses controls, who coordinates incidents, and which thresholds require escalation. A cross-functional council can set priorities and resolve conflicts without absorbing every mission or system decision.

  • Publish a RACI or decision-rights matrix across the three levels, including acquisition and incident authorities.
  • Define upward triggers for critical supplier failure, concentration risk, control failure, vulnerability exposure, incident impact, and risk above tolerance.
  • Define downward flows for enterprise policy, common control baselines, prohibited sources, contract language, training, and information-sharing expectations.
Section 3

Owner and evidence checklist for NIST SP 800-161 Rev. 1 C-SCRM governance

Governance evidence should show direction, decision authority, implementation, escalation, and feedback across the three levels. A policy alone does not show that mission owners tailored it, system teams implemented it, controls operated, or operational findings reached enterprise risk decisions. Record the version, approver, effective date, review interval, and off-cycle review triggers for each governing artifact.

Appendix D provides example structures for a strategy and implementation plan, policy, operational plan, and supply chain risk assessment. They are adaptable examples, not mandatory forms. Tailor them to the enterprise and keep their assumptions, requirements, decisions, and revisions connected.

  • Strategy and implementation plan with objectives, initiatives, milestones, resources, dependencies, measures, and executive approval.
  • Policy and governance charter defining the three levels, decision rights, PMO/council mandate, risk appetite, escalation, exceptions, and reporting.
  • Mission/business and system-level plans, criticality and risk assessments, tailored controls, acquisition integration, and accountable owners.
  • Metrics, training, budget, supplier and incident reporting, meeting decisions, risk acceptances, corrective actions, and evidence that feedback changed policy or plans.
  • Scheduled review and off-cycle triggers for mission, system, supplier, ownership, sourcing, threat, vulnerability, incident, regulatory, contractual, or risk-tolerance changes.
Recommended next step

Put this NIST SP 800-161 Rev. 1 C-SCRM guidance into practice

Connect enterprise direction, mission priorities, system plans, risk decisions, and monitoring to named owners and reviewable evidence.

Assessment workflow
Open Assessment Autopilot for NIST SP 800-161 Rev. 1 C-SCRM

Create cited tasks, evidence requests, and review checkpoints for this NIST SP 800-161 Rev. 1 C-SCRM scope.

Explore next step
Talk to Sorena
Review this NIST SP 800-161 Rev. 1 C-SCRM scope with Sorena

Review decision authority, governance records, escalation paths, and gaps in supplier-risk oversight.

Explore next step
Section 4

Common C-SCRM governance mistakes

A procurement questionnaire owned by one team does not cover the publication's enterprise-wide, cross-disciplinary model. Acquisition, engineering, legal, security, privacy, operations, continuity, logistics, mission, and system decisions all shape cybersecurity supply chain risk.

A PMO can provide common services and consistency, but accountable officials still make the decisions assigned to their roles. Escalation should carry the scope, evidence, uncertainty, response options, and residual risk to the proper authority.

  • Do not assign responsibility only to cybersecurity; name business, acquisition, engineering, system, supplier, incident, continuity, and risk-acceptance authorities.
  • Do not report document counts as success. Measure implementation, control operation, response performance, risk reduction, mission impact, and decisions enabled.
  • Do not let Level 1 direction flow down without a path for Level 3 changes, vulnerabilities, incidents, and residual risk to flow back up.
Section 5

Practical workflow for NIST SP 800-161 Rev. 1 C-SCRM governance

Run governance as an iterative cycle: frame enterprise direction, tailor it into mission and system plans, implement it through acquisition and the system life cycle, assess risk, choose a response, monitor change and effectiveness, and feed results back into higher-level assumptions and decisions.

Section 3.4 labels its practice groups Foundational, Sustaining, and Enhancing, although the introduction and a key takeaway use "Enabling" for the third group. Treat the groups as general prioritization guidance, not certification levels, supplier categories, or a universal maturity score.

  • 1 | Charter | Establish executive sponsorship, the PMO/council model, decision rights, risk appetite, resources, information sharing, and reporting.
  • 2 | Direct | Approve the strategy, implementation plan, policy, common processes, control expectations, training, and performance objectives.
  • 3 | Tailor and execute | Translate enterprise direction into mission/business and system plans, assessments, acquisitions, contracts, controls, monitoring, and response.
  • 4 | Measure and escalate | Evaluate implementation and effectiveness, surface risks above tolerance, fund corrective action, and record acceptance at the right authority.
  • 5 | Refresh | Feed supplier, system, threat, vulnerability, incident, audit, performance, and mission changes back into strategy, policy, plans, and resources.
Primary sources

References and citations

NIST SP 800-161 Rev. 1 Update 1 C-SCRM
doi.org6 citations
Referenced sections
  • Primary source for the three-level governance model, stakeholder roles, optional PMO model, C-SCRM documents, key-practice groupings, and iterative risk-management cycle explained on this page.
  • Sections 2.3-2.3.4 define the three levels, their stakeholders and deliverables, and the direction and reporting paths between enterprise, mission/business-process, and operational work.
  • Section 2.3.5 describes centralized, decentralized, and hybrid models, lists possible C-SCRM PMO services, and states that a PMO may sit at Level 1 or Level 2.
Show 3 more
  • Section 2.3.4 calls the operational C-SCRM plan a living reference for continuous monitoring; Appendix D provides adaptable example templates for strategy, policy, plans, and assessments.
  • Section 2.3.1 describes the coordinated, multidisciplinary team and shared-responsibility model while stating that the team does not replace responsibilities assigned to individual functions.
  • Section 3.4 groups key practices as foundational, sustaining, and enhancing; Appendix G explains that Frame, Assess, Respond, and Monitor are iterative and that information flows between levels.
"The publication integrates cybersecurity supply chain risk management (C-SCRM) into risk management activities by applying a multilevel, C-SCRM-specific approach"
More quoted passages
"C-SCRM requires the involvement of all three levels."
"A variety of operating models (e.g., centralized, decentralized, hybrid) facilitate C-SCRM activities"
"C-SCRM plans are intended to be referenced regularly and should be reviewed and refreshed periodically"
"The team leverages but does not replace those C-SCRM responsibilities and processes"
"The steps in the risk management process (Frame, Assess, Respond, and Monitor) are iterative and not inherently sequential in nature."

Related guides

NIST SP 800-161 Rev. 1 C-SCRM Governance Checklist

A NIST SP 800-161 Rev. 1 checklist for assigning C-SCRM decisions across enterprise, mission/business-process, and operational levels.

NIST SP 800-161 Rev. 1 Contract and Monitoring Controls

Translate C-SCRM risk decisions into supplier clauses, subcontractor flow-down, evidence delivery, revalidation, monitoring, incident, continuity, and exit terms.

NIST SP 800-161 Rev. 1 Criticality Analysis Guide

Identify mission-critical functions, systems, components, products, services, suppliers, and single-source dependencies so C-SCRM effort follows potential impact.

NIST SP 800-161 Rev. 1 FAQ: practical implementation questions

NIST SP 800-161 Rev. 1 answers with cited implementation steps, decision criteria, and evidence guidance.

NIST SP 800-161 Rev. 1 implementation playbook

Build a tailored C-SCRM program with strategy, policy, plans, assessments, acquisition controls, monitoring, and evidence across NIST's three risk-management levels.

NIST SP 800-161 Rev. 1 Provenance and SBOM Supplier Controls

Use provenance, SBOM, build integrity, authenticity, and supplier evidence together to manage software and component risk under NIST SP 800-161 Rev. 1.

Show all related guides (19)

NIST SP 800-161 Rev. 1 supplier assessment evidence: risk-based records and evaluation criteria

Choose and validate supplier evidence based on criticality, risk, contract requirements, source reliability, freshness, and proof of operating effectiveness.

NIST SP 800-161 Rev. 1 Supplier Risk Tiering

Group suppliers by mission dependency and cyber risk, then tie each category to proportionate due diligence, evidence, contracts, monitoring, and response.

NIST SP 800-161 Rev. 1 vs DORA ICT third-party risk: practical side-by-side comparison

Compare NIST SP 800-161 Rev. 1 and DORA ICT third-party risk with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.

NIST SP 800-161 Rev. 1 vs ISO/IEC 27036 supplier relationships: practical side-by-side comparison

Compare NIST SP 800-161 Rev. 1 and ISO/IEC 27036 supplier relationships with side-by-side scope, owner, trigger, evidence, cadence, assurance, and decision-rule rows.

NIST SP 800-161 Rev. 1: workflow for collecting and validating C-SCRM supplier evidence

A risk-based NIST SP 800-161 supplier evidence workflow from relationship scope and criticality through request, validation, decision, remediation, and monitoring.

How should teams handle counterfeits under NIST SP 800-161 Rev. 1 supply-chain risk management?

Prioritize critical items, use traceable sources, verify authenticity and tamper protection, quarantine suspected counterfeits, and reassess affected risk.

How should teams handle critical suppliers under NIST SP 800-161 Rev. 1 supply-chain risk management?

Identify critical suppliers through mission dependency, component importance, access, concentration, substitutability, and potential impact, not spend alone.

How should teams handle monitoring under NIST SP 800-161 Rev. 1 supply-chain risk management?

Run risk-based supplier monitoring with scheduled revalidation, event triggers, operating signals, escalation thresholds, corrective action, and evidence.

How should teams handle provenance under NIST SP 800-161 Rev. 1 supply-chain risk management?

Collect and verify traceable origin, build, dependency, custody, authenticity, and change evidence for critical systems, components, software, and data.

How should teams handle supplier incidents under NIST SP 800-161 Rev. 1 supply-chain risk management?

Coordinate supplier incidents through joint triage, evidence preservation, containment, recovery, contract communication, corrective action, and reassessment.

How should teams handle supply chain risk response under NIST SP 800-161 Rev. 1 supply-chain risk management?

Choose and document whether to accept, avoid, mitigate, share, or transfer supply-chain risk, with authority, actions, residual risk, and review triggers.

How should teams handle tiering under NIST SP 800-161 Rev. 1 supply-chain risk management?

Build supplier risk categories that drive assurance treatment while keeping them distinct from SP 800-161 risk-management levels and CSF Tiers.

Which contract controls should teams define under NIST SP 800-161 Rev. 1?

Translate supplier risk into measurable security, flow-down, evidence, monitoring, incident, continuity, remediation, and exit clauses under SP 800-161.