Change Management Control Gaps

What this finding is

Changes reach production without the controls the applicable framework requires — peer review, documented approval, separation between the identity that authors a change and the one that deploys it, testing evidence, or a rollback plan. Includes infrastructure changes made directly in a console, bypassing the pipeline entirely.

Why it is Tier 2

Change management is a core control area for SOC 2 and PCI DSS, tested by sampling production changes and requesting evidence for each. It is Tier 2 because the consequence is audit and reliability exposure rather than direct compromise, though undocumented direct-to-production changes are also the most common source of the misconfigurations that become Tier 1 findings.

How to detect it

1. 1Sample recent production changes and attempt to produce the required evidence for each — this replicates the assessor's test exactly.
2. 2Compare cloud control-plane logs against pipeline deployment records to find changes made outside the pipeline.
3. 3Check whether repository branch protection actually enforces review, or whether administrators can merge without it.
4. 4Confirm separation of duties between change authoring and production deployment.

How to remediate it

Steps are ordered. The first step is the one that reduces exposure fastest, which is not always the one that closes the finding.

1. 1Route all production change through the pipeline and remove standing console write access, replacing it with just-in-time elevation.
2. 2Enforce branch protection with required review, applied to administrators as well.
3. 3Capture approval, testing, and rollback evidence automatically as pipeline artefacts rather than as manual records.
4. 4Define an emergency change path with retrospective review, so urgent changes have a compliant route rather than an ad-hoc one.
5. 5Alert on control-plane changes originating outside the pipeline.

How to verify the fix

Mappings

Other Tier 2 findings in Processing Protection