CM-2(6): Development and Test Environments

CM-2(6): development and test environments requirement means you must maintain a configuration baseline for dev/test that is separate from your production (operational) baseline, and manage it as its own controlled standard. To operationalize it, define distinct baselines, enforce environment scoping in your configuration management tooling, and retain evidence that changes to dev/test do not silently drift into production. ¹

Key takeaways:

• Keep dev/test baseline documentation and change control separate from production, even if you use the same platforms. ¹
• Prove separation with technical guardrails (accounts/projects/subscriptions, IaC repos, CI/CD protections) plus auditable records. ²
• Auditors will focus on drift, promotion paths, and whether “temporary” dev settings became de facto production standards. ¹

Most teams already “separate” dev/test from production in a logical sense, but CM-2(6) asks for something more specific: separate baseline configuration management. In practice, this is where programs fail. The organization can show a production hardened baseline, but dev/test inherits the same documents, the same exceptions, and the same change workflow without clear environment scoping. Then teams introduce permissive settings in dev/test to move faster, and those settings bleed into production through shared templates, shared images, or poorly governed CI/CD pipelines.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat dev/test as its own baseline product: define what “acceptable” looks like in dev/test, document the delta from production, and implement controls that keep dev/test changes from automatically altering production baselines. CM-2(6) is not a mandate to make dev/test as locked down as production; it is a mandate to manage dev/test deliberately and separately, with evidence. ¹

Regulatory text

Requirement (verbatim): “Maintain a baseline configuration for system development and test environments that is managed separately from the operational baseline configuration.” ¹

What the operator must do:

1. Define a dev/test baseline configuration (what settings, images, templates, services, and security controls constitute “standard” for dev/test).
2. Define an operational (production) baseline configuration separately.
3. Manage them separately: separate ownership, separate change approvals where appropriate, separate versioning, and technical segmentation so dev/test baseline artifacts cannot silently overwrite production baseline artifacts. ²

This is baseline management, not just “environment separation.” A dev environment can be on a different network and still fail CM-2(6) if it shares the same baseline artifacts and governance such that dev exceptions become production defaults.

Plain-English interpretation

CM-2(6): development and test environments requirement is asking you to prevent configuration management shortcuts in dev/test from becoming production risk. You do that by:

• Writing down a dev/test standard (baseline) that reflects reality.
• Writing down a production standard (baseline) that reflects your hardened posture.
• Making the two standards independent in documentation, tooling, and approvals. ¹

A common, acceptable pattern: dev/test baseline is “production baseline minus select controls,” with explicit, bounded differences (for example, relaxed logging retention or less restrictive inbound rules) that are approved as dev/test-only and technically blocked from promotion without review.

Who it applies to

Entities: Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 Rev. 5 controls. ²

Operational context (where this shows up):

• Cloud environments (separate accounts/subscriptions/projects for dev/test vs prod)
• CI/CD pipelines (build, test, deploy workflows)
• Infrastructure-as-Code (Terraform/CloudFormation/Bicep) repos and modules
• Golden images (AMIs, VM templates), container base images, Kubernetes manifests
• Shared platform services (logging, secrets, identity, endpoint management)

If you have any pathway where a “template” or “baseline” is reused across environments, CM-2(6) will be evaluated through that pathway.

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

Step 1: Set scope and name the baselines

• List your system dev/test environments (dev, QA, staging, pre-prod) and your operational environment (production).
• Create two baseline records:
  • Operational Baseline Configuration
  • Development and Test Baseline Configuration ¹

Operational tip: include environment identifiers used by engineering (account IDs, cluster names, subscription names). Auditors want to see unambiguous scoping.

Step 2: Document the dev/test baseline as its own controlled artifact

Your dev/test baseline should include, at minimum:

• Identity and access model (who can admin, who can deploy)
• Network segmentation expectations
• Approved base images / container base images
• Secrets handling expectations (even if relaxed vs prod, define it)
• Logging/monitoring baseline (what is required, what is optional)
• Patch/update posture (what you enforce automatically)
• Exception process for dev/test-only deviations ²

Keep it short, but specific. A baseline that reads like principles instead of settings will not test well.

Step 3: Define the delta from production (explicitly)

Create a “Baseline Delta” table. Example format:

Control area	Production baseline	Dev/test baseline	Rationale	Compensating guardrail
Admin access	Restricted group, MFA, break-glass	Wider admin group for engineering	Faster iteration	Time-bound access + audit logging
Data	Production data prohibited except approved subset	Synthetic data by default	Reduce confidentiality impact	DLP checks + approvals for any prod data copy

You are not claiming dev/test is “less secure”; you are proving you consciously manage differences.

Step 4: Implement technical separation so the baselines cannot overwrite each other

Pick controls appropriate to your stack, but implement at least one strong technical mechanism in each category:

A) Environment boundary

• Separate cloud accounts/subscriptions/projects for dev/test vs prod
• Separate Kubernetes clusters/namespaces with policy boundaries
• Separate VPCs/VNETs with routing controls

B) Baseline artifact boundary

• Separate IaC repositories or separate protected directories/branches for prod vs dev/test
• Separate image pipelines and image tags (prod-only promoted tags)
• Separate configuration management inventories (prod inventory cannot be targeted from dev pipeline)

C) Change promotion boundary

• CI/CD requires an approval gate to promote a baseline change into production
• Branch protections and code owners for production baseline artifacts
• Immutable versioning of baseline releases (tagged releases for prod) ²

Step 5: Align change control and ownership

• Assign a control owner (often Platform Engineering, IT Ops, or Security Engineering) accountable for both baselines, with explicit responsibility to maintain separation.
• Define change intake:
  • Dev/test baseline changes: normal engineering workflow, documented approvals
  • Production baseline changes: stricter approvals, security sign-off when security-relevant ¹

If the same people approve both, separation can still exist. What matters is separation in artifacts, versioning, and promotion gates.

Step 6: Validate with a repeatable check (drift + promotion)

You need a recurring way to answer:

• “What is the current dev/test baseline version?”
• “What is the current production baseline version?”
• “What differences are approved?”
• “Did any dev/test setting appear in production without an explicit promotion record?” ²

Practical options:

• Scheduled compliance-as-code checks against environment tags
• Config drift reports from your CM tool
• Repo comparison + release notes review as a control activity

Step 7: Operationalize evidence collection (so audits don’t become archaeology)

Set a cadence to export baseline versions, approval logs, and drift reports into your GRC repository. Daydream can help here by mapping CM-2(6) to a named owner, a written procedure, and a recurring evidence checklist so you do not rebuild the story each audit cycle. ¹

Required evidence and artifacts to retain

Retain evidence that proves two baselines exist and are managed separately:

1. Baseline documents (dev/test baseline and operational baseline) with version history. ¹
2. Baseline delta record showing approved differences and compensating controls.
3. System inventory / environment list tying baseline scope to concrete environment identifiers.
4. Change records:
   • Tickets/PRs for dev/test baseline updates
   • Tickets/PRs for production baseline updates
   • Approval evidence for production promotions
5. CI/CD policy evidence (screenshots or exports of branch protections, approval gates, code owners).
6. Drift detection outputs (reports, alerts, or periodic attestations) demonstrating you monitor divergence.
7. Access control evidence showing production baseline artifacts are protected (repo permissions, restricted groups).

Common exam/audit questions and hangups

Auditors and assessors typically press on these areas:

• “Show me both baselines.” If you only have one hardening standard and call it “all environments,” expect a finding. ¹
• “How do you prevent dev/test from changing production?” They will look for CI/CD gates and repo protections, not verbal assurances. ²
• “Are production templates/images ever built in dev tooling?” Shared pipelines can be acceptable, but you must show separation of artifacts and approvals.
• “Do you ever use production data in dev/test?” If yes, be ready to show additional safeguards and explicit authorization, even though CM-2(6) itself is about baselines.
• “What’s the last time the dev/test baseline changed, and who approved it?” This is an evidence maturity test.

Frequent implementation mistakes and how to avoid them

1. One baseline document with environment footnotes. Fix: create two controlled baseline artifacts and a delta table. ¹
2. Same IaC modules, same repo, no guardrails. Fix: protect production paths with code owners, separate directories, and promotion tagging.
3. Staging treated as production for releases but governed like dev. Fix: classify staging explicitly (dev/test) and define whether it mirrors production baseline or has a narrow delta.
4. Baseline exists, but no drift visibility. Fix: implement scheduled checks and retain outputs as evidence.
5. “Temporary” dev exceptions never expire. Fix: time-bound dev/test exceptions and review them as part of baseline maintenance.

Risk implications (why this control exists)

If dev/test baselines are not managed separately, you get predictable failure modes: overly permissive access, weakened logging, debug services exposed, and inconsistent patching. The operational risk is that these settings migrate into production through reuse of images, pipelines, or “known-good” templates that were never production-approved. CM-2(6) reduces that risk by forcing explicit governance boundaries. ¹

Practical execution plan (30/60/90)

Use qualitative phases to move fast without guessing timelines.

Immediate (start now)

• Identify all environments and label them dev/test vs operational.
• Assign a control owner and create two baseline placeholders with versioning.
• Lock down production baseline repositories/paths with restricted write access and required approvals. ²

Near-term (stabilize)

• Publish the dev/test baseline and the baseline delta table.
• Implement CI/CD promotion gates for production baseline changes.
• Turn on drift reporting or create a manual monthly attestation until tooling is in place.

Ongoing (operate)

• Review dev/test baseline deviations regularly and expire exceptions.
• Keep evidence collection on a calendar (baseline versions, PR approvals, drift outputs).
• Use Daydream to maintain the CM-2(6) control mapping (owner, procedure, recurring artifacts) so audits become a packet, not a scramble. ¹

Frequently Asked Questions

Does CM-2(6) require dev/test to be as secure as production?

No. It requires a dev/test baseline that is managed separately from the operational baseline, with controlled and documented differences. The key is governance and evidence of separation. ¹

Can we share the same IaC modules across dev/test and prod?

Yes, if you still maintain separate baselines through versioning, protected production release tags, and approval gates for production promotion. Assessors will look for controls that prevent dev/test defaults from becoming production defaults. ²

Is staging considered “development and test” under CM-2(6)?

Typically yes, unless your organization defines staging as part of operations for a specific system boundary. Decide and document it, then apply the correct baseline and change controls consistently. ²

What’s the minimum evidence an auditor will accept?

Two baseline documents with version history, an environment inventory mapping, and change records showing separate governance for dev/test vs production. Add repo/CI protection evidence to make the separation defensible. ¹

How do we prove the baselines are “managed separately” if the same team owns both?

Show separation in artifacts, approvals, and promotion paths: distinct baseline versions, restricted permissions on production baseline artifacts, and a traceable promotion process. Ownership can overlap; management controls must not. ¹

What if developers need elevated permissions in dev/test for troubleshooting?

Allow it within the dev/test baseline, but document the rule and add guardrails like time-bound access and audit logging. Then enforce stricter controls in the operational baseline with separate approvals. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5