SA-10(2): Alternative Configuration Management Processes

SA-10(2) requires you to define and run an alternate configuration management (CM) process, staffed by your own organizational personnel, when you do not have a dedicated developer CM team. Operationalize it by assigning CM roles, enforcing baseline/version control and change control for code and build artifacts, and retaining evidence that changes are reviewed, approved, and reproducible. ¹

Key takeaways:

• You need a documented “who does CM” plan for development work when no formal developer CM team exists. ¹
• Auditors look for traceability: baseline → change request → approval → build/release → ability to reproduce. ²
• Evidence matters as much as process design; missing artifacts is the most common failure mode for SA-10(2). ¹

SA-10(2): alternative configuration management processes requirement shows up when you build, customize, or maintain software but you do not have a formal developer configuration management team. That describes a lot of real environments: small internal development groups, platform teams that “own” scripts and infrastructure-as-code, and contractors running a mixed delivery model where engineering is distributed.

This control enhancement is not asking you to invent heavyweight CM. It is asking you to prevent the predictable failure modes that appear when “CM is everyone’s part-time job”: untracked changes, unclear approvals, inability to recreate a build, and production drift. The operational expectation is simple: assign organizational personnel to run CM duties, define the workflow, and prove it runs consistently. ¹

If you are a Compliance Officer, CCO, or GRC lead, your job is to translate this into a small set of enforceable requirements engineering can follow and you can audit. The rest of this page gives you the minimum viable process, the evidence to retain, and the common auditor hangups.

Regulatory text

Requirement (excerpt): “Provide an alternate configuration management process using organizational personnel in the absence of a dedicated developer configuration management team.” ¹

What the operator must do:

• Decide when SA-10(2) applies: you lack a dedicated developer CM team for the system/software in scope. ¹
• Stand up an alternate CM process: a defined, repeatable set of CM activities (baseline control, change control, versioning, and release/build traceability) performed by named organizational personnel. ¹
• Prove it works: retain artifacts that show the process is followed for real changes, not just described in a policy. ²

Plain-English interpretation

SA-10(2) is a backstop. If you do not have a formal CM team supporting developers, you still need CM outcomes:

• You can tell what version of code/config is running.
• You can show who approved changes and why.
• You can recreate or roll back releases.
• You can prevent “silent” production changes.

This is especially relevant where engineering is lean, responsibilities are shared, or third parties deliver code but you operate it. SA-10(2) focuses on organizational personnel stepping into the CM function. ¹

Who it applies to (entity and operational context)

Typical applicability scenarios:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data (including environments supporting federal programs) where NIST SP 800-53 is flowed down contractually or adopted as the control baseline. ²

Operational contexts where assessors commonly probe SA-10(2):

• Internal apps with no formal release engineering.
• DevOps teams managing infrastructure-as-code without CM separation of duties.
• SaaS configuration changes made directly in production by admins.
• “Shadow” scripts, automation, and pipelines that touch production.

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

Use this as a quick implementation runbook.

1) Declare scope and triggers

1. Identify systems/software/components where you develop or modify code, scripts, templates, or configuration items.
2. Document the trigger: “No dedicated developer configuration management team exists for this scope.” ¹
3. Define which artifacts are controlled items (minimum: source code, build scripts, deployment manifests, IaC, and production configuration parameters that affect security or availability).

Operator tip: auditors will accept a lightweight scope statement if it is consistent with your SDLC and asset inventory.

2) Assign the alternate CM roles (named people, not teams-in-the-abstract)

Document an alternate CM RACI that uses organizational personnel:

• CM Lead (owner): accountable for CM procedure, tool configuration, and audit response.
• Approvers: engineering lead and security representative (or delegated reviewer) for risk-impacting changes.
• Implementers: developers/admins who submit change requests and execute changes.
• Release/Build custodian: person responsible for tagging releases and preserving build outputs.

This is the core of SA-10(2): CM responsibilities still exist even if there is no formal CM team. ¹

3) Define the alternate CM workflow (minimum viable controls)

Write a short procedure (often 2–4 pages) that covers:

A. Baseline management

• Establish a baseline for each controlled item (repo default branch protection, “known-good” tag, or release branch).
• Define how baselines are updated (via approved change).

B. Version control

• Require all controlled items to be stored in an approved version control system.
• Prohibit direct edits to production-controlled items outside the workflow (define emergency path if needed).

C. Change control

• Require a change record for each change (ticket, pull request, or change request form).
• Require review and approval before merge/deploy, with criteria for what needs security review.

D. Build/release traceability

• Require each production deployment to map to a unique commit/tag and to a change record.
• Preserve release notes and deployment evidence.

E. Emergency changes

• Allow emergency changes, but require retrospective approval and documentation.

You are designing for auditable traceability and reproducibility, not bureaucracy. ²

4) Configure tools to enforce the workflow (where feasible)

You can satisfy SA-10(2) with process-only controls, but enforcement via tooling reduces drift:

• Branch protection (required reviewers, no force-push).
• Mandatory pull requests for changes.
• CI/CD pipeline logs retained and accessible.
• Change ticket integration (link PR ↔ ticket ↔ deployment).

If engineering resists “process,” anchor the ask in operational safety: fewer unknown changes, easier rollback, clearer accountability.

5) Implement recurring oversight and sampling

Define an oversight cadence that fits your environment:

• CM Lead samples changes and confirms evidence is complete.
• Review exceptions: emergency changes, out-of-band fixes, and direct production edits.

Your goal is to show the process runs continuously, not only during audits. ²

Required evidence and artifacts to retain

Retain evidence that proves both design and operation.

Control design artifacts (static)

• Alternate CM procedure covering baseline, versioning, change control, emergency changes.
• CM RACI with named roles and backups.
• Definition of controlled configuration items ¹.
• Tool configuration screenshots/exports (branch protections, reviewer rules) where applicable.

Operating evidence (dynamic, sample-based)

• Change records (tickets) with risk/impact notes.
• Pull requests/merge requests showing review and approval.
• Commit history and release tags for deployed versions.
• Build and deployment logs showing what was deployed and by whom.
• Emergency change log with retrospective approvals.

Evidence hygiene rule: store artifacts centrally (GRC repository, controlled folder, or evidence management system) with clear naming, retention, and access control.

Where Daydream fits: many teams fail SA-10(2) because evidence is scattered across ticketing, source control, and CI/CD. Daydream can map SA-10(2) to an owner, a procedure, and a recurring evidence set so you request the same artifacts every cycle and stay assessment-ready. ¹

Common exam/audit questions and hangups

Assessors often ask:

• “Who performs configuration management duties if there is no CM team?” ¹
• “Show me a recent production change from request through approval to deployment evidence.”
• “How do you prevent direct changes to production configuration items?”
• “Can you reproduce the deployed version from your source and build artifacts?”
• “What is your emergency change process and how do you ensure follow-up approval?”
• “How do you know all relevant configuration items are under control?”

Common hangups:

• You have a policy, but no “last three changes” evidence.
• Changes exist in chat messages, not in tracked records.
• IaC is treated as “ops scripts,” not as controlled configuration.
• Releases are not uniquely tied to commits/tags.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SA-10(2)	Fix
Assuming Git alone equals CM	Version control without approvals and traceability does not show controlled change	Add required reviews, link PRs to change records, retain deployment evidence
No named CM owner	Shared responsibility becomes nobody’s job	Assign a CM Lead and backup; document responsibilities 1
Emergency path becomes the normal path	Changes bypass review and records	Require retrospective approval and track emergency volume with management visibility
Config changes outside repos	Drift and “unknown state”	Treat critical configuration as controlled items; move to repo-backed config where possible
Evidence scattered across tools	You cannot assemble a narrative under audit	Define an evidence package and retention location; automate collection where you can

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SA-10(2), so this page does not cite enforcement outcomes.

Risk implications to brief leadership:

• Weak alternate CM increases the chance of unauthorized or unreviewed changes reaching production.
• Incident response and recovery slow down when you cannot confidently identify what changed.
• Assessments frequently downgrade controls where evidence of operation is missing, even if teams “usually follow” the process. ²

A practical 30/60/90-day execution plan

You asked for speed, but you also need defensible artifacts. Use this phased plan.

First 30 days (stabilize and document)

• Name the CM Lead and approvers for each in-scope system/repo. ¹
• Publish the alternate CM procedure (baseline, versioning, approvals, emergency changes). ¹
• Define controlled configuration items for the top systems in scope.
• Pick an evidence location and create an “SA-10(2) evidence package” folder structure.

Days 31–60 (enforce and generate evidence)

• Turn on branch protections and required reviews where feasible.
• Require every production change to map to a ticket + PR + deployment record.
• Start a lightweight monthly sampling by the CM Lead; log findings and remediation.

Days 61–90 (prove repeatability and close gaps)

• Run an internal mini-assessment: select recent changes and verify end-to-end traceability.
• Fix recurring exceptions (common ones: emergency changes, config edits outside repos).
• Formalize recurring evidence pulls in your GRC calendar (and automate collection if your tooling supports it).
• If you use Daydream, configure the SA-10(2) control record with owner, procedure link, and an evidence checklist so collection stays consistent across cycles. ¹

Frequently Asked Questions

Does SA-10(2) require a separate configuration management team?

No. It requires an alternate CM process using organizational personnel when a dedicated developer CM team does not exist. You still need defined roles, workflow, and evidence. ¹

What counts as “organizational personnel” if contractors write the code?

Your organization must still run the CM process (ownership, approvals, evidence retention), even if a third party produces code. Document who internally is accountable for baselines, approvals, and release traceability. ¹

Can we satisfy SA-10(2) with Jira + GitHub + CI/CD logs?

Yes, if they collectively prove baseline/version control, change approval, and deployment traceability for in-scope items. The key is consistent linking and retention so you can replay a change end-to-end under audit. ²

What evidence should we show an auditor first?

Show a recent production change: ticket/change record, PR with approvals, commit/tag, and deployment log confirming what shipped. Then show the written alternate CM procedure and role assignments. ²

How should we handle emergency changes without failing the control?

Allow emergency changes but require a documented record and retrospective approval within your defined process. Track exceptions and review them in oversight sampling so “emergency” does not become routine. ²

We have multiple repos and teams. Do we need one process or many?

Use one standard with room for team-specific implementation details (tooling, branching model). Auditors want consistency in outcomes: controlled items, approvals, and traceability across all in-scope work. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5