SR-5(1): Adequate Supply

SR-5(1): Adequate Supply requires you to put controls in place so you can maintain an adequate supply of critical system components, spares, and supporting items despite supply chain disruption. To operationalize it quickly, define what “adequate supply” means for your mission, assign ownership, implement sourcing and inventory controls, and retain evidence that the controls run on a recurring basis. ¹

Key takeaways:

• Define “adequate supply” for your critical components and mission needs, not for the entire enterprise.
• Implement concrete controls: approved sourcing, alternates, inventory thresholds, and tested contingency procedures.
• Audits are evidence-driven; map SR-5(1) to an owner, a procedure, and recurring artifacts. ¹

The sr-5(1): adequate supply requirement lives in the NIST SP 800-53 supply chain risk management family and is assessed like any other control: auditors will look for a clearly scoped control statement, an accountable owner, operating procedures, and proof that you run the control consistently. The operational goal is straightforward: avoid mission-impacting outages or degraded security because you cannot get required components, replacements, licenses, or supporting materials in time.

In practice, “adequate supply” is not a generic inventory project. It is a risk-based commitment tied to your system boundary, your critical dependencies, and your recovery expectations. If you operate federal information systems or contractor systems handling federal data, SR-5(1) is a practical requirement that touches engineering, procurement, IT operations, and third-party management. ²

This page gives requirement-level implementation guidance you can execute: how to define scope, which controls to deploy, how to evidence them, where teams get stuck in exams, and what to fix first so you can pass an assessment without turning supply chain risk into a never-ending program.

Regulatory text

NIST control enhancement excerpt (SR-5(1)): “Employ the following controls to ensure an adequate supply of {{ insert: param, sr-05.01_odp.02 }}: {{ insert: param, sr-05.01_odp.01 }}.” ¹

What this means for an operator

• NIST is explicitly expecting controls (not informal intent) that ensure you can obtain and maintain a sufficient supply of whatever the parameters represent for your system (commonly critical components, spares, or essential supporting items). ¹
• Because the OSCAL excerpt uses parameter placeholders, your first job is to define the parameter values in your environment (what items are in scope, and what “adequate” means in measurable operational terms). ¹
• Assessors will evaluate SR-5(1) through your implementation statement, procedures, and evidence that the controls are operating. ²

Plain-English interpretation (what you’re committing to)

You must be able to keep critical systems running and recover them as planned even when suppliers fail, parts are backordered, shipping is delayed, or a third party changes terms. “Adequate supply” should be defined as a level of availability that supports your mission and your recovery needs for the system boundary you are assessing.

Treat SR-5(1) as a resilience and continuity control for supply chain dependencies:

• resilience: you can source or substitute critical items without unacceptable disruption;
• continuity: you have pre-planned actions that work under real constraints (lead times, allocations, end-of-life parts, single-source dependencies).

Who it applies to (entity and operational context)

Applies to:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are flowed down through contract, authorization requirements, or agency security requirements. ²

Operational contexts where SR-5(1) becomes “real” quickly:

• Systems dependent on specialized hardware (network gear, endpoint devices, industrial/OT components).
• Systems dependent on licensed software or cloud services where entitlement, capacity, or account access can be constrained by a third party.
• Environments with strict recovery expectations where delays in replacement parts extend outage windows.

What you actually need to do (step-by-step)

Step 1: Set scope and control ownership

1. Name the in-scope system boundary (the authorized system, platform, or environment you are assessing).
2. Assign a control owner with authority across procurement and operations (commonly a joint owner model: IT Ops for inventory + Procurement for sourcing + Security/GRC for oversight).
3. Write a one-paragraph implementation statement describing how your organization ensures adequate supply for in-scope items and how often the control is reviewed. ²

Practical tip: Don’t scope “all enterprise purchasing.” Scope what the system needs to meet availability and recovery expectations.

Step 2: Define “adequate supply” for the system

Create a short, auditable definition that covers:

• In-scope items: critical components, spares, licenses, support contracts, cryptographic hardware, specialized connectors, or other items without which the system cannot operate securely.
• Adequacy criteria: minimum on-hand quantity, maximum acceptable lead time, substitution rules, or reserved capacity with a provider.
• Trigger conditions: what events force action (e.g., supplier EOL notices, sustained backorder, geopolitical restriction, third-party breach, insolvency).

Make adequacy measurable. Auditors can’t test “we keep enough.”

Step 3: Build and approve the “critical supply list”

1. Work with engineering/ops to identify items whose absence causes an outage, security degradation, or inability to restore service.
2. Capture each item with: part number/SKU, vendor/third party, alternates, lead time assumptions, and internal owner.
3. Document why each item is “critical” (tie to architecture diagrams, DR plans, or dependency maps).

This list becomes your core control artifact.

Step 4: Implement sourcing controls (primary and alternate)

Minimum control set most assessors expect to see in practice:

• Approved supplier/third-party list for critical items with procurement gates.
• Second-source options (where feasible): alternate manufacturers, authorized resellers, or functionally equivalent substitutes validated by engineering.
• Contractual assurances for supportability: support SLAs, replacement terms, and continuity expectations for critical providers.

If alternates are not feasible, document compensating controls (increased spares, longer support contracts, design changes).

Step 5: Implement inventory and replenishment controls

Operationalize adequate supply with repeatable mechanisms:

• Stock thresholds (reorder points) for critical spares and consumables.
• Lifecycle monitoring for EOL/EOSL notifications and firmware support windows.
• Segregated storage controls (physical security, environmental controls) for sensitive components where relevant to the system.

If you use a third party for fulfillment, include them in your control boundary and evidence collection.

Step 6: Add disruption playbooks and test them

Create short playbooks for:

• supply interruption (backorder, allocation);
• third-party service restriction (account suspension, region capacity constraints);
• counterfeit/tainted component concern (quarantine and replacement path).

Run a tabletop exercise and capture outcomes. Testing converts your plan into evidence.

Step 7: Map the requirement to recurring evidence (assessment-ready)

Operationalize SR-5(1) the way assessors validate it:

• map to an owner;
• map to a procedure;
• map to recurring artifacts (purchase approvals, inventory reports, exception approvals). ¹

If you track controls in Daydream, treat SR-5(1) like any other assessment object: one owner, one procedure, an evidence calendar, and a place to store time-stamped artifacts that show operation.

Required evidence and artifacts to retain

Keep evidence that is dated, reviewed, and scoped to the system:

Core artifacts

• SR-5(1) control implementation statement and control owner assignment.
• Critical supply list (BOM/spares list) with alternates and rationale.
• Approved supplier/third-party list for critical items/services.
• Inventory policy/procedure for critical components (reorder, approvals, exception handling).
• Records of replenishment actions (POs, receipts, ticketing records) for in-scope items.
• Disruption playbooks and tabletop/test records with follow-up actions.

Operational evidence (recurring)

• Inventory snapshots or reports showing thresholds and current levels.
• Meeting notes or change-control records showing review of supply risks (EOL notices, supplier issues).
• Exceptions: approvals when thresholds are not met, with risk acceptance and compensating controls.

Common exam/audit questions and hangups

Questions you should be ready for

• “Show me what you consider ‘adequate supply’ for this system and where it is documented.” ²
• “Which components are critical, and how did you decide?” ²
• “What happens if your primary supplier can’t deliver?” ²
• “Prove this is operating: show inventory monitoring and replenishment records.” ²

Hangups that cause findings

• No explicit definition of “adequate.”
• No alternates and no compensating controls.
• Evidence exists, but it is not tied to the assessed system boundary.
• Inventory exists, but there is no governance (no thresholds, no review cadence, no exception path).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SR-5(1) as a procurement policy only.
   Fix: connect procurement controls to ops reality: inventory thresholds, spares on hand, and tested disruption procedures.

2. Mistake: Listing “critical components” without ownership.
   Fix: assign an internal owner per item class (network, endpoint, platform, security appliances) who must review changes and risk.

3. Mistake: Assuming cloud means no supply constraints.
   Fix: include cloud dependencies that can become constrained (capacity reservations, account access, region restrictions) and document your fallback plan.

4. Mistake: Evidence is scattered across email and spreadsheets.
   Fix: centralize artifacts by control and by system. Daydream-style control-to-evidence mapping reduces scramble during assessment. ¹

Enforcement context and risk implications

No public enforcement cases were provided for this specific requirement in the supplied source catalog, so you should treat SR-5(1) primarily as an assessment and authorization risk rather than a “find a fine amount” control. What tends to drive impact is operational: inadequate supply can extend outages, delay recovery, or force insecure substitutions under pressure. For federal systems and contractors, those outcomes translate into authorization conditions, POA&M actions, and procurement restrictions tied to security performance expectations. ²

Practical execution plan (30/60/90-day)

First 30 days (Immediate stabilization)

• Assign SR-5(1) control owner and backup; publish a short control statement.
• Define “adequate supply” criteria for the system in writing.
• Produce the first version of the critical supply list with owners and alternates.
• Stand up an evidence folder/register aligned to SR-5(1) (control statement, lists, procedures, sample inventory report). ¹

By 60 days (Controls operating)

• Implement procurement gates for critical items (approved suppliers, approval workflow, exception process).
• Implement inventory thresholds and a replenishment workflow for critical spares.
• Document disruption playbooks for top failure scenarios and align them to incident/BCP processes.

By 90 days (Assessment-ready and repeatable)

• Run a tabletop exercise for a supply disruption scenario; document results and remediation tickets.
• Conduct the first formal management review of supply adequacy and exceptions; record decisions.
• Validate evidence completeness: artifacts are current, dated, and clearly scoped to the system boundary. ²

Frequently Asked Questions

What counts as “adequate supply” for SR-5(1)?

“Adequate” is whatever you define and can defend for the system’s critical items, based on mission and recovery needs. Document measurable criteria (thresholds, lead-time limits, substitution rules) and keep evidence that you monitor against them. ¹

Does SR-5(1) apply to SaaS and cloud-only systems?

Yes, if the system depends on third parties for capacity, access, or entitlements, those are supply constraints in practice. Treat reserved capacity, account continuity, and provider dependencies as in-scope items and document fallback options. ²

We have single-source components. Is that an automatic failure?

No, but it is an assessment risk if you cannot show compensating controls. Increase spares, extend support terms, redesign for substitutability, and document a disruption playbook that has been tested. ²

What evidence do auditors actually want to see?

They want proof the control operates: a defined critical supply list, inventory thresholds, procurement controls, and time-stamped records showing monitoring and replenishment. Tie everything to the specific system boundary under review. ²

How do I map SR-5(1) into a GRC tool without making it busywork?

Create one control record with an owner, one operating procedure, and an evidence schedule that mirrors real operational outputs (inventory reports, PO approvals, exception tickets). Daydream-style mapping keeps SR-5(1) evidence collection predictable and reduces audit scramble. ¹

What’s the fastest way to get to “good enough” for an assessment?

Lock scope to the assessed system, define adequacy criteria, publish the critical supply list with alternates, and produce at least one cycle of monitoring evidence. Then add playbooks and testing to harden the control. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5