Change management, in the pipeline.
CC8.1 is the SOC 2 criterion about change management: changes to infrastructure, data, and software should be authorized, designed, developed, tested, and approved before they go live. A lot of that lives in your pipeline and your branch protection, which means a pull request can quietly remove the very controls that govern how changes ship.
The shapes the same control failure takes.
CC8.1 weakens when a change loosens the process that is supposed to govern changes. The recurring shapes:
A required approval is removed
A required review or approval gate before a production deploy is dropped from the CI config or branch protection, so changes can ship without sign-off.
A migration skips review
A database migration or data change is wired to run on deploy with no separate review or approval of a change that alters production data.
Tests stop gating the merge
A required status check (the test suite, a security scan) is made non-blocking or removed, so unverified changes can merge.
A bypass path is added
An emergency or admin path is added that lets a change reach production outside the normal pipeline, with no equivalent controls on it.
The rollback is removed
A safe rollback or migration-down path is dropped, so a change can ship that cannot be cleanly reverted if it goes wrong.
A required deploy approval, removed.
A required manual approval before production deploys has been slowing releases, so a change drops the protection rule. Deploys get faster, and now any merge to main reaches production with no one signing off on the change.
jobs: deploy:- environment:- name: production # requires a reviewer approval steps:Removing the production environment's required approval means changes now reach production with no sign-off. CC8.1 expects changes to be authorized and approved before they go live. If approvals are too slow, narrow who or what needs them, or automate the checks, but keep an approval step rather than removing it.
Change management is sampled against real changes.
An auditor samples changes that went to production and looks for the evidence that each was reviewed, tested, and approved, often the pull request, its approvals, and the passing checks. A change that removed a required approval or made a test non-blocking is the gap behind that evidence, and it is visible in the diff to the pipeline or branch-protection config.
A review, not your release process.
heygrc flags changes that touch CC8.1 and cites the criterion so the fix happens in the pull request. It does not run your deploys or own your branch protection. It catches the moment a change loosens the process that governs changes, at the diff. heygrc is in early access.