You auto-deploy straight to production on every merge. Where is your change management? My auditors will ask.?

The full executive answer

Our change management is automated and evidenced rather than meeting-based — which is exactly where ITIL 4 has moved: it replaced the old change-advisory-board bottleneck with 'change enablement', where standard changes flow through automated controls and every change is traceable. Here is our control chain, all of it inspectable in the repository: every change must pass a five-stage gate — lint, strict type-checking, an AI-behaviour regression gate, the full test suite of 3,577 tests across 344 suites, and a production build — before it reaches the main branch, and CI re-runs that gate on every push. Only green builds deploy.

Traceability, which is what your auditors actually need: every production change is a git commit with author and diff; the deploy pipeline is declarative in the repository; and application-level changes to customer-affecting configuration are written to an append-only, hash-chained audit log — append-only meaning entries can be added but never altered, hash-chained meaning each entry cryptographically seals the one before it, so tampering is detectable. Rollback is a redeploy of the previous immutable build on Vercel — minutes, not a war room.

The DORA research is unambiguous that this model — small, frequent, gated changes — produces lower change-failure rates than batched, board-approved releases. What we do not yet have, honestly: a formal segregation-of-duties story for a multi-engineer team, because today the team is small; as the engineering team grows, branch protection with mandatory second-person review is the roadmap control, and the pipeline is already built to enforce it.