SA-18(1): Multiple Phases of System Development Life Cycle

SA-18(1) requires you to embed supply chain risk controls across multiple phases of the system development life cycle (SDLC), not only at procurement or deployment. Operationalize it by defining which SDLC phases you use, assigning control ownership per phase, and retaining evidence that supply chain protections were planned, built, tested, and maintained. ¹

Key takeaways:

• Treat supply chain risk as an SDLC control, with phase-based checkpoints and exit criteria. ¹
• Map SA-18(1) to named owners, documented procedures, and recurring evidence artifacts auditors can sample. ¹
• Prove operation: show artifacts from design, build, test, release, and change/patch cycles, not just a policy. ²

The sa-18(1): multiple phases of system development life cycle requirement is a practical audit test: can you show that supply chain risk considerations are built into how you design, acquire, integrate, and change systems over time? SA-18 sits in the System and Services Acquisition (SA) family and focuses on supply chain risk management; the (1) enhancement narrows the examiner’s lens to SDLC coverage across phases rather than a single point-in-time review. ²

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize SA-18(1) is to treat it like a gating control embedded in delivery workflows. You are not trying to “do more paperwork.” You are trying to create a repeatable mechanism that forces the right questions at the right times: What third parties are in the bill of materials? What code and components are introduced? What are the trust boundaries? What assurance evidence do we require before release? What changes require re-validation?

This page gives requirement-level implementation guidance: applicability, a step-by-step operating procedure, evidence to retain, common audit traps, and an execution plan you can hand to Engineering, Security, and Procurement with minimal translation. ¹

Regulatory text

Excerpt (as provided): “NIST SP 800-53 control SA-18.1.” ¹

What the operator must do (requirement intent): Implement SA-18’s supply chain risk management expectations across multiple SDLC phases for systems in scope, and be able to demonstrate that coverage with phase-specific procedures and evidence. ¹

Because the provided excerpt is minimal, auditors will evaluate you on how credibly you translate “multiple phases of SDLC” into (a) defined phases, (b) mandatory activities per phase, and (c) proof those activities actually occurred for representative systems/releases. ²

Plain-English interpretation

You must bake third-party and supply chain risk controls into the way systems are built and changed. That means:

• During requirements and design, you identify supply chain dependencies and define assurance requirements.
• During build and integration, you control what third-party components enter the system and how they are verified.
• During test and release, you validate that supply chain controls are met before deployment.
• During operations and change, you keep validating when updates, patches, new vendors, or new components are introduced. ²

A policy that says “we manage supply chain risk” will not satisfy SA-18(1) if you cannot show phase-based execution.

Who it applies to

Entity types (typical):

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational contexts where SA-18(1) is commonly tested:

• Systems built in-house with open-source dependencies.
• Systems composed of SaaS, APIs, managed services, or cloud marketplaces (third-party concentration).
• Major system upgrades, platform migrations, and “rapid release” engineering models where changes happen frequently.
• Environments with multiple development teams and inconsistent delivery practices, which creates uneven SDLC control coverage. ²

If you run a mixed environment, define a scope statement: which systems are “in,” which SDLC model(s) you use (Agile, DevOps, waterfall, hybrid), and how SA-18(1) maps to each.

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

1) Define your SDLC phases (make them auditable)

Write down the phases you will govern. Keep the list short and map it to how work happens. Common phase labels that work in practice:

• Plan/Requirements
• Architecture/Design
• Build/Acquire
• Integrate
• Test/Validate
• Release/Deploy
• Operate/Change (including patching and vendor changes)

Your goal is not a textbook SDLC. Your goal is stable checkpoints you can enforce and evidence.

2) Assign ownership per phase (RACI that matches reality)

SA-18(1) breaks when “GRC owns it” but engineering owns the workflow. Set clear owners:

• Product/Engineering: requirements, architecture, release gates
• Security: threat modeling, component verification expectations, security test criteria
• Procurement/TPRM: third-party onboarding and assurance requirements
• IT/Operations: patch/change controls and re-validation triggers

Document a RACI, then tie it to a system-level SDLC procedure so responsibility is not abstract. ¹

3) Create phase-based supply chain checkpoints with exit criteria

For each phase, define the minimum supply chain activities and what “done” means. Example control checkpoints you can implement quickly:

Plan/Requirements

• Identify third-party dependencies (SaaS, libraries, cloud services, managed providers).
• Define assurance needs (security requirements, logging requirements, incident notification expectations).

Architecture/Design

• Document trust boundaries and third-party data flows.
• Identify “high-risk” third-party touchpoints that require stronger assurance or compensating controls.

Build/Acquire & Integrate

• Maintain a component inventory for third-party software and services used by the system.
• Require approvals for introducing new third parties or materially changing an existing third party’s scope.
• Record verification steps (e.g., internal review outcomes, acceptance of third-party attestations where applicable).

Test/Validate

• Run security testing that covers third-party integration points.
• Validate configuration baselines for third-party services (where you control settings).

Release/Deploy

• Require a release sign-off that includes supply chain criteria (no unapproved third-party additions; required evidence attached).
• Ensure rollback plans consider third-party service dependencies.

Operate/Change

• Define triggers for reassessment: new vendor, major version upgrade, critical patch, significant configuration change, new integration.
• Periodically re-confirm that third-party controls remain in place (contractual commitments, technical configurations, monitoring). ²

4) Embed checkpoints into tooling, not just documents

Auditors look for operationalization. Put the checkpoints into:

• Ticket templates (required fields for “new third party,” “new library,” “data shared externally”).
• CI/CD gates (required approvals, required security checks before merge/release).
• Change management workflows (risk review required when triggers occur).
• Procurement intake (security requirements included before contract signature).

If you need a fast path, start with two “hard stops”: (a) no new third party without intake review, and (b) no production release without a release checklist that includes supply chain items.

5) Define the evidence cadence and sampling approach

Decide how you will prove SA-18(1) for auditors:

• Pick a representative set of systems (high impact and typical impact).
• For each system, retain evidence from multiple releases or changes that show phase coverage.
• Ensure evidence is retrievable by system name, release ID, or change ticket.

Daydream (as a practical resolution) helps teams keep control ownership, procedures, and recurring evidence artifacts mapped to SA-18(1) so you can produce a clean audit packet without scrambling across tools. ¹

Required evidence and artifacts to retain

Keep evidence that demonstrates phase coverage and repeatability:

Governance artifacts

• SDLC policy/standard that defines phases and required supply chain checkpoints.
• SA-18(1) control mapping: owner, procedure, and evidence list. ¹
• RACI for phase activities.

System-level artifacts ¹

• Architecture diagrams showing third-party dependencies and data flows.
• Third-party/component inventory (system bill of materials at the service/provider level; include libraries where feasible).
• Third-party onboarding records: risk review, security requirements, approvals.
• Secure design review or threat model outputs that address third-party interfaces.

Build/test/release artifacts

• Change tickets showing approval for new third-party components/services.
• Release checklist with supply chain items completed and approver identity.
• Test results relevant to third-party integrations (e.g., config reviews, security tests).

Operations artifacts

• Change management logs for vendor/service changes and major upgrades.
• Evidence of reassessment when triggers occur (ticket + review notes + decision).
• Monitoring/incident records that demonstrate you can detect issues tied to third parties (where in scope for your program). ²

Common exam/audit questions and hangups

Auditors typically probe these points:

1. “What are your SDLC phases, and where is supply chain risk addressed in each?” Expect to show the matrix.
2. “Show me evidence from a real release.” They will pick a system and ask for end-to-end artifacts.
3. “How do you prevent teams from adding a new third party without review?” They want workflow enforcement, not reminders.
4. “What triggers a re-review after go-live?” If your answer is vague, SA-18(1) will fail in operations.
5. “Who owns this control?” “Security” is not enough; they will look for engineering execution and procurement alignment. ²

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating SA-18(1) as procurement-only	“Multiple SDLC phases” requires broader coverage	Add design, release, and change gates tied to third-party events
Only keeping a policy	Auditors test operating effectiveness	Retain release tickets, checklists, and approvals
No defined triggers for re-validation	Post-deploy changes introduce new supply chain risk	Define change triggers and require reassessment in the change workflow
“Everyone is responsible” ownership	Diffuse accountability leads to gaps	Assign a primary owner and phase owners with clear deliverables
Inventory exists but is stale	Evidence becomes non-credible	Tie updates to release/change events so the inventory updates with work

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-18(1), so this page does not list case examples.

Risk-wise, SA-18(1) failures show up as: unmanaged third-party dependencies, unclear provenance of components, missing approvals for external integrations, and inability to prove that security requirements were applied throughout delivery and change cycles. Those gaps increase the likelihood that a third-party component or service becomes an unmonitored attack path or operational single point of failure. ²

Practical 30/60/90-day execution plan

Days 0–30: Stand up the minimum auditable structure

• Define SDLC phases used by your teams and publish a one-page SA-18(1) phase matrix.
• Assign control owner and phase owners; publish RACI.
• Add a “new third party / new component” flag to intake and change tickets.
• Define the evidence list you will retain per release and per material change. ¹

Days 31–60: Put gates into workflows and pilot on real systems

• Implement release checklist requirements for two to three representative systems.
• Require documented approval for introducing a new third party.
• Build a lightweight inventory process tied to releases/changes (start with service providers and major libraries).
• Run an internal “mock audit” sampling recent releases and verify you can retrieve artifacts quickly.

Days 61–90: Scale, tune triggers, and harden evidence quality

• Expand the controls to additional systems and teams; standardize templates.
• Finalize re-validation triggers and embed them in change management.
• Add periodic review for high-impact third parties (cadence set by your risk program).
• Centralize evidence collection and mapping (Daydream is a clean way to keep SA-18(1) ownership, procedures, and recurring artifacts aligned for audit readiness). ¹

Frequently Asked Questions

Does SA-18(1) require a specific SDLC model like waterfall?

No. SA-18(1) cares that you address supply chain risk across multiple SDLC phases you actually use and can prove it with evidence. ²

What counts as “multiple phases” for auditors?

Define phases in your SDLC standard, then show artifacts from more than one point in delivery and operations, such as design review plus release approval plus change-triggered reassessment. ²

Do open-source libraries fall under this requirement?

If they are part of your supply chain for a system, treat them as dependencies that should be identified and governed through your SDLC checkpoints, even if procurement is not involved. ²

We use SaaS heavily. How do we show SDLC “phases” for configuration changes?

Treat SaaS configuration and integration work as SDLC activity. Use change tickets, design notes for integrations, test evidence for access controls/logging, and release approvals for production changes. ²

What is the minimum evidence set to pass a basic assessment?

Auditors usually accept a clear phase matrix, named ownership, and sampled system evidence that shows supply chain controls executed at design/build/test/release and again during a material change. ²

How do we keep SA-18(1) from becoming a manual paperwork exercise?

Put required fields and approvals into tickets and CI/CD gates, then automatically retain artifacts (tickets, checklists, approvals) as your evidence set rather than writing separate narratives. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5