Can SRE work in an ITIL organisation?

Yes, when it is integrated with ITIL rather than positioned against it. SLOs strengthen service level management, error budgets inform change management, postmortems feed problem management, and automation reduces toil in operations. ITIL defines the processes; SRE supplies engineering practices and objective measures that make those processes faster and better targeted.

Does SRE replace the change advisory board?

No. It gives the board better evidence. Automated, tested, and reversible changes can become pre-approved standard changes, pipelines can attach evidence automatically, and error budgets give an objective signal for when to slow down. The board then focuses its attention on changes that are genuinely risky.

How do you apply SRE to vendor-managed systems?

Measure reliability from your side with synthetic checks and integration metrics, compare the results with contractual service levels, include the vendor system as a dependency in your SLOs, and write runbooks for vendor outages covering coordination, communication, workarounds, and impact recording. You own the user experience even when you do not own the system.

Where should an enterprise start with SRE?

Pick one important business service, define SLIs for its main user journeys from the user's side, and measure them for a few weeks. Use those numbers in its next service review and change assessments. A single visible success gives the practice credibility that a broad programme announcement never will.

SRE in the Enterprise: Making It Work Alongside ITIL, Change Boards, and Legacy

In an enterprise, SRE works by translating its practices into the organisation's existing controls rather than replacing them. Use SLOs to give change and problem management an objective basis, pair error budgets with the change advisory board instead of bypassing it, automate evidence for audits, and treat vendor-run and legacy systems as dependencies with measured reliability and explicit runbooks.

Why the textbook does not transfer directly

SRE was popularised by organisations that write most of their own software, run it on their own platforms, and can change processes centrally. A typical enterprise differs on every count: many systems are bought rather than built, some are operated by vendors or outsourcers, change is governed by an advisory board, processes follow ITIL, regulators expect specific controls, and a large share of the estate is legacy that nobody will rewrite.

Teams that try to import SRE unchanged tend to collide with those structures, lose, and conclude that SRE does not work here. Teams that translate it find that the underlying ideas, measure reliability from the user's view, budget for risk, remove toil, and learn from incidents, fit enterprise needs well.

SLOs as the common language

Enterprise processes often lack an objective signal for risk. Change boards judge changes by description and reputation. Problem management prioritises by who complains loudest. Service reviews report uptime percentages that do not reflect what users experienced.

Service level objectives fix that. Define SLIs for the business services that matter, such as order submission, claims processing, or trading access, measured from the user's side. Then use them everywhere: change risk assessment considers remaining error budget, problem management prioritises by SLO impact, and service reviews report budget consumption rather than component uptime.

Working with the change advisory board

Change boards exist because unmanaged change caused outages. They are slow because they assess each change manually. SRE does not remove the need for oversight; it provides evidence that lets oversight be proportionate.

Standard changes. Changes that are automated, tested, reversible, and have a track record can be pre-approved as standard changes, which ITIL already allows.
Automated evidence. Pipelines can attach test results, deployment plans, rollback steps, and blast radius to each change record automatically.
Error budget input. When a service's budget is healthy, low-risk changes proceed; when it is exhausted, the board has an objective reason to slow down.

The result is a board that spends its time on genuinely risky changes instead of reading templates.

Vendor-operated and outsourced systems

You cannot run a vendor's system, but you are still accountable to your users for it. Measure it from your side: synthetic checks, integration error rates, and latency as your services experience it. Compare those measurements with contractual service levels, which are usually defined differently and often more generously. Write runbooks for what your team does during a vendor outage, since the incident still needs coordination, communication, and impact tracking even when the fix is out of your hands.

Legacy estates

Legacy systems resist automation, but they respond well to observability and documentation. The order that works is: instrument what users experience, alert on symptoms rather than component states, write and test runbooks for the known failure modes, and only then automate the most frequent manual recovery steps. Toil reduction here is often less about code and more about removing the need for tribal knowledge at 3am.

Audit and compliance as automation targets

Regulated enterprises spend large amounts of engineering time producing evidence: who approved a change, what was tested, who accessed what, and whether controls ran. Much of that is toil in the SRE sense, manual, repetitive, and automatable.

Pipelines can record approvals, test results, and deployment details automatically. Access reviews can be generated from identity systems. Control checks can run continuously and report exceptions rather than being sampled once a year. Auditors generally prefer consistent, system-generated evidence to screenshots assembled before a review, and engineers get their time back.

Incidents, problems, and postmortems

ITIL separates incident management, restoring service, from problem management, finding and removing causes. SRE postmortems map naturally onto problem records. Use the postmortem as the problem investigation, track its actions as problem tasks with owners, and record contributing causes in structured form so trends are visible across the estate. The main change most enterprises need is cultural: blameless analysis, and actions that are actually completed rather than closed administratively.

Frequently asked questions

Can SRE work in an ITIL organisation?: Yes, when it is integrated with ITIL rather than positioned against it. SLOs strengthen service level management, error budgets inform change management, postmortems feed problem management, and automation reduces toil in operations. ITIL defines the processes; SRE supplies engineering practices and objective measures that make those processes faster and better targeted.
Does SRE replace the change advisory board?: No. It gives the board better evidence. Automated, tested, and reversible changes can become pre-approved standard changes, pipelines can attach evidence automatically, and error budgets give an objective signal for when to slow down. The board then focuses its attention on changes that are genuinely risky.
How do you apply SRE to vendor-managed systems?: Measure reliability from your side with synthetic checks and integration metrics, compare the results with contractual service levels, include the vendor system as a dependency in your SLOs, and write runbooks for vendor outages covering coordination, communication, workarounds, and impact recording. You own the user experience even when you do not own the system.
Where should an enterprise start with SRE?: Pick one important business service, define SLIs for its main user journeys from the user's side, and measure them for a few weeks. Use those numbers in its next service review and change assessments. A single visible success gives the practice credibility that a broad programme announcement never will.