Your supplier is part of your attack surface

Evidence: third parties already feature in care incidents

One third of respondents in the DHSC study said they had experienced a cyber incident or unsuccessful attack in the previous three years. Among that subgroup, 44% said the attack originated from a third-party organisation, while 21% said it originated within the provider's own systems. The same research recorded concerns about limited cyber-risk information from some technology suppliers and limited ongoing monitoring after contracts were signed.

Those figures do not establish that a supplier was negligent, and the study did not independently verify each reported origin. They do establish a material dependency pattern: a provider can experience disruption without being the point at which compromise began. That changes the control question from 'Are our own systems secure?' to 'Which external failure could reach our data, operations or people?'

Analysis: classify suppliers by consequence, not category

A universal questionnaire for every supplier wastes effort and can hide the relationships that need scrutiny. A more useful first pass asks whether loss or compromise could affect safe care, access to current information, medicines, workforce deployment, confidential data, payments, communications or the provider's ability to operate. A payroll bureau, building-system maintainer or external HR service may be cyber-critical even if it is not sold as a technology product.

Criticality should reflect both impact and speed. A service that can be unavailable for a week with a simple workaround is different from an electronic medicines system needed at the next round. Privileged access also raises consequence: a managed IT supplier that administers identities, devices, email and backups occupies a different risk position from a supplier that receives a monthly file.

The useful question is not whether a supplier is reputable. It is what that supplier can reach, what care depends on it and what happens when it fails.

Practice: build a dependency map that can support a decision

NCSC guidance recommends recording who suppliers are, what they provide, how they provide it, the information flows involved, the importance of the asset, assurance contacts, assessment dates and relevant certifications. For a care provider, the register should also identify locations and care processes dependent on the service, remote or privileged access, recovery commitments, emergency contacts and the route for obtaining usable data if the live platform is unavailable.

The map does not need to trace every software library on day one. NCSC guidance supports a proportionate approach: capture direct suppliers first, determine criticality, then seek visibility further down the chain where subcontractors or shared platforms could create concentration risk. Protect the register itself; detailed access and dependency information would be useful to an attacker.

Legal baseline: make the data-processing contract operational

Where a care provider is a controller and a supplier processes personal data on its behalf, Article 28 contract requirements matter. ICO guidance says the contract must cover appropriate security, sub-processors, assistance with breach obligations, end-of-contract deletion or return, and audits and inspections. It must also require the processor to make available the information needed to demonstrate compliance. These are legal data-protection terms, not a complete care-continuity specification.

The operational schedule should remove ambiguity before an incident: who notifies whom; through which channel if email is unavailable; what severity triggers contact; whether updates continue out of hours; which minimum service or emergency export is available; how recovery priorities are set; how remote access is logged; and how data will be returned in a usable format at exit. Times should reflect the provider's need to act, not merely a generic service desk target.

Contract rights are valuable only if they can be exercised. Named contacts, an out-of-band communication route and a current copy of the relevant schedule should be accessible when the normal system is down.

Assurance: ask for evidence without demanding the impossible

Certifications, penetration-test summaries and security questionnaires can all contribute evidence. None answers every operational question. Check that a certification's scope covers the service being bought; ask how critical findings are remediated; establish when recovery was last exercised; understand how privileged and remote access is restricted and monitored; and ask how the supplier assures the critical organisations on which its own service depends.

This should remain proportionate and collaborative. A small provider cannot audit a major cloud platform line by line, while a small supplier should not face an enterprise-sized evidence demand for a low-consequence service. NCSC supplier-assurance guidance supports matching scrutiny to risk and monitoring changes in supplier information risk over time. Revisit the review when the service, data volume, ownership, subcontractors or provider dependency changes. A useful supplier response is specific about scope, evidence and limitations rather than promising that an incident can never happen.

Continuity: separate supplier recovery from care continuity

The supplier may own technical containment and platform recovery. The care provider still owns decisions about safe staffing, medicines, temporary records, escalation and communication while the service is unavailable. Waiting for a supplier status page is not a continuity plan, particularly in a one-to-many incident when many customers may be calling the same helpdesk.

Run a joint scenario around one critical service. Start with a plausible notification that the platform is unavailable, data impact is not yet known and no restoration time can be given. Test whether staff can find current contingency information, record decisions, operate safely through the next high-consequence activity, receive authenticated updates and reconcile temporary records after restoration. Capture what failed and assign actions to both parties.

Policy watch: supplier transparency is moving up the national agenda

As at 27 August 2026, the Cyber Security and Resilience (Network and Information Systems) Bill was in House of Lords committee stage. It was not an Act. Government proposals include bringing qualifying managed service providers into the NIS regime, a two-stage 24-hour and 72-hour incident-reporting model for regulated entities, and customer notification by relevant digital and managed service providers where customers are likely to have been affected. The detail would require passage and, for many measures, later secondary legislation.

Most care providers should not read those proposals as duties that already apply to them. The practical interpretation is narrower: rapid, usable supplier communication is now recognised as a systemic resilience issue. Providers can improve contractual notification and rehearse customer-side decisions now, without claiming that proposed law is in force.