---
title: Change control in regulated environments
slug: change-control-in-regulated-environments
summary: How to plan, approve, ship and evidence a production change inside a compliance scope, including release tickets, change windows and emergency changes.
order: 22
updated: 2026-11-11
status: ready
---

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

```text
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

```mermaid
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.