PM-30: Supply Chain Risk Management Strategy

PM-30 requires your organization to build, enforce, and maintain a single supply chain risk management (SCRM) strategy that governs every

Quick-reference card

FieldValue
Control IDPM-30
Control NameSupply Chain Risk Management Strategy
FrameworkNIST SP 800-53 Revision 5
Control FamilyProgram Management
Baselines
RelevanceOrganization (First Party)
Risk SeverityMedium

What this control requires

PM-30 requires your organization to build, enforce, and maintain a single supply chain risk management (SCRM) strategy that governs every system, component, and service you develop, acquire, maintain, or dispose of. Without an explicit, organization-wide strategy, supply chain risk decisions happen in silos, and inconsistent risk acceptance across business units creates gaps that no individual team can see.

The strategy must do three things. First, it must define your supply chain risk appetite and tolerance so every team applies the same thresholds when evaluating suppliers, components, and services. Second, it must be implemented consistently, meaning the same risk evaluation criteria and mitigation controls apply whether you’re procuring cloud infrastructure, embedded firmware, or contracted development services. Third, it must be reviewed and updated on a defined frequency or whenever organizational changes demand it.

In practice, PM-30 sits at the organizational and mission/business level within the NIST SP 800-53 framework. It sets the strategic direction that feeds into system-level plans like SR-2. Think of it as the policy backbone that tells every program and project team how to evaluate, accept, and mitigate supply chain risk before they ever draft a system-specific plan.

Why it matters

Organizations without a documented SCRM strategy consistently fail to identify where their supply chain exposure concentrates. The result is a compliance gap that auditors flag quickly, because NIST SP 800-53 expects an explicit strategy document with defined risk appetite, assigned roles, and a review cadence.

Beyond audit findings, the absence of a unified strategy means different teams apply different risk thresholds to the same categories of suppliers. One business unit may accept a software component with no provenance verification while another rejects the same component. That inconsistency isn’t just an operational problem; it produces audit evidence that directly contradicts the consistency requirement in PM-30’s assessment objectives.

Without a defined review frequency, your SCRM strategy also drifts out of alignment with organizational changes. Mergers, acquisitions, new product lines, and shifts in sourcing all introduce supply chain risks that a stale strategy doesn’t account for. Auditors look specifically for evidence that the strategy reflects the organization’s current operating environment.

Failing to implement PM-30 doesn’t trigger a single dramatic failure. It creates a structural weakness that compounds over time, making it harder to demonstrate due diligence to regulators, auditors, and business partners who expect a mature supply chain resilience posture.

What attackers exploit when SCRM strategy is absent:

  • Inconsistent supplier vetting standards across business units, allowing compromised components to enter through the path of least resistance
  • No defined risk appetite, so teams accept third-party dependencies without evaluating provenance or security practices
  • Lack of a disposal process for decommissioned systems and components, leaving residual access or data exposure
  • Stale strategy documents that don’t reflect current acquisition channels, giving attackers newer, unmonitored entry points
  • No centralized visibility into which suppliers and services each business unit relies on, hiding concentration risk

How to implement

For your organization

The most common failure mode with PM-30 is treating the SCRM strategy as a standalone document that gets written once and shelved. Organizations draft a policy to satisfy an audit finding, but never connect it to the procurement workflows, risk assessment processes, and governance structures that make it operational.

Step 1: Define supply chain risk appetite and tolerance. Work with your risk executive function, procurement leadership, and information security team to establish explicit thresholds. Document what level of supply chain risk your organization will accept, what requires mitigation, and what triggers rejection. These thresholds should cover the full lifecycle: development, acquisition, maintenance, and disposal.

Step 2: Inventory your supply chain touchpoints. Map the systems, system components, and services your organization depends on, and identify the suppliers, integrators, and service providers behind them. You can’t apply a consistent strategy to a supply chain you haven’t defined.

Step 3: Establish evaluation criteria and mitigation controls. Define the criteria every business unit must use when assessing supply chain risk. This includes acceptable risk mitigation strategies, required contractual clauses, provenance verification expectations, and minimum security requirements for suppliers. Reference established frameworks like NIST SP 800-161 for detailed supply chain risk management practices.

Step 4: Assign roles and responsibilities. Document who owns the SCRM strategy, who approves exceptions, who conducts supplier risk assessments, and who reports supply chain risk to leadership. A risk executive function helps maintain consistent application across business units.

Step 5: Integrate with organizational risk management. Your SCRM strategy should connect directly to your enterprise risk management framework. Supply chain risk isn’t a separate discipline; it feeds into the same risk register and governance processes as operational, financial, and cybersecurity risk.

Step 6: Set a review and update cadence. Define how often you’ll review the strategy (annually at minimum), and specify triggers for out-of-cycle reviews such as mergers, acquisitions, new product lines, or significant changes to sourcing. Document every review with meeting minutes, change logs, and updated strategy versions.

Common mistakes to avoid:

  • Writing the strategy in isolation from procurement and engineering teams
  • Defining risk appetite in vague terms that teams can’t operationalize
  • Failing to distinguish the organization-wide strategy (PM-30) from system-level supply chain risk management plans (SR-2)
  • Not maintaining version history or review records, which auditors specifically check
  • Treating disposal as outside the scope of supply chain risk

Evidence examples

Evidence TypeExample Artifact
SCRM strategy documentOrganization-wide supply chain risk management strategy defining risk appetite, tolerance thresholds, acceptable mitigation controls, and review frequency
Risk appetite statementDocumented supply chain risk appetite and tolerance levels approved by executive leadership, specifying acceptable and unacceptable risk categories
Roles and responsibilities matrixRACI chart identifying the risk executive function, SCRM strategy owner, supplier assessment leads, and exception approvers
Enterprise risk management integrationEnterprise risk management documents showing supply chain risk incorporated into the organizational risk register and governance structure
Strategy review recordsMeeting minutes, change logs, and version history demonstrating the strategy is reviewed and updated on the defined frequency
Supplier evaluation criteriaStandardized criteria and procedures used across business units for evaluating supply chain risk during development, acquisition, maintenance, and disposal

Cross-framework mapping

FrameworkControl(s)Coverage
ISO 27001:20226.2 Terms and conditions of employmentPartial
  • CM-10 — Software Usage Restrictions: governs how software usage policies intersect with supply chain acquisition and licensing controls defined in the SCRM strategy
  • PM-09 — Risk Management Strategy: establishes the broader organizational risk management strategy that the SCRM strategy integrates into and aligns with
  • SR-01 — Policy and Procedures: provides the supply chain-specific policies and procedures that operationalize the strategic direction set by PM-30
  • SR-02 — Supply Chain Risk Management Plan: translates the organization-wide SCRM strategy into system-level plans with specific controls and mitigations
  • SR-03 — Supply Chain Controls and Processes: implements the specific controls and processes that the SCRM strategy identifies as required across the organization
  • SR-04 — Provenance: addresses component and service origin tracking, a key verification mechanism referenced in the SCRM strategy’s evaluation criteria
  • SR-05 — Acquisition Strategies, Tools, and Methods: defines the acquisition-specific approaches that align with the SCRM strategy’s requirements for the procurement lifecycle
  • SR-06 — Supplier Assessments and Reviews: executes the supplier evaluation activities that the SCRM strategy mandates for consistent risk assessment
  • SR-07 — Supply Chain Operations Security: implements operational security measures across the supply chain as directed by the SCRM strategy
  • SR-08 — Notification Agreements: establishes the contractual notification requirements between the organization and its suppliers as part of SCRM strategy implementation

The full list of Program Management family controls covers additional organizational-level requirements that complement PM-30.

Frequently asked questions

What is NIST SP 800-53 PM-30

PM-30 is the NIST SP 800-53 control that requires your organization to develop, implement, and maintain an organization-wide supply chain risk management strategy covering the development, acquisition, maintenance, and disposal of systems, system components, and system services. The strategy must express your organization’s supply chain risk appetite and tolerance, define acceptable mitigation controls, and assign roles and responsibilities for consistent application. Unlike system-level plans such as SR-2, PM-30 operates at the organizational and mission/business level to set strategic direction across all programs.

What happens if PM-30 is not implemented

Without PM-30, your organization lacks a documented supply chain risk appetite and tolerance, meaning each business unit applies its own risk thresholds inconsistently. Auditors will flag the absence of an organization-wide SCRM strategy as a finding because NIST SP 800-53 expects explicit documentation of how supply chain risk is evaluated and mitigated across the full development, acquisition, maintenance, and disposal lifecycle. The downstream effect is that system-level supply chain risk management plans have no strategic foundation to build on, weakening your entire SCRM program.

How do you audit PM-30

Auditors verify that an organization-wide supply chain risk management strategy exists and that it addresses risk appetite, tolerance thresholds, acceptable mitigation controls, and roles and responsibilities. They check for evidence that the strategy is implemented consistently across business units, not just documented, by reviewing enterprise risk management integration points and standardized supplier evaluation criteria. Auditors also examine version history, review meeting minutes, and change logs to confirm the strategy is reviewed and updated on the defined frequency or in response to organizational changes.

What is the difference between a supply chain risk management strategy and a plan

A supply chain risk management strategy (PM-30) is an organization-wide document that defines your risk appetite, acceptable mitigation approaches, and governance structure for supply chain risk across all programs and mission areas. A supply chain risk management plan (SR-2) is a system-level document that applies the strategic direction to a specific system, identifying the particular controls, suppliers, and risk mitigations relevant to that system’s supply chain. The strategy sets the boundaries and criteria; the plan executes them for individual systems within those boundaries.

Experience superior visibility and a simpler approach to cyber risk management