ITSM and SRE Change Management

In this illustrative scenario, a payments team has everything the reliability literature asks for. Objectives on the user-visible failure rate, a budget that says how much failure is allowed this quarter, deploys that go out on merge, and a rollback that takes ninety seconds. It also has a change advisory board that meets on Tuesday afternoons.

On a Thursday the checkout error rate climbs. An engineer rolls back in ninety seconds, as designed. On Friday she files an emergency change ticket for the rollback, because the process requires a record of every production modification and there was no time to get one first. The board reviews it the following Tuesday and approves it, retrospectively, with a note about following the process.

The instruments produced the results their definitions called for. The board’s change success rate went up because a correctly executed rollback counts as a successful change. Reliability fell because users saw errors for eleven minutes. Those results describe different outcomes; neither establishes whether the engineer had authority to execute the rollback before the later review.

That disagreement is the subject here, and it is usually described wrongly — as process against no process, or governance against engineering. It is neither. Both traditions want fewer outages and both insist on records. What they differ on is narrower and more consequential: where the authority to change production sits, and what a completed record is evidence of.

Four records, four different questions

The part of IT service management worth learning precisely is not its ceremony. It is its object model. Service management separates work that engineers routinely blur together, and the separation is load-bearing: each record has a different clock, a different owner, and a different definition of done.

Record	The question it answers	Done when
Request	Someone needs something the organization already offers. What is it, who may have it, and how is it delivered?	The thing is delivered
Incident	A service is not behaving as promised. How do we restore it?	Service is restored — which is not when the cause is understood
Problem	What actual or potential causes could produce incidents, and how can their likelihood or impact be reduced?	Resolution is verified, or the remaining risk is explicitly accepted; workarounds and known errors have recorded owners and status
Change	Someone wants to modify production. Who authorized it, what was the risk, and what is the way back?	The modification is made and its outcome recorded

Incident response restores usable service; problem management investigates actual or potential causes and manages workarounds and known errors, as PeopleCert’s ITIL 4 overview explains. A first major incident can justify investigation, and a potential cause can be addressed before an incident occurs. Record user-impact start and recovery times separately from administrative ticket closure. Keeping root cause analysis and follow-up actions linked to the incident, with their own owners and status, allows restoration to finish while investigation continues. Accepting residual risk needs an authorized decision and review conditions, not merely a closed investigation ticket.

A service request asks for something the organization offers, such as an environment, dataset, permission, or credential. An incident reports a service interruption or degradation. They can share an intake channel while requiring different classification, routing, and measures. A hundred incident records do not establish a reliability level without a period, affected population, duration, and treatment of duplicate reports. A hundred identical requests may be usage receipts from a self-service path or work performed manually. Measure manual intervention, hands-on time, waiting, failures, and rework before treating the count as evidence of missing capability.

Both records also carry a commitment to somebody outside engineering, which is what the service level agreement layer is for. Response and fulfillment times belong to requests; availability and error rates belong to what the service promises. Confusing those produces an agreement that guarantees a fast reply to a ticket about an outage, which is a promise nobody wanted.

Where the conflict actually is

Now to the argument. It is worth being specific, because the version usually argued — careful people against fast people — explains nothing and resolves nothing.

The authority to change production. This is the real one, and it is worth naming the two positions precisely, because the framework is not one of them. The practice in dispute is the one many organizations actually run: approval located in a standing body outside the team making the change, on the reasoning that an independent check catches what the author missed and that no individual should control a change end to end. Reliability engineering locates it instead in review by people who can read the change, plus automation that refuses bad changes before a human sees them. As the next section shows, the published framework permits both — so where an organization ended up is a choice it made, not an obligation it inherited.

DORA’s change-approval guidance reports that heavyweight external approval was associated with worse delivery performance in its research, and that it found no evidence linking more formal external review to lower change fail rates. That supports reconsidering routine external gates; it does not establish that every independent review has zero safety value. Assess local reviews through the risks they identify, the delay they add, and subsequent outcomes. DORA also retains a strategic CAB role in coordination and business decisions that need higher-level risk acceptance.

DORA recommends review by peers who understand the change during development, supported by automation that identifies, prevents, or corrects faulty changes early in delivery. Note that this keeps both things the board existed for — a second pair of eyes, and a record — and moves them to where the change is made.

A change record describes one modification and its outcome. An error budget measures the permitted shortfall against a service objective over a defined window. Failed events, allowed failures, and remaining allowance are different quantities; calendar boundaries or events entering and leaving a rolling window change the calculation. Thursday’s rollback can therefore succeed while the service loses allowance through user-visible failures. Reporting both reveals different parts of the outcome, without treating either the change count or budget as an indefinitely accumulating score.

What the queue is for. The same split appears over requests. Where service management is run as the interface, the queue exists, it has a catalog, it has response targets, and handling it well is the job. Reliability practice reads a repeated request as a question about where the work is going — and asks whether recurring manual handling can be reduced safely at a justified lifecycle cost. Both views are coherent, and they lead to opposite investments, because one improves the queue and the other tries to empty it. Nothing in the framework requires the first: a catalog item fulfilled by automation, with the record still produced, satisfies both readings at once.

DORA warns against reflexively adding process whenever a problem occurs. A failed change produces a new approval step; the next failed change produces another. Nobody ever decides to build a slow organization.

The standard change is the bridge, under conditions

There is a construct in service management that already resolves most of this, and it is underused because it is treated as an administrative shortcut rather than as the design it is.

Apply the change models according to the assessed procedure, configured authority and product release. The vendor guides used here describe implementations or interpretations of ITIL practices rather than the full official practice guides.

Change enablement — the practice’s current name, and the same thing older documents call change management — recognizes different kinds of change with different authorization paths. The vendor’s account of the ITIL framing defines standard changes as low-risk, recurring work covered by a documented, pre-approved process. Normal changes are non-emergency work without that standing approval, so they need an applicable decision route. A high-risk normal change may need risk assessment and CAB approval; a low-risk one may use a faster designated-authority route or approved automated checks and peer review.

Read that last clause again. The framework itself already permits automated checks and peer review as an approval path. The argument was never framework against engineering; it was about which category a routine deploy belongs in. If shipping a reviewed, tested, automatically verified service version is a standard change, the board never sees it, the record still exists, and nothing has been smuggled past anyone.

That only holds under conditions, and skipping them is how standard change becomes a loophole:

• Assess and approve the procedure and its operating envelope. Define allowed inputs, environments, scale, prerequisites, and expected risk. Assign an owner and triggers for reassessment, suspension, and renewed approval when failures, dependencies, or the procedure change. Pre-approval avoids repeating the same assessment for each conforming instance; it is not permanent approval regardless of new evidence.
• Check that each instance stays within that envelope. Instances need not be identical: parameters and artifacts can vary within approved limits. A schema migration is outside the class if the assessment excluded it, but can be included in a specifically assessed migration procedure. Make departures detectable and route them to the appropriate authority.
• Capture evidence from the execution path where possible. Link the authorized procedure or instance approval, its time and scope, the actual artifact or commit, check results, execution outcome, and recovery plan. Protect retention and access and make missing records visible. A later manual record can document a valid earlier decision, but its creation time alone cannot prove that authorization preceded execution. Automation improves collection only when coverage and integrity are verified.

Emergency change stays as its own path, and it is worth being exact about what the category does, because it is routinely described as permission to act first and record later. It is not. Unexpected faults or threats can make a change urgent, so what the category provides is a faster authorization route — a named authority who can approve within minutes, a standing delegation for a defined set of actions, or an expedited review — rather than the removal of one. ServiceNow’s own emergency model illustrates the point: its state machine pairs an Authorize state with a flow requesting CAB approval, exactly as the normal model does. Acting before authorization is a separate exception that an organization can grant deliberately, with its own conditions and its own record, and collapsing it into the word emergency is how unauthorized change acquires a legitimate-looking label. So the question to settle in advance is who may authorize an emergency change and how fast they can be reached, not whether authorization applies. Where retrospective approval genuinely is permitted, name the actions it covers and the reason. And the measure of whether the path is healthy is not how often it is used — during an incident it should be used — but what the retrospective reviews produce. They can end in an approval every time and still be worth holding: what to look for is whether they change anything downstream — a rollback, a follow-up fix, a standing rule that makes the next such change ordinary. A stream that approves everything and changes nothing afterwards is the queue worth questioning.

DORA recommends improving lead time and change fail rate. Define the start and end events, eligible deployments, failure classification, and observation period before comparing results. Read them alongside approval waiting time, recovery time, and user impact: shorter commit-to-production time can conceal waiting before commit, and extra successful deployments can dilute a failure ratio without removing any failures. Approval counts and rates remain useful activity measures, but demand and pre-submission rework affect them. Evaluate what a review changed and whether an enforced check could provide the same protection at acceptable cost.

Reading the request queue as an instrument

The other half of the operating model is the work that is not incidents and not changes: the steady stream of asks. This is where the two traditions can be made to agree, because the disagreement dissolves once you stop treating the queue as output and start treating it as a reading.

Google’s SRE book describes Toil through recurring operational effort, repetition, automation potential, limited enduring value, and growth with the service. Administrative overhead is a different category. New decisions about genuine tradeoffs can be engineering work, but the book’s footnote explicitly warns that repeated human judgment can still be toil when poor design keeps generating the need. Ask whether the decision is new, whether the underlying need can be removed, and which parts can be automated safely. A fixed rule is a candidate for enforcement in software; risk, implementation cost, maintenance, and authority still determine whether to automate it.

The scaling clause is the one that turns a nuisance into a structural problem. Work that scales linearly with the service means the operations headcount is a function of growth, so success creates the staffing problem. Google SRE therefore sets a goal of spending less than half of each SRE’s time on operational toil, reserving the rest for engineering that reduces future toil or adds service capabilities. The number matters less than the mechanism — a budget for interrupt work forces the question of what would remove it, and without a stated ceiling that question is never urgent.

Group requests over a stated period by the work sought, then inspect fulfillment and outcomes. A cluster suggests questions to investigate; its shape alone does not establish the cause or the right investment.

What the cluster looks like	What it says	What removes it
Many identical asks, fulfilled the same way each time	Check whether records are automated receipts or require manual intervention	Where routine manual effort justifies the cost, add a supported automated path and preserve the record; otherwise assess the existing path
Many asks that each need a different answer	Separate new judgment from recurring diagnosis caused by avoidable complexity	Agree unresolved policy, then consider redesign, defaults, or automation for recurring work; preserve exception handling
Asks for permission to do something routine, decided by a rule you can state	Check whether the rule can be enforced within the approved authority and risk limits	Consider a policy check with an audit record; evaluate manual judgment and redesign separately rather than assuming either is always necessary
Asks that are really outage reports	The request and incident distinction has collapsed	Classify and route incidents separately, even through a shared intake; measure service impact separately from request demand

The SRE workbook describes several ways to reduce recurring remediation. A documented procedure can expose repeatable steps suitable for a script. Detection and execution may then be automated, or a design change may remove the underlying failure. Compare the remaining human effort, control requirements, maintenance cost, and risk of each option. A manually launched script can be a useful intermediate result; report what still needs a person rather than counting the whole task as eliminated.

This is the same argument as treating the platform as a product, which is what platform engineering asks for: the queue is the feedback channel, and each recurring item is a feature request written in the most expensive possible format.

What the tool is, and what it will not decide

In most enterprises this all runs in a platform, and in many of them that platform is ServiceNow. The product documentation describes change management across the change lifecycle to enable useful changes while limiting disruption, with support for ITIL standard, emergency, and normal changes. Product surfaces move between releases, so verify specifics against the current documentation; the shape below is what such platforms are for.

Service-management tooling can retain linked requests, incidents, problems, and changes, route work, expose catalog offerings, and collect an audit trail. Whether those records provide sufficient evidence depends on the required controls and their implementation: approval identity and scope, decision and execution times, artifact linkage, outcomes, collection gaps, access protection, and retention. Being queryable years later is useful, but does not by itself establish that a record is complete or that a change was authorized.

What it will not do is decide the authorization model. A platform will implement a Tuesday board or a pipeline-emitted standard change with equal willingness, and will report happily on whichever you choose. The question of who may change production is an organizational one — a decision rights question — and buying the platform tends to feel like answering it. It also will not reduce the queue. A faster form for requesting an environment is not a self-service environment, and the difference is whether a person is in the path.

A configuration management database records configuration items and their relationships to support change and incident decisions. Its usefulness depends on coverage, accuracy, and freshness. Pipelines and event handlers can register changes through APIs, but integrations must match identities, resolve conflicting sources, retry failed updates, and reconcile out-of-band changes. Expose source and observation times, verification status, and known gaps rather than treating a recent write as proof of completeness. Partial dependency evidence can still help if its limits are visible; treating it as a complete graph can conceal an affected consumer. A blast radius assessment should identify both the dependencies found and the uncertainty that requires further investigation.

A division of labor that survives both traditions

The arrangement that works is not a compromise in which each side gives up something. It is a split along the line of what each tradition is actually good at.

Agree locally who owns commitments, request definitions, accountable roles and the evidence needed to follow decisions. Service management can coordinate these responsibilities while engineering makes commitments measurable and implements reliable records; neither discipline needs exclusive ownership of the concerns.

Reliability engineering develops measurement and recovery mechanisms and explains feasible reliability levels, operating effort, and cost. An empowered business or product owner accepts the user-impact tradeoff with engineering input. Agree the operational-work limit, its owners, and what happens when it is exceeded rather than treating acceptable failure as a purely technical choice.

The seam between them is where the work is, and it comes down to a short list of decisions someone has to actually make.

• Separate the intake for requests and incidents, even if the same team handles both. The two counts answer different questions and a merged number answers neither.
• Define each standard-change class, approve its operating envelope, and check instance eligibility. Assign review triggers and authority to suspend or revise pre-approval when evidence changes.
• Capture authorization and execution evidence from the systems performing the work, with protected retention and visible collection failures. Distinguish a later record from evidence that approval existed before the change.
• Give interrupt work a stated ceiling, and review the request queue by cluster rather than by volume. Without a ceiling, absorbing the queue is always cheaper this week than removing it.
• Evaluate delivery time and failures alongside waiting, recovery, and user impact. Keep approval counts as activity measures rather than treating an increase as proof of a worse process.

Google’s SRE engagement model describes a Production Readiness Review as a way to identify a service’s reliability needs before responsibility transfers. It continues through improvements, training, onboarding, and ongoing work as the service changes. A recorded assessment is reusable evidence within its scope, not a one-time certification. New dependencies, incidents, workload changes, and releases can require renewed review. Both service management and engineering need a named authority for those decisions and a way to keep the evidence current.

Thursday’s rollback shows why records and authority must be designed together. The board sought a record of the production change, and the engineer sought to stop user harm. Their intentions and the later approval do not establish that authority existed before execution. Decide which reviewed, tested and reversible changes have standing authorization, which need an expedited decision, and which permit retrospective approval under explicit conditions. Capture that decision alongside the execution so the next responder can act without waiting for Tuesday or assuming permission.

References

• DORA, Capabilities: Streamlining change approval
• Google, Site Reliability Engineering, Eliminating Toil
• Google, The Site Reliability Workbook, Eliminating Toil
• Google, Site Reliability Engineering, The Evolving SRE Engagement Model
• Atlassian, IT Change Management: ITIL Framework and Best Practices
• ServiceNow Product Documentation, Change Management
• ServiceNow SDK, State Model Guide
• PeopleCert — ITIL 4 Practitioner: Problem Management
• DORA — Software delivery performance metrics