Change management and release controls that keep working

Section 314.4(c)(7) of the Safeguards Rule is one clause long: adopt procedures for change management [1]. It is easy to skim past, and it means that how code reaches production is a control subject to regulation rather than a matter of team preference.

The good news is that a defensible change management procedure and a good engineering practice are nearly the same thing. The bad news is that the gap between the documented procedure and the actual one is usually wider than anybody realises.

What a defensible procedure contains

Four properties, and none of them require a change advisory board.

Every change is recorded. What changed, when it reached production, and which release it was part of. Version control gives you most of this for free, provided deployments are traceable to commits, which is worth verifying rather than assuming.

Every change is reviewed by someone other than the author. This is the most important requirement, and the one most often weakened.

Every change is tested before release. Not a manual check that it works, but the check suite running, including the compliance assertions from using evals as compliance evidence.

Emergency changes follow a defined path that still produces a record. Not the same path, necessarily. But a path.

The undocumented bypass

When we look at a team's change management, the documented process is almost always fine. Somebody wrote it, it says sensible things, and it would satisfy a reviewer reading it.

What we find in the deployment history is a second path. Two or three people can deploy directly. It gets used a handful of times a year, always for genuine reasons, usually at an urgent moment. Nothing records that it happened, because the record is produced by the normal pipeline and this route goes around it.

That path defeats the entire control, and it will not appear in any documentation because nobody thinks of it as part of the process. It is the thing you do when the process slows you down.

The fix is not to remove it. A system with no emergency path gets one anyway, improvised, at the worst possible moment. The fix is to make the emergency path produce a record: it can skip the review, skip the wait, skip the approval, and still write down that it was used, by whom, and when, with a required follow-up within a defined window. An emergency path that logs is a documented control. One that does not is a gap.

Review, when a model wrote the change

This is where regulated change management meets AI-assisted development, and it deserves a direct answer.

The requirement that a change be reviewed by someone other than the author exists because the person who made a set of decisions cannot see the decisions they did not know they were making. That reasoning does not weaken when the author is a model. If anything it strengthens, because a model produces plausible work at a volume that makes careless review much easier, and because the failure mode is specifically output that is almost right.

So a workflow where a model writes the change, the same run writes the tests, the pipeline passes, and it deploys is not reviewed work. It is unreviewed work with a passing result, and describing it as satisfying a change management control would be hard to defend.

What does satisfy it: the change is reviewed by a fresh context that did not produce it, evaluating the diff against the written criteria, and a person is accountable for the release. That is the argument in never let the model grade its own work, and in a regulated context it stops being a quality preference and becomes the thing the control requires.

The volume question is real and worth addressing rather than avoiding. When changes arrive far faster than before, review becomes the slowest step, and the honest options are to make review genuinely cheaper through automation, or to slow down. What is not an option is to keep the throughput and quietly redefine review as a quick look, which is the easiest option and the one most teams slowly move into.

Let the pipeline produce the record

The release record should be a byproduct of releasing, not a document somebody writes afterwards.

A record assembled by a person after the fact has the same weakness as any documentary evidence: it describes what they remember or intended. A record emitted by the pipeline describes what happened. It should capture the commit range, the check results, who approved, the deployment time, and whether the emergency path was used.

Retain those for the period your obligations run. This is another place where a default setting causes trouble: CI systems commonly discard build records after a few months, and the retention setting is one line of configuration that nobody has a reason to look at until an examiner asks about a release from eighteen months ago.

Separating duties without slowing down

Where separation of duties is required, the usual reading is that the person who writes a change should not be the person who approves its release to production. In a small team that is genuinely hard, and pretending otherwise is not useful.

Two things make it workable. First, separation applies to approval, not to work: the same engineer can write and deploy provided somebody else approved. Second, the approval can be asynchronous and lightweight for low-risk changes and reserved in its strict form for the paths that matter, provided the classification of which is which is written down rather than decided case by case.

That classification is worth doing carefully, because it is where a reviewer will ask hard questions. "Changes touching authentication, authorisation, retention, or customer records require approval by a second named person; other changes require peer review" is a defensible rule. "Important changes get extra review" is not, because nobody can audit it.

The check that keeps it accurate

Change management is a process control, so most of it cannot be asserted in code. Some of it can, and the parts that can are worth automating because process controls weaken without anyone noticing.

Assert that no deployment reached production without an associated approval record. Assert that the emergency path count for the period matches the number of emergency records filed. Assert that build and approval records exist for every release in the retention window, which catches the day the CI retention setting deleted them without notice.

Those three checks will not satisfy the requirement by themselves. They will tell you when the documented process and the real one no longer match, which is the thing nobody finds out until somebody asks.

If you want to know how wide that gap is in your team, get in touch.