Under active development Content is continuously updated and improved

KSI-CMT-RMVRedeploying vs Modifying

LOW
MODERATE

Formerly KSI-CMT-02

>Control Description

Execute changes to machine-based information resources through redeployment of version controlled immutable resources rather than direct modification wherever reasonable.
Defined terms:
Information Resource
Machine-Based (information resources)

>NIST 800-53 Controls

>Trust Center Components
4

Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.

From the field: Mature implementations express release management through pipeline observability — build success rates, security gate pass rates, and mean time from commit to production as dashboard metrics. CI/CD pipelines enforce security gates automatically, with deployment artifacts signed and provenance tracked via SLSA or equivalent frameworks.

Deployment Pipeline Architecture

Architecture & Diagrams

CI/CD pipeline expressing security gates, automated testing, and approval workflows at each stage

Automated: CI/CD platform APIs verify security gates are active and enforced

Release Pipeline Enforcement

Product Security Features

Automated enforcement of release gates — security scans, test suites, and approval requirements enforced before production deployment

Automated: Pipeline logs show gate enforcement and blocked deployments

Release Notes Archive

Documents & Reports

Release notes with security-relevant changes highlighted — generated from commit history and PR descriptions

Release Management Process

Policies

Human-readable release management procedures including approval gates, testing, and rollback procedures

>Programmatic Queries

Beta
CI/CD

CLI Commands

List recent deployments
gh api repos/{owner}/{repo}/deployments --jq '.[].{id: .id, env: .environment, ref: .ref, created: .created_at}' | head -10
Check deployment statuses
gh api repos/{owner}/{repo}/deployments/<deploy-id>/statuses --jq '.[].{state: .state, description: .description, created: .created_at}'

>20x Assessment Focus Areas

Aligned with FedRAMP 20x Phase Two assessment methodology

Completeness & Coverage:

  • What percentage of machine-based information resources are managed as immutable, version-controlled artifacts versus those still subject to direct modification?
  • For resources where direct modification is still used, how are those exceptions documented and what is the plan to transition them to immutable redeployment?
  • Does the immutable redeployment approach cover all layers — OS images, container images, serverless code packages, and infrastructure definitions?
  • How do you handle stateful resources (databases, persistent volumes) that cannot simply be redeployed — what controls apply to those modifications?

Automation & Validation:

  • What automated controls prevent or alert on direct SSH, RDP, or console modifications to resources that should only change via redeployment?
  • How do you detect IaC drift — differences between the version-controlled definition and the actual running state of a resource?
  • What happens if a redeployment pipeline fails mid-execution — do resources roll back to the previous known-good version automatically?
  • What automated tests validate that a redeployed resource matches the intended configuration before it receives production traffic?

Inventory & Integration:

  • What IaC tools (Terraform, Pulumi, CloudFormation, Helm) manage your infrastructure, and how do you track which resources are under IaC management versus manually provisioned?
  • How does your CI/CD pipeline enforce that changes go through version control and code review before redeployment?
  • What tools detect resources that exist in the environment but are not represented in any version-controlled definition?
  • How do you correlate redeployment events with change management records to confirm every change followed the redeployment path?

Continuous Evidence & Schedules:

  • How do you continuously demonstrate that the ratio of immutable redeployment to direct modification is improving over time?
  • What evidence shows that drift detection runs continuously and that detected drift is remediated within a defined timeframe?
  • Is deployment history (who deployed what version, when, from which commit) available via API or structured logs?
  • How do you prove that no direct modifications occurred on resources designated as immutable during the past assessment period?

Update History

2026-02-04Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

Ask AI

Configure your API key to use AI features.