Developer Configuration Management

FedRAMP Moderate’s developer configuration management requirement (NIST SP 800-53 Rev 5 SA-10) means you must contractually require system developers (including third-party developers) to run configuration management throughout build, integration, and implementation, and you must only deploy changes you approve. Operationally, you need a defined CM process, enforced change control, integrity checks, and evidence that ties every production change to approval.

Key takeaways:

• Put the requirement on developers in writing (contracts/SOWs) and verify it in practice, not by policy alone.
• Every change needs traceability: request → review → approval → tested build → controlled release → auditable record.
• Integrity controls matter: protect baselines, restrict who can change them, and prove what actually shipped.

“Developer configuration management” is easy to misunderstand as an internal IT change-management policy. SA-10 is narrower and sharper: it requires you to make the developer responsible for configuration management during development, integration, and implementation, and it requires your organization to only implement changes you have approved. The practical implication for a Compliance Officer or GRC lead is governance over the software supply chain and the path to production.

In FedRAMP programs, examiners and assessors will look for two things: (1) clear, enforceable requirements placed on the developer (including third-party developers, integrators, and component providers), and (2) a working mechanism that prevents unapproved changes from being introduced into the environment. If your teams can’t show traceability from a change request to an authorized release, you will struggle to defend SA-10.

This page gives requirement-level implementation guidance you can execute quickly: who is in scope, what to build, how to evidence it, and what auditors typically press on.

Regulatory text

Requirement (excerpt): “Require the developer of the system, system component, or system service to perform configuration management during system, component, or service development, integration, and implementation; document, manage, and control the integrity of changes; and implement only organization-approved changes to the system, component, or service.” ¹

Plain-English interpretation

You must:

1. Make developers follow configuration management (CM) practices while they build and integrate the system (not only after go-live).
2. Control and protect change integrity so changes can’t be silently altered, swapped, or introduced outside the process.
3. Deploy only changes your organization has approved, meaning there is a defined approver, criteria, and record for every production change.

This is a supply chain and release governance control. It applies whether development is done in-house, by a contractor, or by a product/service provider delivering system components.

Who it applies to

Entity scope

• Cloud Service Providers (CSPs) pursuing or maintaining FedRAMP Moderate authorization.
• Federal Agencies operating systems and procuring cloud services where the agency has responsibilities to ensure required controls are implemented and evidenced.

Operational scope (what systems and teams)

• System developers: internal engineering teams, DevOps/SRE teams when they produce infrastructure-as-code (IaC), and any build/release engineering function.
• Third parties involved in development or integration: software development contractors, system integrators, managed service providers making configuration changes, and component suppliers when they deliver deployable artifacts.
• Covered artifacts: application code, IaC templates, container images, machine images, deployment scripts, build pipelines, configuration parameters, and system components integrated into the authorized boundary.

If a third party can change what runs in your FedRAMP boundary, SA-10 should be reflected in their obligations and your validation of those obligations.

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

Use this as an implementation runbook for the developer configuration management requirement.

Step 1: Define what “configuration items” are for your system

Create a CM scope statement and list of configuration items (CIs). Include:

• Source code repos and branches that can release to production
• Build pipeline definitions
• Container/image registries and signing keys (if used)
• IaC repos and modules
• Environment configuration stores (parameters, secrets managers references, feature flags)
• Third-party components that are packaged into releases

Operator tip: Auditors care less about a perfect CMDB and more about whether you can name what must be controlled and prove it is controlled.

Step 2: Put CM obligations on the developer (contract/SOW + SDLC requirements)

For third-party development or integration, ensure your contracts/SOWs require:

• CM during development, integration, and implementation
• Documented change records
• Integrity protection of changes (controls against tampering)
• A rule that only organization-approved changes may be implemented into your environment

For internal development, implement the same requirements through SDLC and engineering standards, then enforce them through tooling.

Step 3: Establish baselines and a controlled change process

You need an explicit baseline concept:

• Baseline definition: what is “approved” for production (e.g., a tagged release, signed image digest, approved IaC commit SHA).
• Change initiation: ticket or change request with risk impact, affected CIs, and rollback notes.
• Review and approval: defined approvers (technical + security/compliance where appropriate) and approval criteria.
• Testing gates: evidence that the build was tested per your release criteria before promotion.

Keep the process tight: if developers can bypass approvals and still deploy, SA-10 is not met in practice.

Step 4: Enforce “only organization-approved changes” with technical controls

Policy is not enough. Put guardrails in the delivery path:

• Restrict who can merge to protected branches.
• Require peer review for changes to release branches and pipeline definitions.
• Limit production deploy permissions to a small set of roles and service accounts.
• Require that deployments reference an approved artifact identifier (release tag, commit hash, image digest).
• Prevent “hotfixes” directly in production; require the same CM workflow for emergency changes, with after-the-fact review and documentation.

Step 5: Document and protect change integrity

SA-10 calls out “control the integrity of changes.” Translate that into controls you can evidence:

• Immutable logs for build and release events (who, what, when).
• Controlled access to repositories and registries.
• Tamper-resistant records for approvals (ticketing system records, signed approvals, or equivalent).
• Clear linkage between the approved change request and what was deployed (artifact ID mapping).

Step 6: Validate third-party developer CM in due diligence and ongoing oversight

If a third party develops or integrates components:

• Ask for their CM procedure and sample change records.
• Verify they can produce traceability for a real change (not a template).
• Confirm their delivery method supports your approval requirement (you approve what gets deployed, not just what gets “handed over”).

If you use Daydream to manage third-party risk, map SA-10 obligations into your third-party due diligence checklist and track the required artifacts (e.g., CM plan, sample change tickets, repo controls evidence) alongside the engagement record.

Required evidence and artifacts to retain

Retain evidence that proves the requirement is operating, not just documented.

Core artifacts (minimum set)

• Developer CM requirements in contract/SOW, SDLC standard, or engineering policy mapped to SA-10 ¹
• Configuration item scope (CI list) and baseline definition
• Change control procedure with roles, approval steps, emergency change handling, and release gating
• Sample change records: tickets showing request, review, approval, testing/validation, and closure
• Release evidence: deployment logs or pipeline records that show the deployed artifact matches the approved artifact identifier
• Access control evidence for repo/branch protections and production deploy permissions (screenshots, exports, or system reports)

What makes evidence “audit-grade”

• It is time-bounded (shows operation over a period, not one-off examples).
• It is traceable end-to-end (ticket ↔ commit ↔ build ↔ release).
• It shows enforcement (failed deployments or blocked merges when approvals are missing are strong proof).

Common exam/audit questions and hangups

Expect variations of these:

1. “Show me how an unapproved change is prevented from reaching production.”
   Hangup: Teams provide a policy but cannot show enforcement controls in the pipeline or permissions model.

2. “Pick a recent release. Trace it from request to deployment.”
   Hangup: Ticket exists, but it doesn’t link to the exact commit hash/image digest that shipped.

3. “How do you handle emergency changes?”
   Hangup: “Break-glass” exists but leaves no record, or post-implementation approval is missing.

4. “How do you control changes made by third parties?”
   Hangup: Third-party changes are delivered as “black box” updates with no change records or integrity proof.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating SA-10 as generic ITIL change management.
  Fix: Scope it to developer-driven changes and the build-to-release path, including pipeline code and IaC.

• Mistake: Approvals exist, but deployment bypass is possible.
  Fix: Align permissions, branch protections, and release tooling so approvals are required for promotion.

• Mistake: Baselines are vague.
  Fix: Define baseline identifiers you can point to (release tag, commit SHA, image digest) and require them in change tickets.

• Mistake: Third-party development is out of scope “because they are a vendor.”
  Fix: Treat third parties as developers when they produce deployable changes. Put CM obligations in the agreement and verify artifacts.

• Mistake: Evidence is screenshots without traceability.
  Fix: Keep structured exports and a repeatable “release trace package” for sampled changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-10. Practically, SA-10 failures create predictable risk: unauthorized changes, tampering in the build/release chain, and inability to prove what code is running. In FedRAMP assessments, this tends to show up as control implementation gaps, weak evidence, or failure to demonstrate consistent operation.

Practical 30/60/90-day execution plan

Use this phased plan to operationalize SA-10 quickly without inventing unrealistic timelines.

First 30 days: Establish the requirement and scope

• Identify all developer channels that can modify production (internal teams and third parties).
• Define configuration items and baseline identifiers for production releases.
• Update templates: SOW/contract language, SDLC requirements, and change ticket fields to capture baseline identifiers and approvals.
• Run a tabletop walkthrough of one recent release and document where traceability breaks.

Next 60 days: Implement enforcement and evidence

• Turn on branch protection and peer review requirements for release paths.
• Tighten production deploy permissions and service account controls.
• Ensure build/release logs are retained and can be produced on request.
• Build a “release trace package” template: one folder or record that collects ticket, commit, build, test, approval, and deployment evidence for sampled releases.

By 90 days: Prove repeatability and bring third parties to parity

• Conduct an internal mini-audit: sample multiple changes across teams and verify end-to-end traceability.
• For third parties, collect CM procedures and sample change records; require remediation where traceability is missing.
• Formalize ongoing oversight: periodic sampling of changes and periodic access reviews for deploy permissions.
• If you manage multiple third parties, track SA-10 obligations and evidence requests centrally (Daydream can serve as the system of record for third-party due diligence artifacts and renewal tracking).

Frequently Asked Questions

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

It applies to the “developer of the system, system component, or system service” ¹. If your provider or a third party develops or changes components that run in your authorized boundary, you still need enforceable CM expectations and proof that only approved changes are implemented.

What counts as “organization-approved changes” in practice?

“Approved” should be a specific authorization event tied to a specific artifact identifier (release tag, commit hash, image digest) ¹. Approval can be routed through a change ticket, pull request approval, or a release gate, as long as it is attributable and auditable.

Do we need a formal Configuration Control Board (CCB)?

SA-10 requires documented control and integrity of changes, not a specific committee structure ¹. If your risk profile warrants it, a CCB can work, but many teams meet the requirement with defined approvers, change categories, and enforced release gates.

How do we handle emergency fixes without violating SA-10?

Allow emergency changes through a defined “expedited” path with strict logging, limited permissions, and documented post-implementation review. The key is that the organization still approves the change and can show what was deployed and why ¹.

What evidence is strongest for auditors?

End-to-end traceability for sampled releases: ticket approval, code change record, build record, and deployment record that all point to the same artifact identifier. Evidence that the system blocks unapproved merges or deployments is also persuasive ¹.

Our third party won’t share internal repo data. Can we still meet SA-10?

Often yes, but you must still require CM, obtain sufficient evidence (procedures, sample change records, release notes with artifact identifiers), and ensure your environment only accepts organization-approved changes ¹. If they cannot support traceability or integrity assurance, treat it as a material risk and negotiate access, attestations, or technical compensating controls.

Footnotes

1. NIST Special Publication 800-53 Revision 5