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

SA-4(5) sits in the “System and Services Acquisition” family, so it is less about how your engineers configure systems day-to-day and more about how you buy systems and services safely. The control is aimed at a common failure mode: you procure a product or service, but you cannot later prove what configuration you received, how it should be hardened, what can be changed, and how changes are controlled.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-4(5) as a contracting and acceptance-testing requirement. Your job is to ensure developers (including third-party developers delivering products or managed services) are contractually obligated to provide specific configuration artifacts and that your teams verify them during onboarding and major changes.

Because the excerpt in the catalog is a stub (“Require the developer… to:”), you should operationalize SA-4(5) by building a requirement “control card,” defining a minimum evidence bundle, and running recurring control health checks so you can show ownership and ongoing operation during audits and customer due diligence. ¹

Regulatory text

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

Operator interpretation (what you must make true): Because the excerpt provided here is not the full set of bullets that typically follow this enhancement, you should treat SA-4(5) as a requirement to impose explicit configuration obligations on the developer as part of acquisition and delivery. Your program must be able to show, with contract language and delivery evidence, that the developer:

• Delivered the system/component/service with defined configurations (what is set, what “good” looks like).
• Provided configuration documentation sufficient for secure deployment and ongoing administration.
• Supports controlled configuration changes (who can change what, how changes are requested, tested, approved, and recorded).

This is requirement-level work: you’re not trying to harden every setting yourself. You’re making sure the developer gives you what you need to harden, verify, and govern configurations throughout the lifecycle. ¹

Plain-English interpretation

You must be able to answer these audit questions without scrambling:

1. What configuration did we buy and receive? (baseline, version, default settings, secure settings)
2. How do we configure it securely? (vendor/developer hardening guidance, required parameters, dependencies)
3. How do we control changes after go-live? (change paths, approvals, testing, rollback, logging)
4. How do we prove it? (contract requirements + deliverables + acceptance evidence)

If any of those are “tribal knowledge” or buried in tickets without a clear link to contractual deliverables, SA-4(5) will be hard to defend.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems and contractor systems handling federal data, where NIST SP 800-53 controls flow down through ATO/FedRAMP-style requirements or agency contracts. ¹

Operational contexts where it matters most:

• Custom-developed systems (internal dev or outsourced dev shop).
• COTS products where the supplier is effectively the “developer” of the component you deploy.
• System services such as managed hosting, managed security services, SaaS platforms, or API services where you depend on the provider’s configuration and change practices.
• Embedded components (agents, libraries, appliances) that bring configuration risk with them.

Internal stakeholders you will need:

• Procurement / vendor management (contracts, SOWs, purchase orders)
• Security architecture / engineering (baseline and acceptance criteria)
• IT operations / platform teams (configuration management + change control integration)
• System owner / product owner (risk acceptance and go-live sign-off)
• Legal (contract terms, audit rights, deliverables enforcement)

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

1) Create a SA-4(5) requirement control card (one page)

Use a simple template so you can show consistent operation:

• Objective: Ensure developers deliver documented, secure, controllable configurations.
• Owner: Name a role (e.g., Third-Party Risk Manager + Security Architect as approver).
• Scope: Which acquisitions trigger it (new systems, major versions, new managed services).
• Trigger events: New third party onboarding, renewal with scope change, major release, re-architecture.
• Procedure: Steps 2–7 below.
• Exceptions: Who can approve exceptions and what compensating controls are required. This aligns to the recommended practice to define ownership, trigger events, execution steps, and exception rules. ¹

2) Define configuration deliverables you will require from the developer

Write these as procurement-ready requirements. Common deliverables:

• Configuration baseline (what settings/parameters are expected for production)
• Hardening guide (secure deployment steps, insecure defaults to change)
• Configuration items list (what is configurable and where it is stored)
• Supported configuration change process (how changes are requested, tested, approved)
• Configuration rollback/recovery guidance
• Logging/telemetry configuration requirements (what logs/metrics must be enabled)

Keep the list short enough to enforce. If your teams cannot review it, you will not collect it.

3) Add the requirements to contracts and third-party onboarding checklists

Operationally, SA-4(5) fails when security requirements live only in policy. Put the requirements into:

• MSA/SOW exhibits or security addendum
• Product/security requirements document for custom development
• Third-party onboarding checklist that procurement must not bypass

Practical contracting terms to include:

• Configuration documentation as a delivery milestone
• Right to receive configuration artifacts and updates at defined events (release, patch, material change)
• Notice obligations for material configuration changes that affect security

4) Build acceptance criteria that test the configuration requirements

Create a lightweight “configuration acceptance test” that happens before production:

• Validate baseline matches your required secure settings
• Confirm hardening steps are complete and reproducible
• Confirm who has permission to change configuration (and how it is logged)
• Confirm rollback approach works in a test environment

Tie the results to a go-live approval. If you cannot block go-live, you do not have control strength.

5) Establish a configuration evidence bundle (minimum set)

Define the “minimum evidence bundle” so you can respond to audits quickly, consistent with recommended best practice. ¹

Minimum bundle (store in your GRC repository or a controlled evidence folder):

• Contract/SOW section that imposes configuration deliverables
• Developer-delivered baseline and hardening documentation (versioned)
• Your internal review/approval record (security architecture sign-off)
• Acceptance test results (screenshots, scripts output, tickets)
• Exception approvals (if any) with compensating controls
• Location of the implemented baseline (IaC repo link, CM tool record, system config snapshot)

6) Operationalize change control for developer-driven changes

Many services change under you. Require and implement:

• A channel for change notifications (release notes, customer advisories)
• An internal triage workflow: security impact review, test plan, approval, deployment
• A way to record the configuration delta (what changed, when, who approved)

For SaaS or managed services where you cannot control the provider’s underlying configuration, focus your requirements on what you can control: tenant settings, security features, logging, identity integrations, and notice/attestation rights.

7) Run recurring control health checks and close gaps

Treat SA-4(5) as continuously operating, not a one-time procurement checkbox:

• Sample a set of in-scope third parties and verify evidence is current and complete
• Track remediation items to validated closure with owners and due dates This aligns with the recommended practice of recurring control health checks and tracked remediation. ¹

Required evidence and artifacts to retain (audit-ready list)

Keep artifacts in a single, named evidence location per system/service:

• SA-4(5) control card (owner, scope, triggers, exceptions)
• Contractual obligations (security addendum, SOW exhibit, or procurement requirements)
• Developer configuration deliverables (baseline, hardening guide, admin guide, change notes)
• Implementation evidence (IaC snippets, CMDB/CM tool records, secure configuration screenshots)
• Validation evidence (test plan, results, sign-off)
• Exception package (risk rationale, compensating controls, approval)
• Ongoing change records (release/change notices + internal assessments)

Common exam/audit questions and hangups

Auditors and assessors tend to get stuck on traceability and scope. Expect questions like:

• “Show me where the developer is required to provide configuration documentation.” (They want contract language.)
• “How do you verify the delivered configuration matches your baseline?” (They want acceptance evidence.)
• “What happens when the provider changes configuration after onboarding?” (They want change governance.)
• “Who owns this control and how do you know it’s operating?” (They want an owner, cadence, and proof.) ¹

Common hangup: teams produce a hardening standard, but cannot show it was imposed on the developer or validated on delivery.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating SA-4(5) as an internal hardening standard only.
   Fix: Make configuration a developer deliverable with contractual hooks and onboarding gates.

2. Mistake: Collecting a PDF once and never updating it.
   Fix: Require updated configuration documentation at major releases and material changes, then attach it to change records.

3. Mistake: No exception process.
   Fix: Add an exception path with defined approvers and compensating controls; store the exception package in the evidence bundle.

4. Mistake: Evidence scattered across email, tickets, and chat.
   Fix: Define a minimum evidence bundle and retention location per system/service. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific enhancement, so you should treat “enforcement” here as assessment failure risk: SA-4(5) gaps often surface during ATO work, FedRAMP-style reviews, and customer security reviews. The practical risk is predictable:

• Misconfigurations persist because nobody knows the intended baseline.
• Incident response slows because configuration state and change history are unclear.
• You cannot prove supply chain expectations were set, which weakens your position in disputes with third parties.

A practical 30/60/90-day execution plan

First 30 days (set the foundation)

• Assign an owner and publish the SA-4(5) control card.
• Define your standard configuration deliverables list (keep it enforceable).
• Add required contract clauses/exhibit language to procurement templates.
• Stand up the evidence folder structure ¹ and the minimum evidence bundle checklist.

Days 31–60 (implement on live procurement and one pilot)

• Pilot on one in-flight onboarding or renewal: collect configuration deliverables and run acceptance checks.
• Train procurement and security approvers on the new gate (what blocks go-live).
• Create the exception workflow and approval routing.

Days 61–90 (scale and prove operation)

• Roll the requirement into all new in-scope acquisitions.
• Perform a control health check on a small sample of existing third parties and log remediation tasks.
• Build a dashboard view (even a spreadsheet) that shows: in-scope third parties, evidence status, exceptions, remediation.

Where Daydream fits naturally: use Daydream to standardize the control card, define the evidence bundle per execution cycle, and track control health checks and remediation to closure so you can show sustained operation without rebuilding the system for each audit. ¹

Frequently Asked Questions

Does SA-4(5) apply to SaaS providers where we can’t access underlying system configurations?

Yes, treat the SaaS provider as the “system service” developer and focus on tenant-level configurations, security features you can control, and contractual obligations for configuration documentation and change notices. Document what is out of scope and why in your control card. ¹

What’s the minimum we need in the contract to satisfy SA-4(5)?

Require configuration documentation and a defined baseline as deliverables, require updates at material changes, and require a change-notice process. Then tie those deliverables to acceptance before production go-live. ¹

How do we prove we validated the configuration, not just collected documents?

Keep acceptance test evidence: review checklist sign-off, test results, configuration snapshots, or IaC pull request approvals that match the baseline. Auditors want traceability from requirement to validation output. ¹

Who should own SA-4(5), security or procurement?

Put operational ownership with security/GRC and make procurement responsible for execution of the contracting step. A shared RACI prevents gaps where security writes standards but procurement buys without them. ¹

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

Use an exception process with documented rationale and compensating controls, and consider alternate suppliers for high-risk systems. Keep the refusal and the approved exception package in the evidence bundle. ¹

How often should we re-check configurations for ongoing compliance?

Re-check at trigger events such as major releases, renewals with scope changes, and material incidents, then add periodic control health checks based on your risk tiering. Record the triggers and cadence in the control card so you can show consistent operation. ¹

Footnotes

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