Configuration and Release Management (CM/RM) is the disciplined practice of identifying, controlling, versioning, and verifying every component that constitutes an information system — hardware, software, firmware, and documentation — and governing the authorized movement of those components from development through testing into production. Configuration management establishes and maintains a trusted baseline of what the system is. Release management governs when and how changes to that baseline are packaged, deployed, and validated. Together they answer two audit-critical questions: (1) Do we know exactly what is running in production? (2) Can we prove every change was authorized, tested, and traceable? CM/RM is NOT general project management, NOT a synonym for change management (though it depends on it), and NOT limited to software versioning — it encompasses infrastructure, data schemas, environment parameters, and all configuration items (CIs) that together determine system behavior.
Where it stops · what it isn't
- —IS: identification, control, status accounting, and auditing of configuration items (CIs); management of configuration baselines; authorization and scheduling of releases; rollback procedures; and audit evidence documentation
- —IS NOT testing methodology — System Readiness and Implementation Testing covers test design and execution; CM/RM governs whether the tested artifact is what actually gets deployed
- —IS NOT infrastructure provisioning — Infrastructure Deployment covers setup; CM/RM governs version integrity and traceability of what is deployed onto that infrastructure
- —IS NOT IT change management — change management defines the approval policy workflow; CM/RM is the technical and documentary backbone that ensures the right configuration item is what actually changes
- —IS NOT software development methodology — whether the team uses Agile, Waterfall, or DevOps, CM/RM applies to the artifact that methodology produces
- —Boundary case: In CI/CD pipelines, CM controls must be embedded in the pipeline itself (e.g., infrastructure-as-code versioning, automated baseline validation); the concepts are identical but the implementation mechanism differs from traditional manual CM
Connected concepts in the graph
Every cubelet sits in a knowledge graph. Here's what this one connects to.
PART OFInformation Systems Acquisition, Development, and Implementation (ISACA CISA Domain 3)
REQUIRESSystem Migration and Infrastructure DeploymentSystem Readiness and Implementation Testing
ENABLESIT General Controls (ITGC) — Program Change ControlsIncident Response and Recovery
RELATED TOControl Identification and Design
CONSTRAINSContinuous Integration / Continuous Deployment (CI/CD) Pipelines