SA-10: Developer Configuration Management

SA-10: developer configuration management requirement means you must contractually and operationally require your system developer (internal team or third party) to run disciplined configuration management throughout development, and you must be able to prove it with concrete artifacts (baselines, change control, versioning, and records). Operationalize SA-10 by embedding these requirements in SDLC gates and supplier due diligence.

Key takeaways:

• Treat “developer” broadly: internal engineers, integrators, SaaS providers, and component suppliers who build or modify your system.
• Make configuration management auditable: defined baselines, controlled changes, tracked versions, and retained records.
• Build it into procurement and SDLC: contract clauses + CI/CD enforcement + evidence collection mapped to an owner.

Compliance teams often inherit systems built by engineering teams or third parties, then get asked to “show NIST control coverage” during an ATO, customer assessment, or internal audit. SA-10 is one of those controls where intent is simple, but evidence is where teams fail: you can’t just say “we use Git.” You need to show that the developer’s configuration management is defined, followed, and produces reliable records.

The control is in the System and Services Acquisition (SA) family, so it sits at the intersection of supplier governance and SDLC execution. The practical job for a CCO, GRC lead, or Compliance Officer is to (1) decide which developers and development activities are in scope, (2) require a configuration management approach that meets your system risk, and (3) collect artifacts that a reviewer can trace from baseline to approved change to deployed version.

This page gives requirement-level guidance you can implement quickly: scoping, contract language targets, SDLC hooks, evidence checklists, audit questions, and a phased execution plan.

Regulatory text

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

Operator interpretation: SA-10 is a “make the developer do it” control. Your organization (as the acquirer/operator) must require the developer to perform configuration management for the system, components, or services being developed. The excerpt is short in the provided source, but the operational expectation is consistent across NIST 800-53 programs: define how configuration items are identified and controlled; establish baselines; control and approve changes; track versions; and keep records that show what changed, who approved it, and what is running now ².

What auditors look for: proof that configuration management is not ad hoc. They will test whether your developer’s practices create integrity and traceability from code/config changes through build and deployment, and whether you can produce records on demand.

Plain-English requirement interpretation

You must ensure the party building or modifying your system uses configuration management that prevents untracked or unauthorized changes. “Configuration” here includes more than source code:

• Infrastructure definitions (IaC templates, cluster manifests)
• Application configuration (feature flags, environment variables, secrets references)
• Build and release definitions (pipelines, build scripts)
• Dependencies and components (libraries, container base images)
• Documentation tied to the build/release (release notes, change tickets)

If you cannot reconstruct what changed and why for a given release, you are unlikely to satisfy SA-10 in practice.

Who it applies to

In-scope entities

• Federal information systems and programs aligned to NIST SP 800-53 ².
• Contractor systems handling federal data, including system components or services delivered to federal customers ².

In-scope operational contexts

• Internal development: your engineering teams building or configuring production systems.
• Third-party development: SaaS providers, MSPs, integrators, custom dev shops, and component manufacturers that deliver code, images, appliances, or managed services.
• Hybrid models: you build the app, a third party runs the platform; both must have configuration management requirements aligned and evidenced.

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

1) Name the control owner and define scope boundaries

• Assign a control owner (often AppSec, DevOps, or Platform Engineering) and a GRC coordinator accountable for evidence collection.
• Define which systems/components/services are in scope (start with those processing regulated or federal data).
• Identify “developers” in your ecosystem: internal teams and third parties who can change production behavior.

Deliverable: SA-10 control statement with owner, scope, and where evidence lives ².

2) Set minimum configuration management requirements for developers

Create a short, enforceable standard your developers must follow. Minimum requirements to document:

• Configuration item inventory: what artifacts are controlled (repos, IaC, pipeline definitions, base images, critical configs).
• Baseline definition: what constitutes an approved baseline for production (tagged releases, signed images, approved templates).
• Change control: how changes are requested, reviewed, approved, and linked to deployments.
• Version control rules: branching strategy, protected branches, required reviews, commit signing if your risk warrants it.
• Build/release traceability: ability to trace a production deployment to a specific commit/build artifact.
• Access control expectations: who can approve/merge/release and how access is granted/removed (tie to IAM processes).

Practical tip: Keep this as a “developer CM standard” that can be attached to contracts and referenced in SDLC procedures, rather than a long policy nobody can implement.

3) Embed requirements into third-party contracting and due diligence

For third parties that develop or modify your system:

• Put the CM standard into MSAs/SOWs or security addenda.
• Require right to audit or at least evidence-on-request (redacted where needed).
• Require notification of material changes affecting your service or components.
• Confirm their SDLC and CM tooling (ticketing + version control + CI/CD + artifact repository) supports traceability.

If a third party refuses to provide any CM artifacts, document the risk decision and compensating controls. That risk acceptance will be a focal point in audits.

4) Implement SDLC gates that make CM real

Policy alone fails. Add technical and process gates:

• Branch protections: require PR reviews, block direct pushes to protected branches.
• Mandatory linking: require change tickets/security issues linked to PRs and releases.
• Immutable build artifacts: store signed or at least uniquely versioned build outputs in an artifact repository.
• Release approvals: define who can promote to production and how approvals are captured.
• Configuration drift checks: for IaC-managed environments, enforce reconciliation and alerting on drift.

5) Define how you will capture and retain evidence

Decide what “good evidence” looks like and how often you snapshot it. Evidence must be reproducible and attributable to dates/releases. Automate collection where possible (export reports from Git platforms, CI/CD systems, ticketing tools).

A common pattern: a quarterly “SA-10 evidence pack” per high-impact system plus on-demand retrieval for specific releases.

6) Test the control like an auditor would

Run a tabletop test:

• Pick a production release from last quarter.
• Reconstruct: request/ticket → PR → approvals → build → artifact → deployment → rollback plan.
• Verify you can show who approved what and when, and that the deployed version matches the records.

Record gaps as findings and route them through your remediation process.

Required evidence and artifacts to retain

Use this as your SA-10 evidence checklist. Tailor to system criticality.

Evidence category	Examples of acceptable artifacts	What it proves
CM standard / procedure	Developer CM standard; SDLC procedure with CM steps	Requirements exist and are actionable
Baseline definition	Release tagging policy; baseline approval record	There is an “approved starting point”
Version control records	Repo settings export; protected branch rules; PR history	Changes are controlled and reviewed
Change control linkage	Tickets linked to PRs/releases; change approvals	Changes are justified and approved
Build/release traceability	CI/CD build logs; artifact hashes/versions; release notes	Deployed software maps to source/build
Third-party commitments	Contract clauses; security addendum; due diligence responses	Developer is required to follow CM
Exception handling	Waivers with approvals and compensating controls	Deviations are governed, not hidden

Operational note: Daydream is useful here as a system of record to map SA-10 to an owner, an implementation procedure, and recurring evidence artifacts so the evidence pack is consistent across systems and suppliers ¹.

Common exam/audit questions and hangups

Expect these, and prepare crisp answers with pointers to artifacts:

1. “Who is the developer for this system?” Auditors want named teams and named third parties, not “Engineering.”
2. “Show me your baseline.” Have a definition: tagged release, golden image, approved IaC templates.
3. “Walk me through one production change end-to-end.” Be ready with a specific release and full traceability.
4. “How do you prevent unauthorized changes?” Point to branch protections, access controls, and release permissions.
5. “How do you handle emergency changes?” Show an emergency path with after-the-fact review and documentation.
6. “How do you know production matches the baseline?” Show reconciliation, drift detection, and periodic checks.

Hangup: teams confuse “we have Git” with “we have configuration management.” Git without enforceable reviews, release traceability, and change approvals will not satisfy mature interpretations of SA-10.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating CM as code-only. Fix: include IaC, pipeline config, dependencies, and runtime configuration in your controlled items list.
• Mistake: no baseline definition. Fix: define what “approved baseline” means per system and how it’s recorded (release tag, signed artifact, approved template set).
• Mistake: approvals happen in chat. Fix: require approvals in systems of record (PR approvals, change tickets).
• Mistake: third-party CM not contractually required. Fix: add CM obligations and evidence rights in SOWs and renewals; document exceptions with risk acceptance.
• Mistake: evidence is scattered. Fix: establish one evidence index per system (links to repos, CI pipelines, ticket queues, and exported settings).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions.

Risk-wise, weak developer configuration management increases the likelihood of:

• unauthorized changes entering production,
• inability to prove what code/config is running,
• delayed incident response because you cannot reconstruct change history,
• supply chain exposure when third-party components change without traceability.

Auditors often treat these as systemic SDLC governance failures because SA-10 sits in acquisition and development controls ².

Practical 30/60/90-day execution plan

Use phases rather than time promises. Move faster if you already have mature SDLC tooling.

First phase (immediate)

• Assign SA-10 owner and evidence coordinator.
• Identify in-scope systems and the developers (internal and third party) who can change them.
• Draft a one-page Developer CM Standard: controlled items, baselines, change approvals, versioning, traceability, evidence retention.
• Create an evidence index template per system (where to pull repo settings, PR logs, build logs, change tickets).

Second phase (near-term)

• Add SDLC enforcement: protected branches, required reviewers, required ticket links, controlled release permissions.
• Update procurement/security addenda to require developer CM for third parties; add evidence-on-request language.
• Run one audit-style traceability test on a recent release; log gaps and remediation owners.

Third phase (operationalized)

• Automate evidence exports (repo settings snapshots, CI/CD logs, artifact metadata).
• Implement exception workflow for emergency changes and third-party constraints.
• Establish a recurring control operation rhythm: periodic sampling of releases and third-party checks.
• Track SA-10 status in Daydream (or your GRC tool) with mapped procedures and recurring artifacts so assessments do not restart from scratch ¹.

Frequently Asked Questions

Does SA-10 apply if we buy SaaS and don’t write code?

Yes if the SaaS provider is effectively the “developer of the system service” that you rely on for regulated processing. Operationalize it through contract requirements and due diligence evidence that their configuration management controls changes and supports traceability ².

Is “we use GitHub” enough to meet SA-10?

Usually no. You need enforceable controls (branch protections, approvals) and records that connect approved changes to builds and deployments, plus a baseline definition you can point to during an audit.

What counts as a “baseline” in a cloud-native environment?

A baseline can be a combination of tagged application releases, approved IaC templates, and versioned pipeline definitions. The key is that you can identify the approved set and show controlled changes from that point forward.

How do we handle emergency production fixes without failing SA-10?

Define an emergency change path that allows expedited deployment but still captures who approved the change and requires after-the-fact review with a linked ticket and PR record.

Our third party won’t share build logs or repo settings. What do we do?

Ask for alternative evidence (independent audit reports, redacted screenshots, or process attestations) and document the gap with a risk decision and compensating controls. Tie the requirement to renewals so you can improve evidence rights over time.

What evidence should we hand an auditor first?

Provide a single release trace: ticket/change request, PR with approvals, CI build record, artifact/version identifier, and deployment record showing what reached production. Then provide your CM standard and repo/pipeline control settings exports.

Footnotes

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

2. NIST SP 800-53 Rev. 5