The architecture isn’t the constraint. The operating model fell behind it.

This is a Day 2 story, and it’s the one most organizations underinvest in.

How Day 2 complexity outpaces Day 1 design

Day 1 covers everything that goes into standing up an Azure environment: subscription topology, security baselines, initial monitoring configuration and landing zone design. Day 1 gets EXECutive attention. It gets funded and celebrated.

Day 2 is what happens after the ribbon-cutting. Incident response at 2 a.m. An engineer spending 30 to 45 minutes triaging an alert that turns out to be noise. Runbooks that were accurate six months ago and have since drifted. The slow accumulation of operational complexity was never accounted for in the project plan, because the project plan ended at architecture sign-off.

Most organizations treat Day 2 as a staffing exercise. They hire more engineers, add monitoring tools and write more runbooks. That model works at a small scale. It stops working the moment the environment grows, because operational complexity does not grow linearly with the environment. It compounds.

How operational decay shows up

Operating model issues rarely arrive as a single failure. They arrive as patterns, and the patterns repeat across industries, team sizes, cloud maturity levels and operational tenure.

alert volume climbs while signal quality DROPs. Overlapping monitoring tools generate duplicate signals from the same underlying events. Engineers develop alert fatigue and start filtering aggressively, which means the incidents that need an immediate response get slower responses because they are buried in the noise.

Manual triage consumes the most experienced engineers. Each incident starts the same way: open a ticket, pull up logs, cross-reference metrics, check recent changes, build context from scratch. That sequence takes 30 to 45 minutes per incident, and it happens dozens of times a day. Senior engineers who should be advancing the platform are instead rebuilding the same context across the same incident classes, repeatedly.

Runbooks decay faster than anyone UPDATEs them. Documentation that was supposed to standardize response falls out of sync with the running configuration. Engineers work around the runbooks rather than follow them. Knowledge concentrates in individuals, and recovery outcomes become inconsistent the moment those individuals are unavailable.

Recovery timelines extend as the environment grows. More workloads, more integrations, more dependencies and more change velocity expand the surface area of every incident. A mean time to resolution that was acceptable at 50 workloads becomes a business risk at 500.

None of this is an Azure limitation. The platform provides the substrate. The gap is in how the environment gets operated at scale.

How AI changes what Day 2 can be

This is where AI enters the conversation, and it is worth being precise about what AI in operations actually means. Not AI as a marketing concept. AI as an operational capability embedded in how the team runs Azure every day.

When AI is integrated into the operating model, it changes the economics of Day 2. Rackspace operates Azure environments 24x7x365 and measures the difference daily.

alert correlation replaces manual triage. Telemetry is correlated across services, patterns are identified and the incidents that require human attention surface above the noise. Organizations running intelligence-driven operations report up to an 85% reduction in the alert volume engineers have to handle.

Predictive monitoring shifts response from reactive to anticipatory. Anomaly detection identifies degrading performance before it turns into a customer-impacting incident. The question moves from how fast the team can respond to how often the team can prevent.

Self-maintaining knowledge replaces decaying runbooks. When remediation actions are captured and fed back into the system, documentation evolves with the environment instead of falling behind it.

The point that matters most: AI does not fix a broken operating model. It amplifies whatever model is already in place. If operations are reactive and fragmented, AI makes the same chaos slightly faster. If the operating model is structured for intelligence, with correlated telemetry, standardized workflows and embedded automation, AI changes what Day 2 economics can look like at scale.

The operating model is the multiplier

Organizations that outperform their peers on Azure are not distinguished by architecture alone. They maintain controlled alert pipelines, predictable recovery cycles, deliberate balance between automation and human oversight, and a clear separation between the work humans should be doing and the work the platform should be handling. They treat Azure as an operating engine, not just infrastructure.

That posture follows a deliberate progression: assess the current operational baseline, standardize workflows across teams, secure the automation and AI guardrails, embed intelligence into daily operations and continuously optimize against measurable outcomes.

Rackspace works with organizations across the full progression: architecting Azure environments, assessing existing operating models, remediating gaps and managing Azure at scale.

For a detailed framework covering operational intelligence across six dimensions of Azure operations, download the e-book, Run Azure Intelligently.

Cloud adoption in healthcare has accelerated in recent years, driven by the need for flexibility, scalability and better access to data. Many organizations have made meaningful progress, yet operational and financial outcomes remain inconsistent. The gap reflects a set of structural barriers that shape how cloud performs in practice, not just differences in investment.

The 2026 Rackspace Healthcare Cloud Report identifies four constraints that consistently influence outcomes:

1. Legacy infrastructure
2. Cost complexity
3. Security and compliance requirements
4. Skills gaps

These barriers tend to show up early, often starting with the systems organizations rely on most.

Legacy infrastructure limits modernization

Legacy systems continue to shape cloud outcomes across healthcare. Many organizations still depend on technologies that were not designed for interoperability, scalability or current data demands.

The impact is widespread. Sixty-three percent of healthcare organizations report relying on legacy systems to a moderate or high degree, and 75% say these systems limit their ability to modernize IT environments.

These constraints affect core operations:

• Data integration and interoperability
• Electronic health record (EHR) performance
• Revenue cycle and billing systems

As a result, data remains fragmented, workflows slow and system performance becomes harder to optimize.

How leaders address infrastructure limits

Cloud leaders integrate modernization into their cloud strategy. In practice, this means they focus on:

• Refactoring or replacing legacy applications
• Introducing interoperable platforms
• Rationalizing data and application environments

These actions help reduce dependency on outdated systems. Only 10% of cloud leaders report that legacy infrastructure significantly limits modernization efforts, compared to 44% of less mature organizations.

Reducing technical debt supports faster data movement, more reliable system performance and improved operational efficiency.

Unpredictable costs limit cloud efficiency

Cloud introduces a different cost model that requires active management. While it can reduce capital expenditure and improve flexibility, it also creates variability that many organizations are not prepared to control.

The report shows a divided experience:

• 59% of organizations say cloud costs meet or fall below expectations
• 40% report higher-than-expected costs and lower-than-anticipated savings

These outcomes often depend on how environments are designed and managed. Organizations that move workloads without architectural changes carry inefficiencies forward, while limited governance increases cost variability.

How leaders address cost complexity

Cloud leaders apply structured financial management practices that support ongoing optimization. Key practices include:

• Monitoring usage and costs continuously
• Aligning workloads to the most efficient environments
• Using hybrid models to balance performance and spend

They also evaluate cost alongside performance. Improvements in system efficiency and reductions in operational overhead contribute directly to overall value.

Security and compliance shape architecture decisions

Security and compliance requirements play a central role in healthcare cloud strategy. The sensitivity of patient data and regulatory expectations require consistent control across environments.

More than half of healthcare organizations cite data security and compliance as primary drivers of workload movement between environments.

This often results in fragmented architectures, increased operational overhead and slower progress toward optimization.

How leaders address security and compliance requirements

Cloud leaders incorporate security into how environments are designed and operated. They:

• Build secure and compliant architectures from the outset
• Apply governance frameworks that support consistency
• Use advanced controls and monitoring to manage risk

This integrated approach allows organizations to maintain control while improving performance and operational efficiency.

Skills gaps slow execution

Cloud and AI initiatives depend on the ability to design, operate and optimize complex environments. In healthcare, limited access to specialized expertise continues to constrain progress.

The report highlights:

• 29% of organizations cite lack of in-house expertise as their biggest challenge in modernizing EHR environments
• 34% identify limited internal knowledge as a primary barrier to AI adoption

These gaps increase operational complexity and extend implementation timelines.

How leaders address skills gaps

Cloud leaders build capability through a combination of internal development and external support, such as:

• Investing in targeted hiring and upskilling
• Working with experienced providers
• Using managed services to extend internal teams

This model supports more consistent execution, reduces risk and accelerates time to value.

From constraints to operational efficiency

Each of these barriers introduces friction. Together, they shape how effectively cloud environments support the organization.

Cloud leaders take a coordinated approach. This includes:

• Addressing constraints as part of a unified strategy
• Aligning cloud initiatives with business priorities
• Investing in modernization, governance and skills development in parallel

This allows them to move from reactive issue management to continuous optimization.

The path forward

For healthcare and IT leaders, improving cloud outcomes requires addressing the conditions that limit efficiency.

Key priorities include:

• Reducing reliance on legacy systems
• Applying financial discipline to cloud operations
• Embedding security into architecture and governance
• Building or accessing the expertise needed to sustain progress

Organizations that take this approach position themselves to translate cloud adoption into measurable operational advantage.

In a sector where efficiency affects patient care, cost management and workforce sustainability, these changes have direct impact across the organization.

Take the next step

Read more in the 2026 Research Report: From Cloud Adoption to Cloud Advantage in Healthcare →

That idea is straightforward. In practice, it is where many threat intelligence programs stall.

The challenge is not access to data. It is the ability to turn that data into insight that consistently guides action across a complex and evolving threat landscape.

For many organizations, threat intelligence remains focused on the tactical layer. Teams enrich indicators of compromise, add context to alerts and support active investigations. These capabilities strengthen response once activity has already surfaced.

Greater value emerges earlier, when intelligence informs decisions before alerts escalate.

Reaching that level requires more than adding new data sources. It depends on analysis that connects disparate signals into a coherent view of adversary behavior, mapped to an organization’s specific exposure. It requires deep understanding of attacker tradecraft, built through focused specialization over time. It also requires continuous tuning as threats evolve, so intelligence stays relevant and actionable.

Building and maintaining this level of capability is resource intensive. Organizations that achieve it have typically invested years into dedicated intelligence functions, with specialists advancing the program over time. Sustaining that depth becomes difficult as security teams balance broader operational demands.

As a result, many programs continue to generate output, but struggle to advance. Analytical depth falls behind the increasing complexity of the threat environment, limiting the program’s ability to influence meaningful decisions.

Bridging that gap requires a more integrated approach to threat intelligence — one that connects analysis directly to how security teams operate day to day.

That is the standard the Rackspace Cyber Defense Center brings to customers, and it is why Rackspace partnered with CloudSEK.

CloudSEK’s platform addresses this challenge by correlating adversary behavior, active campaign activity and emerging threat patterns against an organization’s specific exposure profile before intelligence is surfaced. The result is focused, enriched intelligence aligned to operational priorities.

This approach shortens the path from intelligence to action and strengthens how insights translate into decisions across the security program.

Anticipating threats before they materialize

As Rahul Sasi, Co-Founder and CEO of CloudSEK, explains:

“Enterprises today are no longer defending against isolated threats, but against evolving attack paths. As cyberthreats become more AI-driven, security must shift from reactive detection to predictive resilience. Our partnership with Rackspace brings together deep cloud expertise and predictive cyber intelligence to help organizations anticipate, disrupt and stay ahead of threats before they materialize.”

For Rackspace Cyber Defense Center customers, the impact is clear. Threat intelligence becomes embedded within the security program rather than operating as a separate input. Intelligence integrates into detection, triage and response workflows, informing prioritization earlier in the decision process.

Threat intelligence delivers the most value when it is specific, timely and directly connected to the next action. Achieving that standard depends on the depth of analysis behind the intelligence, and that depth requires more than tooling alone.

The partnership with CloudSEK enables Rackspace to deliver that level of intelligence in practice.

Advance your security operations with contextual threat intelligence.

Learn more about Rackspace SOC services here.

A central theme throughout the discussions was the growing urgency of having a clear, tested and controllable recovery plan you can rely on under pressure.

“Attackers are becoming much more sophisticated,” said Simon Bennett, CTO EMEA for Rackspace Technology, in his keynote presentation. “We’re now dealing with state-sponsored actors.”

In many cases, attackers no longer act quickly and noisily. Instead, they remain undetected for months, learning systems, mapping dependencies and identifying how to maximize disruption. This can include compromising identity systems, infrastructure access and even physical controls.

Crucially, recovery itself is now a target. “Cyberattacks are increasingly targeting recovery platforms and backups for infiltration, deletion or corruption,” Bennett added.

“You might find your only good backup is six months old,” said Bennett. “The regulator will have a field day with that, and your customers will leave you in droves. It’s essential to know that what you’re backing up is safe, secure and not compromised,” Bennett said.

This has shifted the conversation from simply having backups to trusting them and knowing exactly when data was last clean.

AI challenges defence and recovery models

During a roundtable, leaders from central government, legal, healthcare, retail and infrastructure shared how they are navigating this evolving landscape.

The conversation reflected several realities:

• AI-driven and increasingly autonomous attacks are accelerating beyond traditional defence and response models
• Recovery has become a governance, control and accountability issue, not just an operational capability
• Recovery paths are now a primary target, requiring new thinking from CIOs and CISOs

While many organisations regularly test critical services and embed security by design, confidence in recovery remains uneven. As one participant noted, “There are always unknown unknowns,” reflecting a shared concern across the group.

Leaders agreed that a defined and achievable recovery plan is now essential, but more importantly, it must be operationally proven to hold up under real-world conditions.

One leader described building a seven-day recovery plan, while another focused on rapid response to reduce the public impact of an attack. Many highlighted the importance of clearly defining MVO and continuity strategies but acknowledged that confidence in execution under pressure remains a challenge.

Control, visibility and trust in recovery

A recurring concern was control over where and how recovery takes place.

Leaders emphasized the importance of understanding:

• Where data will be restored
• Who has access during recovery
• Whether the recovery environment is isolated and protected
• How quickly decisions can be made under pressure

Equally critical is data integrity and timing.

Rob Egley, Regional Vice President Sales for Rubrik, said a significant challenge is knowing the point in time to recover to once data has been compromised or deleted. “The implications for revenues and services are massive.”

This reinforces the need to move beyond having backups to trusting their integrity and provenance.

What to consider when working with recovery partners

Given the complexity of modern environments, most organizations rely on a combination of cloud providers, software vendors and service partners to support recovery.

Leaders discussed several practical considerations:

• How clearly providers explain recovery processes and limitations
• How quickly they respond to security or risk-related questions
• Whether recovery environments are sufficiently isolated from production risks
• How often are recovery capabilities tested in realistic scenarios
• How responsibilities are shared and understood during a live incident

Rick Martire, General Manager, Sovereign Services at Rackspace UK, observed: “When you give your SLA to your SaaS provider, you’re trusting they will have done their part. But that’s not always the case.”

Rather than assuming coverage, organizations are increasingly validating these assumptions as part of resilience planning.

From backup to business confidence

The overarching takeaway from ThreatScape Manchester was clear: recovery is central to cyber resilience.

The discussion also explored how sovereign and isolated cloud models can support recovery strategies, particularly for regulated industries. Rackspace shared details of its UK Sovereign Cyber Recovery Cloud, designed to help organizations recover critical systems rapidly following a cyberattack. The approach combines isolated UK-based infrastructure with always-on security operations, helping you restore services in a controlled and trusted environment.

Martire pointed to real-world resilience as a key differentiator. “When Cloudflare and AWS had outages in November 2025, our sovereign cloud was not affected at all,” he said. “We’ve got many NHS, Local Government and manufacturing clients in sovereign cloud today. All of those were unaffected. We do simulations of undersea cables being cut to make sure it can stand alone.”

Organizations are asking more focused questions:

• Can we trust our backups?
• Do we know when they were last safe?
• Can we recover quickly, with control, and to the right environment?
• Have we proven this under real conditions?

The discussions at ThreatScape Manchester reinforced a clear shift: Recovery is now the core measure of resilience. Plans must be clearly defined, rigorously tested and proven under pressure to be effective. Resilience is determined by how quickly, completely and with how much control systems can be restored after disruption. Rackspace Technology works with organizations across the UK to design, test and operationalize recovery capabilities that meet those outcomes.

Strengthen your recovery strategy with sovereign control and rapid recovery timelines. Learn how Rackspace and Rubrik are helping UK organizations recover within hours in a secure, isolated environment.

Learn more →

Healthcare organizations have moved decisively into the cloud era, yet outcomes remain uneven. Adoption is widespread, but only a small segment of organizations translate cloud investments into measurable operational efficiency. According to the Rackspace 2026 Healthcare Cloud Report, just 15% of healthcare organizations qualify as “Cloud Leaders,” meaning cloud adoption is fully integrated into business strategy and aligned with organizational objectives.

This distinction is significant in that it reflects a shift from cloud as infrastructure to cloud as an operational and strategic enabler. The gap between adoption and advantage is where efficiency is either created or lost.

Cloud adoption and cloud value are not the same

Most healthcare organizations have made meaningful progress in cloud adoption. Many cite improved reliability, flexibility and security as primary drivers. Adoption alone, however, does not deliver efficiency. The report highlights a mixed financial reality: 59% of organizations say cloud costs meet or fall below expectations, while 40% report higher-than-expected costs.

This divergence reflects execution maturity. Organizations that treat cloud as a lift-and-shift exercise often carry forward inefficiencies from legacy environments. Without architectural redesign, governance and ongoing optimization, cloud environments can introduce new layers of complexity.

Cloud Leaders take a different approach to cloud operations and optimization. They operate cloud as a continuous optimization model. Teams align workloads to the most appropriate environments, monitor consumption and refine architectures over time. The outcome extends beyond cost control to improved operational performance.

Performance optimization as a core efficiency lever

Operational efficiency in healthcare is closely tied to system performance. Latency, availability and responsiveness shape clinical workflows and influence patient outcomes. Cloud Leaders treat performance as a strategic priority.

The data reinforces this pattern. Seventy-six percent of Cloud Leaders cite optimizing performance and minimizing latency as a primary driver for cloud adoption, compared to 32% of other organizations.

This focus supports tangible operational improvements:

• Faster access to patient data
• Fewer delays in clinical decision-making
• Improved user experience for clinicians and staff

Organizations with less-mature cloud strategies often contend with fragmented environments that introduce latency and inefficiencies.

Modern architecture enables scalable efficiency

Architecture remains one of the clearest differentiators between Cloud Leaders and their peers. Leaders design cloud environments intentionally to support scalability, resilience and efficiency.

Hybrid cloud has emerged as a dominant model in healthcare, offering flexibility to balance performance, cost and compliance requirements. The report shows hybrid cloud accounts for 19% of workloads overall, rising to 31% among Cloud Leaders, compared to 17% for less-mature organizations.

This reflects a more mature operating model. Cloud Leaders:

• Place workloads based on sensitivity and performance needs
• Integrate public and private environments with consistency
• Reduce dependence on any single platform

The result is an adaptable infrastructure that supports both operational demands and innovation.

Eliminating legacy constraints unlocks efficiency

Legacy infrastructure continues to limit operational efficiency across healthcare. These systems restrict interoperability, increase maintenance overhead and slow transformation efforts.

The report underscores the scale of the challenge: 75% of healthcare organizations say legacy infrastructure limits their ability to modernize.

By contrast, Cloud Leaders operate with fewer legacy constraints. Only 10% report that legacy systems significantly limit modernization efforts, compared to 44% of less-mature organizations.

Legacy environments often accumulate technical debt over time, creating operational drag and limiting agility. Addressing these dependencies as part of a broader cloud strategy helps reduce that burden and unlock efficiency gains:

• Improved data integration across systems
• Faster deployment of new applications
• Lower maintenance and support costs

Efficiency extends beyond infrastructure

Operational efficiency in healthcare extends beyond IT systems into clinical workflows, administrative processes and decision-making. Cloud maturity begins to unlock broader value, particularly through artificial intelligence.

The report shows that 44% of healthcare organizations have realized improved operational efficiency from AI initiatives. These gains include automation of routine administrative tasks, accelerated data analysis and reduced clinician workload.

AI adoption remains uneven across healthcare organizations. Cloud maturity continues to shape outcomes, as organizations with more advanced cloud environments are better positioned to deploy and scale AI due to stronger data integration, governance and infrastructure capabilities.

This relationship creates a reinforcing cycle between cloud and AI capabilities:

• Cloud enables data accessibility and scalability
• AI applies that data to automate and optimize processes
• Efficiency gains support further cloud investment

Cloud Leaders already operate within this cycle, while others continue building the necessary foundations.

Governance and strategy drive outcomes

Across performance, architecture, legacy modernization and AI adoption, a consistent pattern emerges: operational efficiency depends on how technology is managed.

Cloud Leaders distinguish themselves through stronger governance discipline and operational control, including:

• Alignment between cloud strategy and business objectives
• Financial governance that maintains cost control
• Intentional architecture design
• Ongoing modernization of legacy systems

These capabilities support a more controlled, predictable and efficient operating model.

The executive imperative: From adoption to advantage

For healthcare executives, the conversation has evolved. Cloud adoption is now baseline. Cloud advantage defines differentiation.

Achieving cloud advantage requires a deliberate shift:

• From migration toward optimization
• From infrastructure focus toward measurable outcomes
• From isolated initiatives toward an integrated strategy

Organizations that make this transition reduce operational friction, improve system performance and support innovation at scale.

In a sector shaped by rising costs, workforce pressures and increasing demand, operational efficiency remains foundational. Cloud Leaders show that with the right strategy, architecture and governance, cloud delivers consistent and scalable efficiency.

Read more in the 2026 Research Report: From Cloud Adoption to Cloud Advantage in Healthcare

The data shows clear progress. Cloud is established across the NHS, supported by formal strategies, growing governance maturity and sustained investment.

It also highlights a more specific challenge. Organisations are operating within complex, distributed environments, where outcomes depend less on access to cloud and more on how effectively those environments are integrated, managed and aligned to operational priorities.

Cloud strategy adoption is increasing while maturity and alignment vary

Cloud adoption is advancing across the NHS, though strategy and governance maturity vary between organisations. Forty percent report having a formal cloud strategy, and 20% say cloud operations are well managed within their IT strategy. At the same time, none describe cloud as fully integrated into business strategy.

Where that alignment is still developing, the impact is practical. Teams are managing fragmented environments, balancing cost visibility across multiple platforms and working around integration constraints between cloud services and existing clinical systems. Decisions about workload placement, performance optimisation and security controls are often made within those constraints rather than through a fully aligned strategy.

From what we see, organisations that have progressed further in aligning cloud with operational priorities tend to have clearer governance, more predictable cost management and greater control over how systems and data interact across environments.

Workload placement continues to shift

Our research shows a high level of movement in where workloads are placed. Thirty-seven percent of organisations have moved workloads between cloud providers, and 29% have moved workloads from public cloud back to on-premises environments.

These decisions sit at the intersection of several pressures. Data security and regulatory requirements define where sensitive workloads can run. Existing clinical systems influence how easily new platforms can integrate. Operational teams need visibility and control across environments that have evolved over time rather than being designed as a whole.

In that context, workload placement becomes an ongoing process rather than a one-time decision. Organisations are adjusting environments to meet current requirements while trying to maintain flexibility for the future.

Legacy architectures continue to shape cloud outcomes

Legacy architecture and technical debt continue to influence how cloud capabilities are deployed and integrated.

Fifty-two percent of organisations say legacy systems significantly limit their ability to modernise, and 70% report moderate to high levels of technical debt. These constraints are most visible in cybersecurity, compliance and data integration.

Electronic patient record (EPR) systems provide a clear example. Adoption is widespread, with 85% of organisations using EPR platforms. However, confidence in interoperability remains limited, with only 20% reporting strong confidence in how those systems connect with others.

This creates a structural challenge. Cloud introduces new capabilities, but the value of those capabilities depends on how well systems exchange data and operate together. Where integration is complex, progress depends on incremental change rather than large-scale transformation.

Outcomes correlate with the quality of integration and control

Across our findings, a consistent pattern emerges. Organisations that have integrated cloud into their operating model report stronger control over cost, clearer governance and more predictable performance. Where integration is weaker, teams spend more time managing complexity across systems and environments.

The challenge now is to operate cloud environments as part of a coherent, well-governed model that supports clinical and operational priorities, with integration, cost management and control addressed as part of the design rather than through ongoing adjustment.

Strengthening the foundation already in place

Cloud adoption continues to advance across the NHS, with organisations building capability at different stages of maturity. The next stage of progress depends on how effectively those environments function together in practice.

That involves reducing technical debt where it limits integration, designing architectures that support consistent data flow across systems and ensuring that security and compliance requirements are addressed within the design of those environments rather than after the fact. It also requires closer alignment between cloud strategy and the priorities that drive day-to-day operations across clinical and administrative teams.

These factors determine whether cloud delivers isolated improvements or sustained, system-wide value.

The opportunity now is to ensure cloud environments operate with the consistency, integration and control required to support the next phase of digital care.

For a deeper view of the UK findings, including AI adoption and cyber resilience, explore the full NHS-focused Rackspace Healthcare survey report.

While the legislation is framed around cyber resilience, its implications go further. At its core, the bill accelerates a conversation the UK has already begun: digital sovereignty is no longer theoretical. It is becoming operational, enforceable and unavoidable.

For years, cybersecurity has been treated as a technical discipline, managed largely within IT teams. This bill signals something different. Cyber resilience is now a matter of national resilience, and organisations that underpin essential services will be expected to demonstrate not just protection, but control.

That shift places digital sovereignty firmly at the centre of the resilience debate.

From cyber security to sovereign resilience

The most important signal in the bill is right there in the name. This is not legislation focused solely on preventing attacks. It is about continuity, accountability and recoverability.

Modern disruption is rarely confined to a single threat vector. Supply-chain compromise, cloud outages, geopolitical shocks and AI-driven failures increasingly intersect. In recent years, UK organisations have experienced first-hand how outages affecting major global providers can ripple through essential services. Incidents involving AWS and Microsoft Azure have disrupted workloads relied upon by public bodies, while widespread Cloudflare outages have affected access to critical websites and online services across the UK. In several cases, issues originating outside the UK have had direct operational impact on UK organisations, including those supporting critical national infrastructure.

These events were not necessarily security breaches. They were resilience failures, or concentration risks exposed under stress.

In this environment, resilience depends less on individual security controls and more on who has the authority to act when systems are under pressure, and whether local operators retain meaningful control.

That is a sovereignty question.

Cyber resilience, in practice, requires:

• Clear operational ownership
• Jurisdictional clarity when decisions must be made quickly
• Confidence that systems behave predictably under stress

These qualities cannot be improvised during an incident. They must be designed into the digital estate from the outset.

Why digital sovereignty is the missing layer

The Cyber Resilience Bill does not extensively use the term digital sovereignty, but it effectively legislates for it.

Resilience assumes that organisations can intervene decisively during disruption. That assumption only holds if they retain meaningful decision rights over their infrastructure, data and operations.

As cloud adoption has accelerated, many organisations have gained speed and scale while losing visibility and control. In day-to-day operations, that trade-off can feel manageable. In a national or sector-wide crisis, it becomes a critical vulnerability.

Digital sovereignty is what ensures resilience plans can actually be executed.

Legal clarity and jurisdictional control

A core theme emerging from the bill is accountability. Organisations will be expected to demonstrate not only intent, but capability.

That capability starts with legal and jurisdictional assurance. UK organisations need confidence that:

• Data and workloads are governed under UK law
• Operational decisions are not constrained by conflicting external obligations
• Sensitive systems are supported by trusted, cleared personnel

Simply hosting data in the UK is not enough. Sovereignty requires alignment across infrastructure, operations and governance. Without that alignment, accountability becomes blurred precisely when clarity is needed most.

Resilience, sovereignty and national readiness

Digital sovereignty and national resilience are increasingly inseparable.

Recent global events have shown how quickly international disruption can cascade through digital systems. Infrastructure supporting essential services must be able to operate through prolonged instability, not just isolated incidents.

A sovereign-aware approach to resilience enables:

• Architectures designed for continuity across UK regions
• Clear escalation and crisis-management authority within national jurisdiction
• Operational independence during global disruption

This is not about withdrawing from global ecosystems. It is about ensuring the UK retains agency when circumstances demand it.

Sovereign control over AI-driven systems

The bill also lands as AI becomes embedded into critical workflows and decision-making processes.

AI systems do not merely store data. They influence outcomes, automate actions and increasingly operate at machine speed. That makes sovereign control over AI workloads a resilience issue, not just an ethical one.

Organisations must be able to answer:

• Where AI models are trained, hosted and governed
• Who can modify, tune or override them
• How decisions can be audited, explained and challenged

Resilient AI depends on infrastructure and governance models that preserve human oversight, even under pressure.

Reducing concentration and dependency risk

Another implicit theme in the resilience conversation is concentration risk.

Over-reliance on a small number of platforms can introduce systemic vulnerabilities that no amount of security tooling can fully mitigate. Sovereign digital strategies reduce this risk by supporting:

• Hybrid and multi-cloud architectures
• Portability and interoperability
• Long-term flexibility without forced re-platforming

Reducing vendor lock-in is not simply a commercial preference. It is a resilience requirement.

Transparency, auditability and governance by design

Resilience that cannot be demonstrated will not satisfy regulators, boards or the public.

The bill reinforces the need for environments that are transparent, auditable and governed by design. Sovereign digital infrastructure makes this possible by embedding visibility and accountability into daily operations rather than relying on post-incident reconstruction.

For public bodies and regulated sectors, this transparency underpins trust.

What this means for UK organisations

The Cyber Resilience bill is not just a future compliance exercise. It is a signal to reassess assumptions being made today.

Organisations should be asking:

• Where do we truly retain control, and where do we rely on trust?
• Can we operate effectively through prolonged disruption?
• Do our cloud and AI strategies strengthen or weaken sovereignty?

These are strategic questions with long-term implications.

Rackspace’s perspective

At Rackspace, we see cyber resilience and digital sovereignty as deeply interconnected. Resilience requires robust security and recovery capabilities — but it also depends on retaining clear operational and jurisdictional control over the systems that matter most.

Resilient organisations retain decision rights over the systems that matter most. That means clear jurisdictional assurance, transparent operations and architectures designed for continuity rather than convenience.

We support UK organisations in building sovereign cloud environments that balance scale with control, enabling:

• UK-aligned legal and operational assurance
• Infrastructure designed for resilience and recovery
• Transparent, auditable operations
• Flexibility across hybrid and multi-cloud models

Resilience is not delivered by a single technology choice. It is delivered by sovereign-aware design decisions, made early and reinforced over time.

A turning point for digital sovereignty

The Cyber Resilience Bill marks a turning point.

It moves the conversation from security controls to operational confidence. From compliance to capability. From data residency to decision rights.

For UK organisations, digital sovereignty is no longer optional context. It is the foundation on which cyber resilience now rests.

Explore how Rackspace Technology helps organisations build sovereign cloud environments designed for security, resilience and operational control.

But in mature Amazon Web Services (AWS) and hybrid environments, innovation usually slows for a different reason; Reactive operating models quietly consume the capacity required to EXECute transformation.

When engineering teams spend their time stabilizing, they cannot build. Innovation velocity becomes a function of operational intelligence.

The hidden tax of reactive operations

As cloud environments scale, even well-run estates can drift into a pattern of controlled interruption.

High alert volumes create cognitive overload. In some environments, up to 95% of alerts represent noise. Yet every alert demands attention. Engineers must still read, triage and decide whether it matters.

Manual triage often absorbs 30-45 minutes per incident. Multiply that across dozens of alerts each week and the impact becomes clear. Even when incidents are resolved quickly, the context switching persists.

Extended mean time to resolution further disrupts delivery timelines. When recovery stretches into multiple hours, sprint commitments shift, planned releases move and strategic work slows. The interruption does not end with the incident itself; it lingers in the form of rework, reprioritization and regained context.

Recurring failure patterns compound this drag. The same categories of issues resurface, the same subject matter experts get paged and the same remediation steps repeat without structural resolution.

Over time, this dynamic creates innovation erosion through interruption. The cost rarely appears in a budget review. It surfaces instead as delayed migrations, postponed modernization milestones and incremental delivery across strategic programs.

Organizations move at the speed of recovery confidence

Deployment velocity is highly visible in most AWS environments. Recovery confidence is less visible but often more decisive.

When recovery is slow or unpredictable, leadership behavior shifts in measurable ways. Release windows narrow, change approvals expand and late-week deployments become increasingly rare. What begins as caution gradually becomes structural hesitation.

Risk tolerance also declines. Experimental features receive additional scrutiny, architectural refactors lose priority and transformation initiatives stretch across longer timelines. Teams begin to optimize for avoiding failure rather than accelerating progress.

In this context, agility is not defined by how quickly new code reaches production. It is defined by how quickly failure can be contained without cascading disruption.

Organizations tend to move at the speed of their recovery confidence. If containment remains slow or inconsistent, cloud innovation strategy slows accordingly, regardless of how modern the tooling stack may be.

The compounding effect of operational noise

Operational noise does more than absorb time; it reshapes culture and decision-making.

In high-noise environments, escalation paths frequently converge on a small group of experienced engineers. Institutional knowledge concentrates, and each complex incident reinforces dependency on a limited set of experts. Over time, this pattern becomes a structural bottleneck.

Persistent interruption also drives burnout. Engineers who consistently shift between roadmap EXECution and firefighting struggle to maintain deep focus, and sustained context switching reduces both productivity and job satisfaction. As fatigue increases, attrition risk follows.

Talent churn then weakens architectural continuity. Decisions are revisited without full historical context, standards begin to drift and technical debt accumulates under pressure to restore service quickly. What appears to be short-term resilience can mask long-term fragility.

A reactive operating model therefore creates compounding drag across the organization, reducing clarity, increasing dependency and gradually constraining the very capacity required for innovation.

Innovation requires stability

Modern transformation initiatives increase operational complexity by design.

AI programs expand telemetry, introduce new data pipelines and add performance-sensitive workloads that demand tighter operational control. Modernization efforts deepen service dependencies across distributed systems, where small configuration errors can propagate rapidly.

Hybrid estates add another layer of coordination between on-premises and cloud environments, which complicates observability and multiplies potential failure domains.

In this environment, innovation without operational discipline accelerates fragility. Each new initiative adds stress to systems that may already be strained, and engineering capacity shifts from strategic development to reactive containment.

Cloud operational maturity should not be viewed as a counterweight to innovation. It is the foundation that allows innovation to scale without destabilizing the estate.

From reactive to intelligence-driven operating models

Mature cloud operating models distinguish themselves by how they manage signal, speed and standardization.

They reduce noise before it reaches human operators through alert correlation and event consolidation, which transforms scattered signals into actionable insight. They automate remediation for known failure patterns and translate institutional knowledge into standardized runbooks supported by governed automation.

They invest in predictive monitoring that surfaces leading indicators of risk, allowing teams to intervene before customer impact occurs. They design automation frameworks with clear guardrails so that change velocity can increase without compromising control.

These capabilities do more than reduce multi-hour mean time to resolution (MTTR) in AWS environments. They protect engineering focus and stabilize delivery timelines.

When incidents resolve in minutes rather than hours, context switching declines. When noise decreases, cognitive load becomes manageable. When remediation steps are codified, reliance on a small group of experts diminishes.

Operational maturity creates the structural space required for experimentation, modernization and sustained cloud innovation strategy.

Innovation velocity is operationally determined

Most large-scale AWS environments don’t lack ideas or ambition. What they often lack is uninterrupted capacity.

Reactive operating models redirect engineering focus from building to stabilizing, and over time that redirection shapes delivery outcomes more than strategic intent does. If innovation has slowed, the constraint may not be budget, talent or tooling. It may be the operating model itself.

Operational intelligence ultimately determines how much capacity remains available for transformation. Reducing noise, accelerating containment, codifying recovery knowledge and governing automation are not operational optimizations alone; they are strategic levers.

When stability becomes predictable, innovation no longer competes with resilience. It compounds with it.

Ready to reduce MTTR in AWS and strengthen your cloud operating model?

Download the Operate the Cloud Intelligently guide to explore how cloud operational maturity accelerates innovation.

Providers, payers and health innovators kept coming back to a shared priority: environments that simply work. Reliable. Secure. Built for consistency. Workloads need to be resilient and predictable, staying out of the way so clinicians can focus on care delivery rather than technology friction.

This idea shaped our speaking session with Dell Technologies. Together, we explored how healthcare organizations are reframing infrastructure and cloud. When designed with intention, they become foundational. They support outcomes without demanding attention.

That shift aligns with what we see in our latest third-party report conducted by Coleman Parkes Research. Healthcare organizations continue to adopt cloud to improve reliability, flexibility and data security. The differentiator is maturity. Organizations pulling ahead, what we call cloud leaders, are operationalizing cloud in ways that strengthen resilience, security and AI outcomes.

In fact, 52% of healthcare leaders cite reliability and availability as top drivers for cloud adoption. That reinforces what we heard at HIMSS. Infrastructure must be dependable first. Everything else builds from there.

As Rackspace Technology VP of Sales Tim Lankes shared during the week, “Becoming a cloud leader isn’t about adoption alone. It’s about building an environment that is secure, resilient and designed to run seamlessly in the background so healthcare teams can focus on delivering patient care.”

That distinction matters. Many organizations are still navigating legacy infrastructure, security constraints and skills gaps. Those that move beyond adoption to true cloud advantage are seeing measurable gains, from stronger cyber resilience to more advanced AI integration and greater confidence in protecting patient data.

HIMSS 2026 made one thing clear. Healthcare doesn’t need more complexity. It needs infrastructure designed to support outcomes without getting in the way.

Explore the research and take the next step

Read our latest healthcare cloud report to see how cloud leaders are strengthening critical workloads, improving resilience and enabling AI-driven outcomes.

It typically doesn’t appear as a sudden spike. Instead, spending trends upward over time, making forecasting more complex and creating tension between technology and finance teams. Rightsizing initiatives, savings plans adjustments and discount negotiations may produce improvements in a given quarter, yet the overall trajectory resumes its climb.

In many cases, this pattern reflects an operating model issue rather than a pricing problem.

Most cost conversations focus on financial mechanisms. Persistent cost drift, however, is usually shaped by how AWS environments are provisioned, governed, recovered and evolved on a daily basis.

Why optimization gains erode over time

Traditional cost optimization programs emphasize financial levers:

• Savings Plans and reserved capacity coverage
• Periodic rightsizing reviews
• Enterprise discount negotiations

These efforts are necessary, but they assume a relatively stable infrastructure baseline between review cycles.

AWS environments are rarely static. Teams deploy new services, respond to incidents, expand capacity during peak demand and adjust configurations under operational pressure. Changes introduced for resilience or speed frequently remain in place long after the original condition has passed.

When there is no formal mechanism to reassess those decisions, optimization becomes cyclical. Savings are captured, and gradual operational expansion absorbs them. Over time, that pattern becomes structural.

How cost drift develops in AWS environments

Cost drift accumulates through routine operational behavior. Individual decisions appear reasonable in isolation. In aggregate, they reshape the cost baseline.

Temporary capacity that becomes baseline capacity

Following an availability event, teams often increase headroom to reduce risk. They may select larger instance families, widen autoscaling thresholds or add additional nodes.

Without a structured review process, those adjustments remain embedded in the environment. What began as a short-term buffer becomes part of standard operating configuration.

Recovery environments that exceed current requirements

Disaster recovery architectures frequently include warm or hot standby resources. As systems evolve, those environments are not always recalibrated to match updated recovery objectives.

Over time, the organization may maintain higher levels of redundancy than its current risk profile requires.

Manual incident response that scales labor exposure

When recovery processes rely heavily on manual triage and escalation, senior engineers devote significant time to recurring events. Prolonged recovery can also extend the lifespan of temporary infrastructure changes introduced during incidents.

The cost impact reflects both labor hours and the persistence of elevated configurations.

Tool proliferation across accounts

As AWS footprints expand across regions and business units, tooling decisions often decentralize. Multiple observability platforms, overlapping logging pipelines and parallel ticketing workflows can develop independently.

Each investment may address a legitimate need. Without coordination, the collective tooling layer increases operational overhead and recurring spend.

Inconsistent governance enforcement

Multi-account AWS environments depend on consistent tagging, identity policies and scaling standards. When governance relies primarily on guidance rather than enforcement, drift in configuration and cost behavior is difficult to contain.

Over time, exceptions and inconsistencies influence spend more than isolated optimization efforts.

Recovery performance as a cost variable

The speed and predictability of recovery materially influence cloud cost structure.

When incidents take longer to resolve, teams often introduce additional capacity to stabilize workloads. Senior engineers remain engaged for extended periods, and leadership attention shifts toward risk mitigation measures that add redundancy or tooling.

Organizations with mature automation and incident management practices generally achieve shorter mean time to repair (MTTR). While improvement percentages vary by environment, the relationship is consistent: as recovery becomes more predictable, the need for prolonged high-cost configurations and repeated escalations decreases.

This relationship is less about a single percentage improvement and more about structural behavior. Predictable recovery reduces the likelihood that temporary expansion becomes permanent baseline spend.

Governance as embedded cost control

If cost drift reflects operating behavior, governance must function as a built-in control system within AWS environments.

Effective approaches typically include:

Automated guardrails at the account level

Policies governing tagging, instance types, scaling ranges and identity controls can be enforced programmatically. Automated enforcement reduces reliance on manual review cycles and distributes accountability across teams.

Continuous review of operational signals

Cost data provides lagging indicators. Operational signals such as recurring incidents, alert volume and manual ticket trends often reveal where cost pressure is forming.

Integrating these signals into platform governance creates earlier intervention points.

Standardized recovery and remediation patterns

Documented runbooks and automated remediation workflows reduce variability in response. When recovery follows consistent patterns, temporary measures are more likely to be evaluated and reversed once stability returns.

Cross-account architectural consistency

In complex AWS estates, shared baselines for logging, monitoring and scaling policies create more uniform cost behavior across teams and regions.

These mechanisms do not prevent growth. They create discipline around how growth occurs.

Where AI Ops changes the cost trajectory

Addressing AWS cost drift at scale requires more than periodic review cycles. It requires systems that continuously correct behavior as environments evolve.

This is where AI-driven operations models are increasingly relevant.

AI Ops platforms analyze operational signals across incidents, alerts, configuration changes and performance trends to identify patterns that humans often detect too late. Instead of relying on quarterly cost reviews, the environment can surface and remediate drift conditions closer to when they occur.

In practical terms, AI Ops can:

• Trace cost increases back to their operational cause, enabling earlier rollback of drift inducing changes
• Identify idle or underutilized resources introduced during recovery
• Reduce alert noise that drives reactive scaling decisions
• Automate remediation steps that shorten recovery time

As recovery becomes faster and more predictable, organizations reduce the likelihood that temporary expansion becomes permanent baseline spend.

For many enterprises, this shift also has a talent implication. Senior engineers spend less time on repetitive triage and manual remediation and more time on architecture, modernization and product-facing innovation.

Rackspace Managed Cloud integrates AI Ops capabilities into day-to-day cloud operations to drive this discipline continuously. In environments where operational inefficiency is a material contributor to spend, organizations may realize cost reductions of up to 30% while improving recovery performance and governance consistency.

The precise impact depends on workload complexity, architectural maturity and existing automation. The broader outcome is structural: fewer reactive decisions, tighter operational control and more predictable AWS cost behavior.

Questions for executive review

To determine whether AWS cost drift stems from pricing or operational behavior, consider:

1. After major incidents, do we formally reassess and roll back temporary capacity increases?
2. How frequently do we align recovery environments with current recovery objectives?
3. What portion of incidents requires sustained involvement from senior engineers?
4. Are tagging, scaling and identity standards enforced consistently across all AWS accounts?
5. How coordinated are tooling decisions across business units?
6. If recovery became faster and more predictable, what excess capacity or workflows could be retired?

When operating patterns shape spend, improvement will come from strengthening the operating model that governs AWS usage.

To learn more about handling AWS cost drift, download the Run AWS at Scale e-book.