Advanced made NHS 111 software dependency a care-continuity

Summary

Advanced Computer Software Group's August 2022 ransomware incident disrupted products used in NHS 111, out-of-hours care and social-care workflows, including Adastra.
Contemporaneous reports describe operational disruption, fallback activity and an extended product-by-product recovery process. They do not establish one uniform period in which every NHS 111 service nationwide was unavailable.
The final Information Commissioner's Office material says availability was affected for 658 data-controller customers. That is an operational-availability population, not a data-exfiltration population.
The ICO separately says personal data was exfiltrated from systems used by 16 controller customers, affecting 79,404 people. Those figures must not be projected across all 658 availability-affected controllers.
The enforcement record places Advanced in the role of data processor and examines the appropriateness of technical and organisational security measures, including access and vulnerability-management weaknesses.
The public record supports service disruption, personal-data compromise and regulatory findings. It does not establish deaths, specific patient injuries or a quantified national clinical outcome caused by the incident.
The provisional GBP 6.09 million figure announced in 2024 was not the final fine. The March 2025 outcome was GBP 3,076,320 following a voluntary settlement, and the ICO says Advanced agreed not to appeal.
Recovery was not complete merely when infrastructure returned. Affected products had to be restored, checked and reconnected for individual controller customers whose care workflows and local fallback arrangements differed.
Durable repair requires evidence that supplier access is hardened, vulnerabilities are managed, backups can be restored, products can be reconnected safely and controller organisations receive precise evidence about both operational disruption and personal-data exposure.

Care responsibility remained local while workflow control did not

An urgent-care professional can know what a patient needs and still be unable to use the software through which the service normally organises that need. A clinician or call handler may retain judgment. An NHS organisation may retain statutory and operational responsibility. Yet the workflow that records, routes or shares information can depend on a product operated by an external supplier.

That dependency became visible in August 2022 when a ransomware incident at Advanced affected software used across health and social care. Contemporaneous reports connected the disruption to Adastra, a product supporting NHS 111 and out-of-hours workflows, as well as other care-management systems. NHS bodies worked with cyber authorities and used fallback, rerouting or workaround arrangements while the supplier assessed and restored affected services.

The incident was not simply an internal IT problem at one hospital. Nor was it a uniform shutdown of every NHS 111 service. It was a supplier incident that reached multiple controller organisations through products on which their local services depended.

This distinction changes the accountability analysis. A controller organisation could activate continuity procedures, communicate locally and decide when it was safe to resume a workflow. It could not independently rebuild a supplier-operated product, inspect every supplier security control or reconnect itself without evidence from Advanced. The supplier held capabilities that individual customers did not.

Advanced, in turn, did not control every public-service outcome. NHS organisations and public authorities held routing, staffing, local records, clinical decision-making and public communication responsibilities. Some services could fall back in ways others could not. Care continuity therefore depended on a chain of controls distributed across supplier, customer and public authority.

When that chain works, specialisation is useful. A supplier can maintain software and infrastructure for many organisations, while each controller focuses on delivering care. When the supplier fails, the same concentration can make recovery evidence a shared bottleneck. Hundreds of customers may need answers about availability, data and reconnection from one operator at the same time.

The central question is not who owned the word “care.” It is who could change the control that failed and who could prove that the next step was safe.

Two evidence periods must not be collapsed

The public account has two principal periods. The first is the operational record from August 2022, when organisations were trying to understand the outage and sustain services. The second is the regulatory record culminating in the ICO's March 2025 enforcement outcome.

Contemporaneous reporting is strongest on what operators and customers were experiencing. The Record reported that NHS bodies were working with UK cyber authorities to assess the incident. Digital Health described major outages and product-specific status developments. The Register, the Guardian, Computer Weekly and GP reporting documented disruption around NHS 111 and the prospect of a lengthy recovery for some services. Public-sector and professional sources add context about remote health advice and later service effects.

Those reports were produced before the final regulatory investigation was complete. They should not be rewritten as though reporters in August 2022 already knew every finding the ICO would publish in 2025. Early descriptions may use the information available from Advanced, customers and authorities at the time.

The final ICO action page, press release and penalty notice serve a different function. They provide the authoritative figures for the final penalty, the affected controller populations and the regulator's conclusions about security measures. They also record the voluntary settlement and no-appeal agreement.

The 2024 ICO announcement belongs between those periods. It described a provisional decision and proposed GBP 6.09 million fine. A provisional decision is part of an enforcement process. It is not the final legal and financial outcome. Advanced made representations, and the matter concluded in 2025 at GBP 3,076,320 through a voluntary settlement.

Parliamentary written evidence also needs its proper status. It can illuminate what a submitter told Parliament about the incident and its effects. It is not automatically a finding adopted by a committee. The evidential role of a regulator's penalty notice, a company's incident update, contemporaneous journalism and submitted parliamentary evidence is not interchangeable.

Keeping the periods separate prevents hindsight from distorting the operational story. It also prevents early uncertainty from weakening the later findings. In 2022, organisations needed to keep care pathways functioning with incomplete information. By 2025, the ICO had a developed enforcement record. Both belong in the account, but they answer different questions.

August 2022: one supplier incident, multiple local effects

The incident began in August 2022 and affected Advanced products used by health and social-care customers. Adastra became a prominent part of the public account because it supports NHS 111 and out-of-hours care. Other Advanced care products were also reported as affected.

Ransomware was the incident mechanism identified in the record. The consequences included loss of software availability and, for a narrower set of systems, exfiltration of personal data. Product restoration and customer reconnection extended beyond the first public reports.

The available evidence does not establish one national outage clock. Different products had different roles. Different controller organisations had different deployments, dependencies and fallback arrangements. A call service, an out-of-hours provider and a social-care organisation could each experience the loss of supplier software differently.

That is why the safe chronology is product- and customer-aware. The incident affected supplier systems. Advanced and public authorities assessed the event. Customers activated local workarounds and continuity processes. Restoration proceeded across affected products and organisations. The exact order and duration for every customer are not fully established in the public record.

It would be tempting to substitute a dramatic national formulation: “NHS 111 was down.” That language is too coarse. It can imply that every NHS 111 function in every place failed at once and remained unavailable for the same period. The evidence supports material disruption around NHS 111-related software, not a uniform nationwide state.

The narrower description is still consequential. Urgent-care workflows rely on timely information and coordination. When a supplier-operated product becomes unavailable, staff may need to use manual processes, alternative routes or reduced-function systems. That can increase friction and delay without proving a specific clinical injury.

Care continuity is therefore a legitimate accountability lens even in the absence of a quantified health outcome. Continuity is the ability to sustain a service through disruption, not merely the count of harms after the fact. A failure can reveal weak dependency controls before a causal chain to injury is documented.

The numbers describe two different scopes

The ICO figures are central, and they are easy to misuse.

The enforcement material says availability was affected for 658 data-controller customers. In data-protection terms, a controller determines the purposes and means of processing personal data, while a processor handles data on the controller's behalf. Here, the 658 figure describes Advanced customers whose service availability was affected.

The ICO separately says personal data was exfiltrated from systems used by 16 controller customers, affecting 79,404 people. That is a confidentiality and data-subject scope attached to a narrower set of controller systems.

These figures do not form one interchangeable population. The 658 controllers are not 658 people. They are not necessarily 658 NHS 111 organisations. They are not all confirmed exfiltration victims. The 16 controllers are not a subset that can be multiplied by an average number of people to estimate exposure elsewhere. The 79,404 people are not an operational-outage total.

The distinction can be expressed as two separate questions:

Whose access to supplier services was disrupted?
From which systems was personal data taken, and how many people did that data concern?

The first question is about availability. The second is about confidentiality. One incident can affect both, but the evidence required for each is different.

An organisation can lose access to software without data from its system being exfiltrated. Data can be exfiltrated from a system even if another customer's service experiences only availability disruption. Combining the figures would exaggerate the data breach and obscure the operational breadth.

The ICO press release says affected material included sensitive data from health and care contexts. It also described information that could enable access to the homes of some people receiving care. That detail explains why confidentiality risk extended beyond ordinary account information. It does not establish that anyone used the information to enter a home or cause physical harm.

The correct interpretation therefore preserves both severity and precision. Availability effects reached 658 controller customers. Confirmed exfiltration in the enforcement record concerned systems used by 16 controllers and personal data relating to 79,404 people. Neither scope should be enlarged with the other.

This is more than numerical hygiene. Controllers needed different evidence depending on their position. An availability-affected customer needed restoration and reconnection information. A controller whose systems were within the exfiltration scope also needed evidence for data-breach assessment, notification and support to affected people. Treating everyone as if they faced the same event would weaken both responses.

Operational disruption is not proof of clinical harm

Health-service incidents often invite a leap from system failure to patient harm. The public record here does not support that leap.

The sources establish disruption to software used in urgent-care and social-care workflows. They describe organisations working around unavailable systems and managing recovery. The ICO establishes personal-data compromise and security findings. None of that proves the incident caused deaths, particular injuries or a quantified national clinical outcome.

The absence of such proof does not make the operational impact trivial. Manual processes can demand more time. Rerouting can increase load elsewhere. Loss of familiar software can reduce visibility and complicate coordination. Staff may have to reconcile records after systems return. Those are plausible continuity pressures, but their exact clinical consequences require evidence.

Responsible analysis therefore avoids two opposite errors. It should not invent patient outcomes to make the incident sound serious. It should not imply that an incident affecting urgent-care workflows is unimportant because no attributable death count is available.

The appropriate measure is whether services retained safe and workable paths under supplier failure. Which functions could continue? Which needed alternative systems? How were records maintained and reconciled? How did organisations decide when to reconnect? How long did particular product dependencies remain constrained?

Those questions focus on capabilities. They allow care providers and suppliers to improve continuity without converting uncertainty into an allegation.

They also clarify responsibility. Advanced controlled the operation and restoration of affected supplier products. Controller organisations controlled local service continuity and clinical governance. Public authorities could coordinate at system level. A clinical outcome might depend on actions across that chain, so it cannot be assigned to one party without evidence.

The processor relationship made supplier controls consequential

The ICO record treats Advanced as a data processor for controller customers. That role does not make the supplier a passive carrier. A processor operating software and infrastructure can hold direct control over access, vulnerability management, monitoring, backups, restoration and technical incident response.

Controller organisations remain responsible for their use of personal data and for selecting and governing processors. They may set contractual requirements, review assurances, maintain continuity procedures and make notification decisions. Yet they cannot independently inspect every live control inside a supplier environment.

This creates an evidence dependency. Before an incident, controllers need credible assurance that the processor's controls match the sensitivity and operational importance of the service. During an incident, they need accurate facts about availability and data scope. During recovery, they need product-specific evidence that restoration and reconnection are safe.

The ICO enforcement material examined the appropriateness of Advanced's technical and organisational measures under UK GDPR security obligations. The available account identifies access and vulnerability-management weaknesses within that wider assessment. It would be inaccurate to compress the regulator's case into one missing control or one simple cause.

A ransomware incident normally involves a chain: an opportunity for access, expansion of authority, contact with valuable systems, execution of destructive or exfiltration activity, detection, containment and recovery. The public summary does not assign a complete causal share to each Advanced control. The regulator's broader measures framing matters because security depends on how controls work together.

For example, access hardening can reduce entry or misuse. Vulnerability management can close known paths. Segmentation can limit reach. Monitoring can shorten dwell time. Backups can preserve recoverability. None is a complete substitute for the others.

Processor accountability should therefore be evaluated through the capabilities the supplier controlled and the evidence it can produce. It should not be reduced to the proposition that a customer ultimately remained the controller. Legal roles distribute duties; they do not erase operational control.

Root cause, trigger and consequence need separate labels

Ransomware describes the malicious incident. It does not by itself explain every enabling condition.

The ICO made findings about security measures, including access and vulnerability management. The public materials also document operational unavailability, data exfiltration and extended recovery. Those findings identify important control failures and consequences. They should not be rewritten as a claim that one missing measure was the sole root cause.

The trigger can be understood as the malicious activity that forced systems out of normal operation. The precise initial access and complete attack sequence require the penalty notice's detailed evidence and should be reported only to the level the regulatory record supports.

Contributing conditions concern the control environment: how access was protected, how vulnerabilities were managed, how systems were separated, how activity was detected and how recovery was prepared. The ICO's measures analysis belongs here.

Operational consequences include product unavailability for controller customers and the need for fallback and reconnection. Confidentiality consequences concern data exfiltrated from the narrower group of systems identified by the regulator.

Response includes containment, investigation, communication and rebuilding. Recovery includes restoration of product functionality and safe reconnection for individual customers. These can proceed at different speeds.

This classification prevents a recurring accountability failure. If the attacker is treated as the only cause, the supplier's controllable blast radius disappears. If one technical weakness is named the entire root cause, organisational measures and recovery capability disappear. If service restoration is called complete response, data exposure and customer-specific reconnection disappear.

The Advanced case requires the full chain. Malicious activity created the incident. The regulator later found the supplier's measures inadequate in relevant respects. Availability was affected broadly across controller customers. Exfiltration was confirmed for a narrower population. Recovery required more than switching infrastructure back on.

Controller organisations controlled the local continuity layer

Advanced held the supplier-side technical controls, but controller organisations were not spectators.

Each organisation had to understand which local workflows depended on affected products. It had to decide how to continue service, how to record actions while systems were unavailable, how to communicate with staff and users, and how to reconcile information after restoration.

Controllers also held supplier-governance responsibilities. Before an incident, they could define requirements for security, recovery objectives, incident notification and evidence. They could assess concentration risk and test whether critical functions had a workable fallback.

The practical strength of those controls varies. A small care organisation may have limited leverage over a major supplier. It may be unable to obtain detailed architectural evidence or maintain an alternative product ready for immediate use. Procurement terms do not automatically create operational capability.

That asymmetry makes precise supplier evidence more important. A controller cannot responsibly reconnect a system on the basis of a generic statement that services are returning. It needs to know which product instance was restored, what integrity checks were performed, whether data was reconciled and what residual risks remain.

Controllers within the exfiltration scope also faced data-governance decisions. They needed evidence about the affected systems, categories of data and people concerned. Those decisions are different from the continuity choices facing a customer whose service was unavailable but whose system was not identified within the exfiltration scope.

The 658-versus-16 distinction therefore maps directly onto controller duties. An availability-affected customer did not automatically face the same data-breach response as a controller in the confirmed exfiltration scope. Data-exposure decisions could not be inferred from the general outage.

Accountability at the controller layer should be measured by preparation and evidence use, not by pretending the controller could operate the supplier's infrastructure. Did the organisation know its dependency? Could it continue critical work? Did it preserve local records? Did it demand product-specific reconnection evidence? Did it communicate accurately with the people for whom it was responsible?

NHS and public authorities held the coordination layer

A supplier incident affecting multiple health organisations can exceed the visibility of any one customer. Public authorities and sector bodies can coordinate cyber assessment, share information, manage routing and communicate at a system level.

Contemporaneous reporting said NHS bodies were working with UK cyber authorities. That coordination mattered because product unavailability could affect multiple organisations using related workflows. A central view can identify where fallback capacity is under strain and where restoration should be prioritised.

System-level coordination does not mean every service experiences the same effect. Public communication should avoid flattening local variation. It should identify the products and functions affected, explain available alternatives and update the picture as services reconnect.

Authorities also need to distinguish cybersecurity response from clinical continuity. Technical teams may focus on containment and evidence preservation. Service leaders may focus on call routing, staffing and safe workarounds. Data-protection teams may focus on affected populations and notices. Those tracks must exchange evidence without becoming one indistinct crisis label.

The public record does not provide a complete NHS after-action account covering every organisation. It therefore cannot support a definitive judgment about the effectiveness of every fallback. The documented disruption is enough to establish that supplier dependency belongs in sector continuity planning.

Recovery required customer-specific reconnection evidence

Supplier recovery is not a single moment. Infrastructure can be rebuilt while an application remains unavailable. An application can run while customer data is incomplete. A product can pass the supplier's checks while a controller still needs to validate local integrations and records.

The Advanced record describes a long reconnection span for affected customers. Public reporting also anticipated extended recovery for some services. The exact sequence for every product and organisation is not complete, so no universal restoration date is supportable.

Safe reconnection requires several kinds of evidence. The supplier needs to show that the restored environment is trusted, that relevant vulnerabilities and access paths are controlled, that backups or recovered data have integrity, and that monitoring is active. The controller needs to know what changed and what local checks remain.

Data reconciliation is especially important in care workflows. Actions may have been recorded manually or in fallback systems while the primary product was unavailable. Reconnection can create duplication, gaps or ordering problems if those records are not aligned. The public sources do not establish a particular reconciliation failure at Advanced; they establish why reconnection cannot be measured only by server uptime.

Prioritisation also requires transparency. A supplier serving hundreds of controllers may need to restore products and customers in stages. The criteria should reflect safety, dependency, technical readiness and available fallback, not merely which customer can exert the greatest pressure.

Controller-specific evidence reduces two risks. It prevents an organisation from resuming too early on the basis of a general status update. It also prevents indefinite caution when the relevant product and data have in fact been restored safely.

The recovery record should therefore preserve, for each affected service, what was unavailable, what was restored, what validation passed, what data interval may need reconciliation and who accepted reconnection. That is the bridge between supplier recovery and care continuity.

Availability and confidentiality require separate communications

During a ransomware incident, organisations often communicate under one headline: cyber attack. Customers need more precise categories.

An availability update should say which products or functions are unavailable, what fallback exists, when the next assessment will occur and what customers should do. It should not imply data theft merely because systems are down.

A confidentiality update should identify whether personal data was accessed or exfiltrated, which controller systems were involved, what categories of data and people are affected, and what remains uncertain. It should not use the broad outage population as a substitute for investigation.

The Advanced figures show why this split matters. An update to 658 availability-affected controller customers could be appropriate for service continuity. It would not by itself mean all 658 should tell people that their data had been exfiltrated. The regulator's confirmed exfiltration scope involved systems used by 16 controllers and 79,404 people.

The sensitivity of some affected information raises the stakes. The ICO said some data could enable access to homes of people receiving care. Communication should support protective action without implying that such access actually occurred.

Precise language also protects credibility. “No evidence at this time” is different from “did not happen.” “Service restored” is different from “local records reconciled.” “Controller affected by availability” is different from “controller within the exfiltration scope.”

These distinctions are not public-relations refinements. They determine which operational, legal and personal actions are justified.

The enforcement timeline is part of the accountability record

The ICO announced a provisional decision in August 2024 that contemplated a GBP 6.09 million fine. That figure attracted attention, but it did not become the final penalty.

The final March 2025 outcome was GBP 3,076,320. The ICO says it followed a voluntary settlement and that Advanced agreed not to appeal. The final amount, not the provisional proposal, is the correct enforcement figure.

Explaining both amounts is useful only if their procedural difference remains clear. A regulator may revise a proposed penalty after representations, legal analysis and settlement. The lower final amount does not erase the findings. The higher provisional amount is not an additional fine.

The no-appeal agreement also closes a common uncertainty. The current record does not support speculation about a pending appeal against this settled outcome.

Regulatory accountability is not identical to operational accountability. The ICO's role was to assess compliance with data-protection security obligations and impose the final penalty. The regulator did not operate NHS 111, restore Advanced products or run controller fallback processes.

The enforcement record nevertheless strengthens operational learning because it identifies deficiencies in measures under a formal evidential process. It converts parts of the incident from early allegation or explanation into regulatory findings. Those findings should be stated precisely, with the company's representations and settlement context kept in view.

What the ICO findings do and do not establish

The ICO findings establish that Advanced's technical and organisational measures were not appropriate in relevant respects under the regulator's analysis. The available materials identify access and vulnerability-management weaknesses within that broader conclusion.

They establish a final monetary penalty and the affected populations reported by the regulator. They establish Advanced's processor role and the voluntary settlement.

They do not establish that one control alone caused every consequence. Security incidents emerge through interacting technical and organisational conditions. The appropriate repair is therefore broader than installing one tool.

They do not establish a uniform clinical impact. The ICO's data-protection findings are not a clinical-outcome study.

They do not make every controller's circumstances identical. Controller systems, products, data and continuity arrangements differed.

They do not shift every responsibility to the processor. Controllers and public authorities retained their own duties, even though only Advanced could operate and restore the supplier environment.

This boundary matters because enforcement summaries can become shorthand. “The fine proves X” is often used to fill gaps that the penalty notice does not decide. The ICO record should be used for what it establishes, while operational unknowns remain visible.

Repair must be proven across four control layers

The first repair layer belongs to the supplier's security controls.

Access should be hardened according to the authority an account can exercise. A credential that can reach critical health-software infrastructure demands stronger protection, monitoring and recovery than an ordinary user account. Vulnerability management should connect known weaknesses to exposed assets, exploitation risk and remediation deadlines. Segmentation should limit how compromise of one system can reach others.

Repair need not prescribe a particular product. The evidence standard is whether Advanced can show that relevant access paths and vulnerabilities are controlled over time, not merely that a policy exists.

The second layer is restoration.

Backups should be recoverable into a trusted environment without relying on compromised administration. Restore tests should prove that applications, configuration and data work together. Recovery objectives should be measured by product and customer, because one aggregate target can hide a critical workflow that takes much longer.

The third layer is reconnection.

Advanced should be able to provide a customer-specific record of what was restored, what integrity checks passed, what data intervals need reconciliation and what monitoring remains in place. Controller organisations should have a defined acceptance process that includes operational and data-governance checks.

The fourth layer is continuity across the public service.

Controllers should maintain workable fallback procedures, local dependency inventories and ways to preserve actions taken while supplier software is unavailable. NHS and public authorities should be able to coordinate routing and prioritisation without assuming every local service has the same fallback capacity.

These layers need shared exercises. A supplier restore test that excludes customers may prove infrastructure but not reconnection. A controller tabletop that assumes the vendor can provide a clean system on demand may not test a prolonged supplier outage. A national exercise that treats “NHS 111” as one system may miss local and product variation.

Exercises should also distinguish availability and confidentiality. Entities should practice how to communicate when many services are unavailable but data exposure is confirmed only for a narrower set of systems. The Advanced numbers provide a clear model for that scenario.

Evidence should be durable. Incident timelines, access logs, vulnerability decisions, backup tests, restoration results, customer notices and reconnection approvals should remain available for investigation and improvement. If the evidence disappears with the service, accountability becomes reconstruction by memory.

Finally, repair should be tested after organisational and product changes. Health-software suppliers evolve through acquisitions, migrations, platform consolidation and product updates. A control that worked for one architecture may not remain effective after dependencies change.

The goal is not a promise that ransomware can never succeed. It is proof that access, vulnerability, restoration and continuity controls make the next incident harder to start, smaller in reach, faster to detect and safer to recover from.

What remains unknown

The public record does not provide one complete product-by-product outage and reconnection timeline. Some contemporary reports describe expected or observed recovery periods, but the final order for every customer is not established.

The record does not quantify direct clinical harm attributable to the incident. Deaths, injuries and national patient-outcome figures must not be inferred from software disruption.

The full initial access and attack sequence should not be reduced beyond the ICO's established findings. One missing control should not be declared the sole cause.

Controller-specific notification and remediation outcomes vary. The 658 availability population cannot be used as a universal data-exfiltration population, and the 16-controller exfiltration scope cannot be generalized without evidence.

A complete NHS after-action account is not available here. The effectiveness of every local workaround, routing decision and reconciliation process remains outside the established record.

These limits do not weaken the central case. They define what the evidence can responsibly support.

Accountability follows control over the dependency

Advanced's 2022 ransomware incident made a supplier-run healthcare workflow an accountability entity.

The supplier controlled access hardening, vulnerability management, infrastructure, restoration and product reconnection. Controller organisations controlled procurement, local continuity, data-governance decisions and acceptance of restored services. NHS and public authorities controlled wider coordination and routing. The ICO controlled the retrospective regulatory process.

The incident affected availability for 658 controller customers. Exfiltration involved systems used by 16 controllers and personal data relating to 79,404 people. Keeping those figures separate preserves the difference between operational continuity and confirmed data access.

The record supports serious disruption and sensitive-data compromise. It does not support invented deaths, uniform national downtime or a single-cause story.

The final GBP 3,076,320 penalty provides a formal accountability endpoint. It does not complete the operational repair. That requires evidence that supplier controls improved, backups restore, customers reconnect safely and public services can continue when one vendor's systems are unavailable.

In a distributed care system, responsibility can be shared without control being equal. The organisation able to change a control should be able to prove that change. The customer forced to depend on it should be able to test the evidence. Advanced made that exchange—not software availability alone—the measure of continuity.

Advanced made NHS 111 software dependency a care-continuity accountability test