The 412-entry standard change catalogue
Skylark Logistics has run the same change model for four years. Its standard change catalogue holds 412 entries, added over time whenever a team wanted to avoid the weekly CAB. Last quarter, two severity-2 outages traced back to catalogue entries: an automated TLS certificate renewal that failed on an expired intermediate certificate, and a database parameter change applied to a cluster whose size had doubled since the entry was written. The change manager wants to withdraw the catalogue entirely and route everything through CAB. The DevOps lead points out that around 900 deployments a month flow through the pipeline and CAB currently clears about 80 items a week. An internal auditor has noted that standard changes leave no record at all, which the change manager says is acceptable because they are pre-authorized.
1. Assess the change manager's proposal to abolish the catalogue and send all 900 monthly deployments to CAB. What does the standard change type actually require, and where does the proposal fail?
Read the worked answer
The proposal is an over-correction that would make the risk position worse, not better.
What the standard change type requires: a standard change is a pre-authorized change - low risk, well understood, repeatable, with documented trigger conditions and a named owner. Pre-authorization is a delegation of authority made once, in advance. It is not an exemption from control, and it is only valid while the conditions that justified it still hold.
Where the proposal fails:
- Capacity. 900 deployments a month against a CAB clearing roughly 80 items a week is a fourfold overload. The predictable result is a queue, then late changes, then work performed outside the process. A backlog does not reduce risk; it relocates it to somewhere unmonitored.
- Misdiagnosed cause. Both failures were standard entries whose environment had drifted - certificate chain, cluster size. Risk was never a property of the change type; it is a property of this instance, in this environment, now.
- It does not fix the actual defect, which is that no one owned, reviewed or bounded those entries.
The proportionate response: keep the type, restore the conditions that make pre-authorization legitimate - an owner per entry, a review/expiry date, explicit boundary conditions ('valid for clusters up to N nodes'), automated detection when an execution falls outside the envelope (which forces reclassification to normal), and retained execution evidence.
2. You have six weeks and one analyst to triage all 412 entries. How do you decide what stays, what is retired and what is escalated to normal, and what evidence do you use?
Read the worked answer
Do not review alphabetically or by group opinion. Work from execution data, because that is the only evidence of what these entries actually are.
Pull 12 months of evidence from pipeline and automation logs: last execution date, frequency, failure and rollback rate, number of configuration items touched, and whether any touched CI is shared or customer-facing.
Retire by default (expect 150–250): entries with no execution in 12 months, entries with no identifiable owner, and duplicates. Retiring is cheap - a genuine need can be re-raised in a day, and if it recurs quickly you have learned something.
Escalate to normal: anything multi-CI, anything touching shared platforms, security or identity, anything with a failure or rollback rate above threshold, and anything whose parameters have clearly drifted from the environment it now runs in. That is likely a few dozen entries, and they are where the real risk was hiding.
Keep as standard, with conditions: high-frequency, single-CI, reversible, owner assigned, boundary conditions written, review date set.
The sequencing matters. Retire first so the analyst's time goes to the entries that can hurt you, and make 'no owner' an automatic retirement - unowned pre-authorization is the root cause here, not the catalogue itself.
3. The auditor wants every standard change recorded. The DevOps lead says that is bureaucracy that will slow delivery. Resolve the tension without simply siding with one of them.
Read the worked answer
The tension dissolves once you separate two different records.
Record of authorization - the decision to pre-authorize this class of change. That decision is made once, when the entry is approved, and it should carry owner, date, scope, boundary conditions and review date. That is the auditable judgement, and it is exactly what Skylark has lost.
Record of execution - evidence that each individual instance ran. This already exists in the automation and pipeline logs. The control is to retain it, tag it with the change identifier and make it retrievable - not to make a human open a ticket 900 times a month.
The auditor gets full traceability: who authorized this class of change, when, under what limits, and proof of every execution against those limits. DevOps gets no added manual step, because the evidence is a by-product of the work rather than an extra task.
The one new control worth adding is the exception path: if automation detects an execution outside the written boundary conditions, it flags it and the instance is treated as a normal change, reviewed retrospectively. That is the mechanism that would have caught the certificate and cluster cases before the outage did.