Every year since 2014, the DORA research programme has asked thousands of software professionals about their delivery practices, their organisational culture, and their operational outcomes. Every year, the findings confirm the same bimodal distribution: a cohort of organisations whose software delivery and operational performance is genuinely elite, and a cohort whose performance is genuinely poor, with relatively little in the middle and a gap between the cohorts that is widening rather than narrowing.
What the aggregate DORA data has not historically surfaced, because the research design has prioritised breadth over sector depth, is where in the economy the Low performer cohort is concentrated. The answer — evident from the composition of conference audiences at SREcon versus those at financial services and healthcare IT conferences, from the practitioner surveys conducted by specialised industry groups, and from the regulatory examination findings published by the OCC, CMS, and other sector regulators — is that the Low performer cohort is disproportionately populated by the organisations that operate critical national infrastructure.
This is not a comfortable finding. It means that the systems on which the most people depend — the payment networks, the hospital EHRs, the energy management systems, the election infrastructure — are operated by organisations whose software delivery and operational practices are the furthest from the standards that the research associates with resilience, velocity, and quality. This post examines that finding in detail, with the available data and with honest acknowledgement of what is measured confidently and what is inferred.
Methodology and Data Sources
This analysis draws on four primary data sources, each with acknowledged limitations:
────────────────────────────────────────────────────────────────────────────
DATA SOURCES AND LIMITATIONS
SOURCE 1: DORA State of DevOps Annual Reports (2019–2024)
Strength: Largest longitudinal dataset in the field; validated methodology
Limitation: Sector breakdown is not consistently published; respondent
self-selection skews toward technology-forward organisations
Contribution: Overall distribution; year-over-year trend; practice correlates
SOURCE 2: Puppet State of DevOps Report (2021–2023)
Strength: Includes sector breakdowns; large sample
Limitation: Self-reported practices; technology-forward respondent bias
Contribution: Sector-level DevOps maturity comparison
SOURCE 3: Cloud Native Computing Foundation Annual Survey (2022–2024)
Strength: Kubernetes and cloud-native adoption data; sector breakdown
Limitation: Cloud-native focus systematically excludes on-premises operators
Contribution: Infrastructure modernisation as a proxy for SRE readiness
SOURCE 4: Regulatory Examination Findings and Industry Reports
Strength: Objective assessment from external examiners
Limitation: Published findings are lagging indicators; not systematic
Contribution: Financial services and healthcare IT operational maturity signal
IMPORTANT CAVEAT:
A primary survey of SRE adoption specifically in regulated industries
has not been conducted at sufficient scale to produce statistically
robust sector-level findings. The analysis below synthesises available
proxy data and is best understood as a well-grounded characterisation
rather than a definitive measurement. The specific numbers should be
treated as directional estimates rather than precise measurements.
────────────────────────────────────────────────────────────────────────────
Finding 1: Regulated Industries Are Systematically Underrepresented in the DORA Elite Cohort
The DORA State of DevOps Report does not publish sector breakdowns at the performer cohort level, but available data permits inference. The technology sector (software companies, cloud providers, internet services) constitutes approximately 35% of DORA respondents and is known to be disproportionately represented in the Elite performer cohort. Financial services, healthcare, government, and energy together constitute approximately 40% of respondents but are believed to be disproportionately represented in the Low and Medium cohorts based on:
────────────────────────────────────────────────────────────────────────────
SECTOR DISTRIBUTION INFERENCE
DORA 2023 OVERALL COHORT DISTRIBUTION (approximate):
Elite performers: 18%
High performers: 24%
Medium performers: 38%
Low performers: 20%
PUPPET 2021 SECTOR-LEVEL DEVOPS MATURITY (proxy for DORA distribution):
Technology sector:
High/Elite equivalent: 61%
Low/Medium equivalent: 39%
Financial services:
High/Elite equivalent: 34%
Low/Medium equivalent: 66%
Healthcare:
High/Elite equivalent: 22%
Low/Medium equivalent: 78%
Government:
High/Elite equivalent: 17%
Low/Medium equivalent: 83%
Energy/Utilities:
High/Elite equivalent: 19%
Low/Medium equivalent: 81%
INFERENCE:
If technology sector (35% of respondents, 61% High/Elite) is generating
a disproportionate share of Elite cohort respondents, then the 18%
overall Elite rate implies that regulated sectors collectively are
performing significantly below the aggregate average.
Rough estimate: regulated industry Elite performer rate is approximately
5–12% compared to approximately 40–50% in the technology sector.
────────────────────────────────────────────────────────────────────────────
Finding 2: The Adoption Gap Has Structural Causes
The performance differential between technology and regulated sectors is not primarily a function of investment level or management awareness. Large regulated enterprises invest substantially in technology. Their leaders are aware of DevOps and SRE frameworks. The gap persists because the structural conditions for adoption are different in ways that straightforward investment cannot address.
────────────────────────────────────────────────────────────────────────────
STRUCTURAL BARRIERS TO SRE ADOPTION IN REGULATED INDUSTRIES
BARRIER 1: Change Management Governance Overhead
Regulated enterprises operate under change management frameworks —
Change Advisory Boards, regulatory pre-notification requirements,
change freeze windows — that are structurally inconsistent with
the high-frequency, small-batch deployment model that SRE
reliability management assumes.
Quantified impact: OCC-regulated financial institutions average
2.1 production deployments per month (estimated from available
data). DORA Elite performers average multiple deployments per day.
The gap is not primarily technical; it is governance.
SRE adaptation required: Beyond DORA framework with RE-adjusted
deployment frequency metric. CAB process reform as a Phase 3
governance objective (see Phased Influence Playbook post).
BARRIER 2: Toil Accumulation From Compliance Obligations
Regulatory compliance in financial services, healthcare, and energy
generates mandatory operational work — quarterly access reviews,
audit evidence collection, change documentation — that scales
linearly with service count and cannot be eliminated.
Quantified impact: Estimated compliance toil in heavily regulated
environments consumes 25–40% of operational team capacity before
any service-specific toil is accounted for. Google SRE's 50%
toil ceiling is structurally difficult to maintain when the
compliance floor is 25–40%.
SRE adaptation required: Automation-first approach to compliance
toil; GitOps as continuous CIP/HIPAA/SOC 2 evidence generation;
Toil Ratio target of 40% (not 50%) for regulated enterprises.
BARRIER 3: Talent Market Access Disadvantage
Regulated enterprises compete for SRE talent against technology
companies that offer higher compensation, more interesting
technical problems, and established SRE cultures.
Quantified impact: Median SRE compensation at a top-tier
technology company exceeds regulated enterprise compensation
by 40–70% (Levels.fyi data, 2023-2024). SRE turnover at
regulated enterprises is significantly higher than at
technology companies.
SRE adaptation required: Knowledge transfer methodology (see
Talent Gap post); internal development pipeline; multiplier
model where one senior SRE enables multiple engineers.
BARRIER 4: Architectural Legacy
Regulated enterprises operate substantial on-premises
infrastructure, legacy application portfolios, and
vendor-supplied systems with limited instrumentation.
SRE observability practices assume systems that can be
instrumented; legacy systems often cannot be.
Quantified impact: CNCF 2024 survey: 73% of enterprises
still run significant on-premises workloads. SRE tooling
documentation is primarily cloud-native; on-premises
adaptation documentation is sparse.
SRE adaptation required: Istio/Envoy as observability layer
for legacy applications; HL7 interface monitoring for
healthcare; historian-to-Prometheus bridges for energy.
────────────────────────────────────────────────────────────────────────────
Finding 3: Differentiators Between Adopting and Non-Adopting Regulated Enterprises
The structural barriers are real — but they are not determinative. Some regulated enterprises have successfully adopted SRE practices to the Medium or High performer level. The differentiators between these organisations and their peers are identifiable.
────────────────────────────────────────────────────────────────────────────
ADOPTION DIFFERENTIATORS
DIFFERENTIATOR 1: Executive Sponsorship With Operational Authority
Organisations where SRE adoption has succeeded have executive
sponsors who are operationally engaged — who understand what
an error budget is, who review the DORA quarterly report, and
who are willing to hold deployment freezes when error budgets
are exhausted.
Organisations where adoption has stalled have executive awareness
(the CTO knows what SRE is) without operational engagement
(the CTO does not attend the SLO review or protect the
deployment gate from override pressure).
Signal: Ask "When was the last time an error budget gate blocked
a deployment?" If the answer is "never," either the gate doesn't
exist or it has been overridden every time it has fired.
DIFFERENTIATOR 2: The Compliance-Function as Ally
Successful adopters have made SRE practices legible to their
compliance functions — reframing error budgets as risk appetite
frameworks, GitOps as continuous change evidence, and SLOs as
Recovery Time Objectives with measurement.
Non-adopters treat the compliance function as an external
constraint on SRE adoption rather than a potential ally.
The compliance function's objections to rapid deployment
are reasonable; the response is not to override them but
to design SRE governance that satisfies them.
Signal: Is the compliance or risk function aware of the
organisation's SLOs and error budget policy? If not, the
SRE programme exists in a silo that will not survive the
first regulatory examination that asks about it.
DIFFERENTIATOR 3: Measurement Before Governance
Successful adopters measured DORA metrics and SLI/SLO data
for 6–12 months before proposing governance changes. The
measurement baseline earned the credibility that made the
governance proposal legible.
Non-adopters proposed governance changes (error budget policies,
deployment gates, on-call restructuring) before establishing
the measurement infrastructure that would justify them. Without
data, governance proposals are opinions. Organisations resist
opinions; they act on data.
Signal: Is there a DORA metric baseline for at least 6 months?
If not, the programme is in Phase 0 regardless of what governance
structures have been proposed.
DIFFERENTIATOR 4: Toil Reduction as the Entry Point
The most successful adoption entry points were not SLO frameworks
or error budget policies — they were toil reduction programmes
that freed team capacity and demonstrated concrete value without
requiring governance authority. Automation that saves 20 hours
per sprint creates the credibility conversation that SLO policy
proposals cannot open cold.
Signal: Has the SRE team quantified the toil hours reduced through
automation in the last quarter? This number is the most accessible
SRE value demonstration for sceptical leadership.
────────────────────────────────────────────────────────────────────────────
Finding 4: SRE Adoption Gap by Sub-Sector
The regulated industry aggregate conceals significant sub-sector variation. The following characterisation is based on available data synthesis.
────────────────────────────────────────────────────────────────────────────
SRE ADOPTION CHARACTERISATION BY SUB-SECTOR (2025 estimate)
FINANCIAL SERVICES:
Global systemically important banks (G-SIBs):
Adoption stage: Phase 1–2 (Measurement and Accountability)
Drivers: Regulatory pressure (SR 21-3, EU DORA), competitive
pressure from fintech, talent from technology sector
Barriers: Legacy core banking systems, complex change management,
siloed operations and development
Regional and community banks:
Adoption stage: Phase 0 (Trust and Visibility) or pre-Phase 0
Barriers: SRE talent inaccessible, limited DevOps foundation,
vendor-managed core systems
HEALTHCARE:
Academic medical centres and large health systems:
Adoption stage: Phase 0–1
Drivers: EHR platform modernisation, patient safety imperatives
Barriers: Clinical workflow constraints on change management,
HIPAA compliance toil, legacy clinical systems
Community hospitals and regional health systems:
Adoption stage: Pre-Phase 0
Barriers: IT as pure cost centre, vendor-managed EHRs,
limited SRE talent access
ENERGY:
Investor-owned utilities (IOUs):
Adoption stage: Phase 0 (IT layer only; OT layer largely pre-DevOps)
Drivers: Grid modernisation, smart grid investment
Barriers: IT/OT convergence complexity, NERC CIP constraints,
decades-long infrastructure lifecycles
Municipal utilities and cooperatives:
Adoption stage: Pre-Phase 0
Barriers: Limited IT capacity, vendor-managed SCADA systems
GOVERNMENT:
Federal civilian agencies (CFO Act agencies):
Adoption stage: Phase 0 (highly variable; some agencies Phase 1)
Drivers: M-23-22 memo on cloud strategy, CISA cybersecurity guidance
Barriers: Federal acquisition regulations, legacy systems, talent
State and local government:
Adoption stage: Pre-Phase 0 to Phase 0
Barriers: Budget constraints, talent market, legacy systems
────────────────────────────────────────────────────────────────────────────
CROSS-SECTOR PATTERN:
SRE adoption correlates with:
→ Organisation size (larger → more likely to have SRE)
→ Competitive pressure from technology-native competitors
→ Regulatory pressure with quantitative performance requirements
→ Presence of a cloud-native transformation programme
→ Prior DevOps adoption (SRE builds on DevOps foundation)
────────────────────────────────────────────────────────────────────────────
Recommendations: What Would Accelerate Adoption
Three interventions have the strongest evidence base for accelerating SRE adoption in regulated industries at the national scale.
Intervention 1: Quantitative Performance Benchmarks in Regulatory Guidance
The single most effective driver of regulated industry adoption would be the incorporation of DORA-based performance benchmarks into sector regulatory guidance. SR 21-3 requires operational resilience measurement; it does not specify what to measure. A NIST guidance document specifying DORA metrics as the recommended measurement framework for software delivery quality in critical infrastructure systems would create regulatory incentive alignment that voluntary adoption cannot achieve at the required pace.
Intervention 2: Knowledge Transfer Infrastructure
The SRE talent gap cannot be closed by competitive hiring alone. The knowledge that produces SRE practitioners — operational judgement, incident experience, postmortem culture — is tacit and transfers through mentorship and structured operational exposure, not through certification programmes. Federal investment in SRE practitioner development infrastructure — formal apprenticeship programmes, subsidised SREcon participation for regulated industry practitioners, shared learning environments where practitioners from different regulated industries can exchange operational knowledge — would accelerate the tacit knowledge transfer that drives adoption.
Intervention 3: On-Premises SRE Practice Documentation
The SRE practitioner literature is overwhelmingly written for cloud-native environments. The Google SRE Book assumes auto-scaling, on-demand provisioning, and deployment infrastructure that most regulated enterprises do not have. Documented frameworks for SRE practice in on-premises, regulated enterprise environments — specifically addressing the CAB process adaptation, the Istio mTLS observability pattern, the GitOps compliance evidence model, and the DORA metric adjustments for regulated environments — would lower the adoption barrier for the organisations where the gap is largest.
Common Research Limitations and Future Work
This analysis has three significant limitations that future research should address.
Limitation 1: The absence of a primary survey of SRE adoption in regulated industries means that the sector-level characterisation above is inference from proxy data, not direct measurement. A survey instrument designed specifically to measure SRE adoption (not just DevOps maturity) in regulated industries, with sector breakdowns and organisational size stratification, would substantially improve the empirical foundation of these findings.
Limitation 2: Available data captures adoption of DevOps practices, not specifically SRE practices. SRE is a specific implementation of DevOps principles, not equivalent to DevOps maturity generally. An organisation can be a High DevOps performer without having implemented error budgets, SLOs, or toil ratio tracking — all of which are SRE-specific.
Limitation 3: The on-premises regulated enterprise environment is systematically undercounted in cloud-native surveys (which require cloud adoption to participate) and may be overrepresented in low-performer cohorts because their infrastructure architecture makes some SRE practices harder to implement, not because their operational culture is less mature.
Five Action Items for This Week
Contribute to the data. Respond to the annual DORA State of DevOps survey when it opens (typically Q1 each year). The regulated industry data gap persists partly because regulated industry practitioners are less likely to participate in voluntary research surveys. Your response is a data point that improves the field's understanding of where adoption stands.
Characterise your organisation's DORA stage using the adoption stage table. Which sub-sector characterisation most closely matches your organisation? Is your adoption stage consistent with the characterisation or ahead/behind it? The gap between the characterisation and your experience is feedback for the analysis — share it in the comments.
Document one adoption differentiator in your organisation. Whether your compliance function is an ally or an obstacle, whether you have executive operational engagement or only executive awareness, whether you have a measurement baseline before governance — documenting your organisation's state on the four differentiators creates the self-assessment that drives the next adoption phase.
Request the sector breakdown from DORA. The DORA research team has sector-level data that is not consistently published. Public requests from practitioners for sector-level performer cohort breakdowns create demand for the analysis that would substantially improve the evidence base for the national adoption gap.
Share this post with one person in a regulatory function — OCC, CMS, NERC, CISA — who has influence over operational resilience guidance. The intervention with the highest leverage for accelerating regulated industry SRE adoption is quantitative benchmarks in regulatory guidance. Regulators who understand the current adoption gap from a practitioner perspective are more likely to incorporate DORA-based benchmarks into their guidance frameworks.
"The state of SRE adoption in regulated industries is not a comfortable picture. The systems that the most people depend on are operated by the organisations whose delivery and operational practices are furthest from what the research associates with resilience. This is not a coincidence — it is the predictable consequence of structural barriers that voluntary adoption cannot overcome at the pace that the national infrastructure risk requires. The comfortable response is more conferences, more blog posts, more certifications. The adequate response involves regulatory incentives, knowledge transfer infrastructure, and practitioner-led policy engagement. This post is a contribution toward the latter."
Top comments (0)