Contents
Once an organisation builds a delivery pipeline for database changes, the job feels done. Schema changes are versioned, the pipeline applies them, records are kept. Then an audit arrives and finds a change in production that the pipeline never saw. Nobody broke a rule. That change was never in the pipeline's scope to begin with.
The Pipeline Is Built, the Scope Is Not
A delivery pipeline governs one path very well: carrying a planned schema change from development into production. The problem is that this is not the only path. A large share of the work that touches a production database sits outside the pipeline by nature, and that share tends to hold the riskiest items.
A data correction is made at midnight. A user is granted temporary access. An index is rebuilt. A customer record is updated by hand. None of these enters a release package, none passes through the pipeline, and every one of them changes production.
The Eight Paths Into Production
To make scope discussable, the paths need names. The list below is complete in most organisations; if one of the eight sits outside the scope, governance is short by exactly that much.
| Path | Inside the pipeline | Why an audit asks about it |
|---|---|---|
| Planned schema change | Yes | Already recorded; this is where audits pass easily |
| Planned data change | Often no | Schema tools do not version data; UPDATE scripts travel by hand |
| Reading production data | No | Personal data leaves here; without a record it cannot be explained |
| Emergency intervention | No | The riskiest change passes with the least control |
| Manual work outside the pipeline | No | The main source of unrecorded change |
| Rollback | Partly | A rollback is a change too, and it usually runs without approval |
| Permission and role change | No | It moves an access boundary; the effect is lasting and silent |
| Maintenance work | No | Index, statistics and partition work also affect production |
A common mistake: letting the tool define the scope
Organisations rarely choose their scope deliberately; the scope becomes whatever their tool covers. A schema versioning tool is adopted and governance narrows to schema changes. An auditor, however, asks about production as a whole, not about the reach of a tool.
Why Partial Scope Counts as None
An organisation governing three of the eight paths does not hold thirty seven per cent of governance. Audit logic does not work that way.
An auditor tests not whether a control exists but whether it can be relied on. The statement that every change in production passes through approval collapses entirely the moment one exception is shown. The remaining controls working well does not rescue it, because the statement is simply no longer true.
In practice the organisation can produce most of the evidence but cannot show that the scope is complete. The auditor widens the sample, asks for more, and the process drags. The most common reason audits run long is not missing records but unclear scope.
Bringing the Paths Outside the Pipeline In
Pushing all eight paths through the pipeline is neither possible nor necessary. Trying to route a midnight fix through the pipeline while production is down only lengthens the outage. The goal is not to move the work into the pipeline but to bind it to the same decision and evidence model.
That has three conditions.
One: declaring the work must be easier than doing it. As long as recording a piece of out of pipeline work costs more than performing it, it will not be recorded. A declaration screen asking for three fields gets filled in; one asking for fifteen does not. This is a design question, not a discipline question.
Two: the emergency path should be shortened, not switched off. The number of steps drops but not to zero, the right to declare an emergency is tied to a specific role, and a post event review is produced. A rule that closes completely gets disabled entirely during an emergency and eventually becomes the normal path.
Three: a path left out of scope must be visible. Choosing not to govern a path is a legitimate decision; pretending to govern it is not. Which path sits outside the scope should be written down, and that decision should be a deliberate one.
Why reading data is on this list
Reading production data changes nothing in the database, so it never enters the scope of change management tools. Yet this is where personal data leaves the organisation. The sentence asking someone to run a query and send the result is recorded nowhere in most organisations, and it is the first thing a data protection audit asks about.
Measure Your Own Scope
This measurement needs no tool. Read the eight paths one by one and answer three questions for each:
- Does work travelling this path leave a record that it did?
- Can that record be verified independently of the person who did the work?
- Was leaving this path out of scope a deliberate decision, or was it never discussed?
Answering "never discussed" to the third question matters more than the first two. If no scope decision was made, there is no scope; what exists is whatever the tool happened to cover.
Frequently Asked Questions
Could we not just push everything through the pipeline?
For some paths yes, for all of them no. Routing a fix through the pipeline while production is down lengthens the outage. Permission changes and maintenance work do not fit the pipeline either. The realistic goal is not to widen the pipeline but to bind the work outside it to the same decision and evidence model.
Does this mean we do not trust the team?
No. A scope problem is a visibility problem, not a trust problem. The team may well be doing everything correctly; the issue is that this cannot be shown. What an audit accepts is not the team's good faith but a record that can be verified independently.
Do we have to bring all eight paths in at once?
No, and attempting it would be a mistake. For most organisations the right order is this: start with reading production data and emergency intervention, because both carry high risk and both are probably unrecorded today. Permission changes come next. Maintenance work can be left until last.
How do we explain a path we deliberately left out of scope?
A written scope decision with a stated reason is something an auditor accepts. What they do not accept is a path nobody noticed was outside the scope. In the first case the organisation took the risk knowingly; in the second it never saw the risk at all, which says something far worse about the control environment.
Measure your own scope
See how many of the eight paths sit inside one governance model, in five minutes.
Self Assessment →