SA-4(5): System, Component, and Service Configurations

To meet the sa-4(5): system, component, and service configurations requirement, you must contractually require developers (internal teams and third parties) to provide, document, and deliver secure configuration specifications for the systems, components, and services they build or supply, and you must be able to prove you received and operationalized those configurations. This is a supply-chain control: write it into requirements, verify delivery, and retain evidence.

Key takeaways:

• Put explicit configuration deliverables into development and third-party contracts, SOWs, and acceptance criteria.
• Treat “configuration” as a controlled artifact: baseline, hardening parameters, dependencies, and secure defaults.
• Audit readiness hinges on evidence that configurations were required, received, reviewed, and used in build/deploy.

SA-4(5) sits in the NIST SP 800-53 “System and Services Acquisition” family and targets a common failure mode: you buy or build a system, but you cannot prove what secure configuration it requires, what it shipped with, or what configuration assumptions exist for safe operation. In practice, exam teams and assessors look for two things: (1) your acquisition and development requirements explicitly demand configuration specifications and secure configuration guidance from the developer, and (2) your operations teams actually implement those configurations (or document approved deviations).

This requirement matters most when you rely on third parties (cloud/SaaS, managed service providers, device manufacturers, software suppliers) and when you have multiple environments (dev/test/prod) where drift happens. SA-4(5) is also a forcing function for internal dev teams: “developer” includes your own engineering org if they produce systems/components/services consumed by the business.

If you operationalize only one thing: make configuration deliverables part of “definition of done” and vendor acceptance, then store them in a governed repository tied to change management. That turns SA-4(5) from a paper control into something you can run.

Regulatory text

Excerpt: “Require the developer of the system, system component, or system service to:” ¹

What an operator must do with this text: SA-4 is the control for acquisition contracts; SA-4(5) is an enhancement focused on configurations. Even though the excerpt provided here is incomplete, the operational obligation is clear from the control’s title and context in SA-4: you must impose specific configuration-related requirements on the developer and ensure those requirements produce deliverables you can use to securely implement and operate the system or service. Keep your implementation aligned to NIST SP 800-53 Rev. 5 ².

Plain-English interpretation (requirement intent)

SA-4(5) means: Don’t accept a system/component/service unless the developer provides the configuration information you need to deploy and run it securely. That includes secure defaults, required hardening settings, configuration constraints, and how to verify the configuration remains correct over time.

Think of it as “secure configuration as a deliverable,” not “security guidance in an email.”

Who it applies to

Entity scope (typical):

• Federal information systems and programs adopting NIST SP 800-53 controls ².
• Contractors and service providers handling federal data or operating federal systems where 800-53 is flowed down contractually ².

Operational scope (where you feel this control):

• Procurement / sourcing: contract language, SOWs, RFP security schedules.
• Engineering / product security: internal SDLC requirements and release checklists.
• IT operations / platform teams: golden images, IaC modules, Kubernetes baselines, endpoint hardening, cloud account guardrails.
• Third-party risk management (TPRM): onboarding evidence and ongoing change notifications tied to configuration changes.

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

1) Define what “configuration deliverables” mean in your environment

Create a short standard that lists what you expect from any developer (internal or third party). Keep it practical and testable. Example deliverables to require:

• Configuration baseline for each environment type (prod vs non-prod), including secure defaults and prohibited settings.
• Hardening guide mapped to the technology (OS, DB, app server, container, cloud service).
• Dependency and integration configuration (ports, protocols, identity/SSO settings, logging/auditing settings).
• Configuration drift detection method (how to validate settings remain as intended).
• Upgrade/patch configuration impacts (what breaks or changes when versions change).

Output artifact: “Configuration Requirements Standard” (one-pager + appendix per technology).

2) Flow the requirement into acquisition and SDLC gates

For third parties, add a contract/RFP clause and acceptance criteria. For internal dev, add to SDLC checklists.

Minimum language to include (operator-focused):

• The developer must provide configuration documentation sufficient to securely deploy and operate the deliverable.
• The developer must disclose secure defaults and any settings that materially affect confidentiality, integrity, availability, logging, authentication, authorization, encryption, or network exposure.
• The developer must notify you of configuration changes in new releases or service updates.

Make this enforceable by tying it to:

• Acceptance testing: “no config docs, no go-live.”
• Payment milestones: configuration package delivered and approved.
• Security sign-off: AppSec / GRC reviews config artifacts before production.

3) Build a configuration intake and review workflow

Treat configuration artifacts like code:

• Intake location: a controlled repository (GRC evidence vault, document management system, or version-controlled repo for technical artifacts).
• Review: assign named reviewers (platform owner + security).
• Approval: record disposition (approved, approved with exceptions, rejected).
• Exception handling: deviations require a ticket, risk acceptance, compensating controls, and an owner.

A workable pattern is a single “Configuration Package” checklist required for go-live.

4) Convert developer guidance into enforced technical baselines

SA-4(5) fails in practice when documentation exists but nothing changes in operations. Convert the received configuration into enforceable controls:

• Golden images / hardened templates (VM images, container base images).
• Infrastructure-as-code modules (cloud guardrails, network policies, IAM scaffolding).
• Configuration management policies (GPO/MDM profiles, CIS-aligned settings if you already use them).
• Runtime policies (Kubernetes admission controls, cloud config rules).

Tie each baseline to a system identifier and environment so you can demonstrate consistent implementation.

5) Validate configuration in pre-prod and monitor drift in prod

Add objective checks:

• Pre-prod: configuration verification steps in deployment pipelines (linting, policy-as-code checks, build attestation where available).
• Prod: periodic configuration scans or continuous monitoring, with alerts when critical settings change outside change management.

Document what you check and how exceptions are handled.

6) Make it sustainable with ownership and recurring evidence

Assign:

• Control owner: usually Product Security, GRC, or IT Risk.
• Implementers: platform/infra owners and application owners.
• Third-party relationship owners: procurement + TPRM.

Set a recurring cadence aligned to change: review configuration packages on major releases, new integrations, and material environment changes.

Required evidence and artifacts to retain

Assessors will ask for proof that you (a) required it, (b) received it, and (c) implemented it. Keep:

• Contract clauses / SOW language / security schedules requiring configuration deliverables.
• RFP responses or third-party security addendum confirming configuration documentation.
• Configuration package artifacts (baseline, hardening guide, secure defaults, drift/validation method).
• Review and approval records (tickets, sign-off notes, meeting minutes).
• Implementation evidence:
  • Links to hardened templates, IaC repos, golden images.
  • Change records showing configuration applied to production.
  • Monitoring outputs showing drift detection and remediation.
• Exception/risk acceptance records for deviations from the baseline.

Tip: In Daydream, teams often map SA-4(5) to a single control owner and attach the recurring evidence list so audits stop turning into archaeology.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where you require developers to provide secure configuration guidance.” (They want contract language or SDLC gate evidence.)
• “How do you know production matches the approved configuration?” (They want monitoring or verification, not a policy statement.)
• “How do you handle configuration changes introduced by patches or service updates?” (They want change management linkage.)
• “Where are these artifacts stored, and who approves them?” (They want governance and access control.)

Hangups that slow audits:

• Configuration docs exist but are scattered across email, Slack, and vendor portals.
• No traceability between “vendor hardening guide” and “what’s implemented in prod.”
• Exceptions exist but lack an owner, expiration, or compensating controls.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SaaS as “no configuration.”
   Avoid it: SaaS still has admin/security settings (SSO, MFA, logging, retention, sharing controls). Require a “tenant configuration baseline.”

2. Mistake: Accepting marketing/security whitepapers instead of configuration specs.
   Avoid it: Require a configuration checklist with named settings, values/ranges, and verification steps.

3. Mistake: One baseline for everything.
   Avoid it: Maintain baselines by technology and environment type (prod/non-prod), and document justified differences.

4. Mistake: No change trigger.
   Avoid it: Define triggers that require a refresh of the configuration package (major release, new integration, identity model change, hosting change).

5. Mistake: Evidence without ownership.
   Avoid it: Put a single accountable owner on SA-4(5) and name the operational approvers per system.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement risk as indirect: SA-4(5) is commonly tested in assessments because weak configuration control leads to preventable exposure (misconfigurations, default credentials, excessive access, missing logs). The practical risk is failed authorization, delayed ATO, audit findings, and increased incident likelihood. Align your implementation to NIST SP 800-53 Rev. 5 expectations and keep artifacts assessment-ready ².

Practical 30/60/90-day execution plan

First 30 days (establish the requirement and intake path)

• Assign SA-4(5) control owner and define “developer” scope (internal dev, third parties).
• Publish a configuration deliverables checklist (minimum viable).
• Add standard contract/SOW language and an SDLC go-live gate.
• Stand up a single repository location and naming convention for configuration packages.

Days 31–60 (operationalize in one pilot and one third party)

• Pilot with one high-impact system and one key third party (SaaS or managed service).
• Run the intake-review-approval workflow end-to-end.
• Convert at least one set of config guidance into an enforceable baseline (template/IaC/MDM profile).
• Create an exception template with owner, rationale, compensating controls, and review trigger.

Days 61–90 (scale and make it auditable)

• Roll out the requirement to additional systems via procurement and SDLC controls.
• Add drift detection or periodic verification for the pilot systems.
• Build an audit packet template: contract clause + config package + approval + implementation proof + exceptions.
• In Daydream, map SA-4(5) to the owner, procedure, and recurring artifacts so evidence collection becomes routine rather than event-driven.

Frequently Asked Questions

Does SA-4(5) apply to internal development teams, or only third-party suppliers?

It applies to any “developer” of the system, component, or service, which includes internal teams if they develop deliverables used in your environment. Treat internal product teams as suppliers with required configuration deliverables.

What counts as a “configuration” for SaaS where we don’t control infrastructure?

Tenant and admin settings are configuration: identity/SSO, MFA policies, logging/audit settings, retention, data sharing, API access, and integration permissions. Require the provider to document secure defaults and your required tenant baseline.

What’s the difference between SA-4(5) and general configuration management controls?

SA-4(5) forces configuration requirements into acquisition and development deliverables. Configuration management controls focus on operating and controlling changes after deployment; you typically need both.

How do we prove we “operationalized” the developer’s configuration guidance?

Keep a trace from the received configuration package to the implemented baseline (templates/IaC/config profiles) and to verification output (scan results, drift alerts, or change records). Auditors look for this chain.

What if the third party refuses to provide detailed configuration specs?

Document the refusal, escalate through procurement, and treat it as a risk decision. Where you proceed, record compensating controls and a plan to reduce dependency or add technical guardrails around the service.

How should we store configuration packages so audits are painless?

Store them in a controlled repository with consistent naming, versioning, and an approval record linked to the system and release. Daydream works well as the system-of-record for the requirement mapping and evidence index, with technical artifacts linked out to your engineering repos.

Footnotes

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

2. NIST SP 800-53 Rev. 5