Use this page for any production change in an environment under a compliance standard (SOC 2, PCI DSS, HIPAA, and similar), and for release tickets that go through a change board. The standard does not make change slow; it makes change provable.
What auditors want to see for every change
- A record: what changed, why, who requested it, who approved it.
- Separation of duties: the person who wrote it is not the only person who approved it.
- Testing evidence before production.
- A rollback plan.
- Who deployed it and when, from system logs, not memory.
Most of this already exists if work goes through MRs and pipelines. The change record just links to it.
Change types
| Type | Example | Approval |
|---|---|---|
| Standard | Pre-approved, repeatable, low risk: a routine release through the pipeline, a certificate renewal with a runbook | Pre-approved template, logged |
| Normal | Anything else in scope | Change board or named approvers before the window |
| Emergency | Fix for an active incident or critical vulnerability | Incident commander plus one approver now; full review afterwards |
Release change ticket template
Summary: Release <service> <version> to <env>
Change type: standard | normal | emergency
Scope: <components, accounts or environments>; in compliance scope: yes/no
Reason: <ticket links>
Testing: <pipeline link for lower env>, <smoke test result>
Window: <YYYY-MM-DD HH:MM> to <HH:MM> UTC
Deployer: <role> Approver(s): <roles>
Rollback: <one-click rollback job link, or steps>; expected time <N> min
Customer impact: none expected / <describe>
Verification: <what will be checked after deploy>
The flow
flowchart TD
A[MR merged, lower env verified] --> B[Change ticket created from template]
B --> C{Standard?}
C -- yes --> E[Deploy in window]
C -- no --> D[Change board or approvers approve]
D --> E
E --> F[Verify]
F --> G{OK?}
G -- yes --> H[Close ticket with pipeline link]
G -- no --> I[Rollback, record, incident if needed]
- Sandbox or staging release ticket first, production clone second. Do not reuse a ticket across environments; each deploy needs its own record.
- Deploy only in the approved window. Outside it, it is an emergency change.
- Close the ticket with the pipeline job link as evidence.
Keep the scope small
- Segment the regulated environment (separate accounts, networks) so fewer systems need this process.
- Keep regulated data out of logs, tickets, dashboards and prompts to AI tools.
- Shared tooling (CI runners, monitoring agents) that touches the scope is in scope.
What an agent may do here
- Draft change tickets from the MR and pipeline.
- Gather evidence (pipeline links, test results) read-only.
- Never approve, never deploy to production, never edit production data.
Pitfalls
- Approving your own change because the approver is on holiday. Name backups ahead of time.
- Configuration changes made in a console "because it is just a setting". It is a change.
- Emergency changes that never get the after-the-fact review.