Continuous delivery under SOC 2 scrutiny at a SaaS provider

ITIL 4 does not require a committee; authorization is a control, and controls can be automated. The audit finding is about evidence of independent scrutiny, not about the forum.

Practical design:

• Peer review enforced by the pipeline. A pull request approval from someone other than the author, recorded with identity and timestamp, becomes the authorization evidence. The pipeline refuses to build without it.
• Policy as code. Automated gates for dependency scanning, licence checks, migration review, and a mandatory second approver for defined high-risk paths (authentication, billing, data export).
• A service account for deployment, so no engineer holds production credentials and every deploy is attributable.
• Immutable artifacts built once and promoted by digest, with the release record generated by the pipeline rather than typed by a human.

The nine findings would be closed by the review gate; the four unlinked changes by automatic release-record generation keyed to the artifact digest. Both are more reliable than a quarterly board, because they cannot be skipped under time pressure - which is exactly when the manual control fails.

This is configuration drift caused by two paths to production. The fix is to remove the second path, not to add more checking at the end.

• One route to production. Hotfixes build from the currently deployed tag, pass the same pipeline (with an expedited, narrower test set), and are automatically forward-merged to the main branch. Automatic merge, not 'usually'.
• Build once, promote the same artifact. The June release should have been a descendant of the March hotfix by construction; if it had been, the revert was impossible.
• Drift detection. The pipeline compares what is running in production against the artifact registry and the main branch, and alerts on divergence daily. This would have caught the March hotfix within a day rather than at the June release.
• Reconcile now: re-apply and verify the data-export fix, then reconstruct the record for it, including the 11-day impact on 300 tenants, so the incident record and the release records agree.

The underlying lesson: a release record is only trustworthy if it is a by-product of how deployment actually happens.

Reject the diagnosis while acknowledging the finding. The auditor's issue is missing evidence of authorization and traceability - neither is caused by deploying frequently. A quarterly board would make the evidence worse, because 40 daily deployments would simply continue outside it.

Argue the trade-off explicitly: quarterly boards would delay fixes to customers by up to three months while adding no control that a pipeline gate cannot provide, and every change would still need to be individually reviewed at some point.

Offer a counter-proposal that keeps a genuine release management role:

• Deployment stays continuous and automated.
• Release authorization is retained where a coordinated, customer-visible or contractual decision is needed - major version launches, breaking API changes, pricing or data-model changes - using a named accountable owner rather than a board.
• High-risk change categories get an extra approver in the pipeline.
• Quarterly the release manager reviews change failure rate, rollback counts, drift alerts and audit samples with the compliance lead.

This gives the auditor a control narrative and the engineers their cadence. The compromise is in the mechanism, not in the level of assurance.