NHS organisations should treat supply chain security as a procurement and assurance problem, not only a technical one. The first step is to verify supplier claims, test systems in an environment that matches local conditions, and set controls according to criticality. High-risk clinical systems need stronger checks, while low-risk informational services can use lighter assurance. Business continuity planning should be built in from the start.
How to reduce supply chain risk before go-live
Before a new system goes live, the key is to move from vendor assurances to evidence. NHS teams should validate what the supplier says the system can do, test it in conditions that resemble the local estate, and calibrate assurance to the clinical and operational criticality of the service. That is where hidden integration, resilience, and support gaps usually surface.
A useful way to think about this is that procurement, technical validation, and operational readiness are one control chain. If any link is weak, the go-live decision becomes a gamble on assumptions rather than a managed risk decision. For NHS organisations, the practical question is not whether the supplier is reputable, but whether the delivered service is fit for the specific environment it will enter.
Testing should therefore include the interfaces, dependencies, and failure modes that matter locally. A system can look secure in a demo or generic assurance pack and still fail once it meets NHS identity services, network constraints, data flows, support arrangements, or business continuity requirements. The stronger the system’s clinical impact, the less tolerance there should be for unresolved ambiguity.
What “good assurance” looks like in practice
Good assurance starts with evidence that is specific to the deployment, not just to the product. That means checking supplier claims against documented architecture, support boundaries, patching and escalation arrangements, and any third-party dependencies that could affect availability or integrity. It also means understanding whether the supplier’s controls still hold when the system is configured for your environment rather than a reference environment.
Local testing should be proportionate to the system’s risk. High-risk clinical systems warrant stronger assurance because defects can affect patient safety, service continuity, and incident recovery. Lower-risk informational services may justify lighter assurance, but they still need enough validation to prevent a hidden dependency from becoming a live failure after cutover. The objective is to distinguish acceptable residual risk from avoidable uncertainty.
Business continuity planning belongs in the pre-live stage, not after deployment. If a supplier service fails, degrades, or loses connectivity, the organisation should already know what manual workaround, fallback process, or escalation path will be used. That planning is part of supply chain risk reduction because resilience often depends on the weakest external dependency, not the system’s own code.
Which controls should shape the go-live decision
Use the procurement and assurance process to set the control depth. High-criticality systems should trigger stronger evidence requirements, more realistic testing, and clearer exit criteria before approval. Lower-criticality systems can be accepted with a lighter control set, but the decision should still be explicit so that “low risk” is not just shorthand for “less examined.”
Where supplier claims depend on third-party components, services, or update channels, ask who is accountable when one of those dependencies changes. Supply chain risk is often introduced by hidden relationships, such as outsourced support, shared hosting, managed updates, or subcontracted development. The go-live decision should therefore be based on the full delivery chain, not only the named prime supplier.
For teams needing a security-control lens, this is the point to align procurement evidence with recognised controls such as NIST SSDF (SP 800-218), SLSA, and the OpenSSF ecosystem for software integrity and supplier assurance, alongside broader operational controls in NIST SP 800-53 Rev 5 Security and Privacy Controls.
Risk and Threat Considerations
Supply chain risk before go-live is usually less about a single malicious event and more about untested assumptions. A supplier may overstate resilience, omit a dependency, or provide controls that work in theory but not in the local NHS environment. The result can be service failure, insecure integration, or a control gap that only appears under operational pressure.
Failure mechanism: The organisation accepts vendor claims without verifying deployment-specific behaviour, so hidden dependencies, weak recovery paths, or insecure defaults survive into production.
Impact: A live service can fail at cutover, expose patient-facing or operational disruption, or require emergency workarounds that are slower and less secure than planned operations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8, NIST CSF 2.0 and SLSA set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Covers supplier assurance and acquisition risk for systems before deployment. |
| CP-2 — Contingency Plan | Supports pre-live continuity planning for supplier or service failure. | |
| SA-15 — Development Process, Standards, and Tools | Supports verifying that delivered systems were built and handled with controlled engineering practices. | |
| Recommendation — Require supplier evidence and verify external dependencies before approving go-live. Define fallback and recovery paths before the system enters production. Confirm the supplier’s engineering and release controls before accepting delivery. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Directly addresses supplier risk, assurance, and ongoing oversight before go-live. |
| CIS-17 — Incident Response Management | Relevant because go-live planning must include response paths if the supply chain fails. | |
| Recommendation — Assess service-provider controls and contractually enforce evidence before activation. Test escalation and incident handling with supplier dependencies before launch. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Directly governs supplier assurance and control expectations in sourcing and delivery. |
| A.5.30 — ICT readiness for business continuity | Supports continuity planning for supplier or system failure at cutover. | |
| Recommendation — Set security requirements and evidence gates in supplier relationships before go-live. Validate continuity arrangements and recovery options before production approval. | ||
| NIST CSF 2.0 | GV.SC-01 — Supply Chain Risk Management Strategy | Applies to governing supply-chain risk as part of system acquisition and deployment. |
| RC.RP-01 — Recovery Plan Execution | Supports readiness to recover when a supplied system or dependency fails after launch. | |
| Recommendation — Embed supply-chain risk criteria into the go-live governance decision. Confirm recovery actions and fallback ownership before cutover. | ||
| SLSA | Supply-chain Levels for Software Artifacts | Relevant to software integrity and provenance checking before deployment. |
| Recommendation — Use provenance and integrity checks to reduce release-chain risk. | ||
Practitioner Guidance
What to prioritise: Prioritise the systems whose failure would create patient-safety impact, service interruption, or complex recovery. Those systems deserve the strongest pre-live evidence, the most realistic testing, and the clearest go/no-go criteria.
What to verify: Verify the supplier’s claims against the actual NHS deployment pattern, not a generic reference installation. If the evidence does not show how the system behaves under local constraints, treat the assurance as incomplete rather than “good enough.”
Decision rule: If a dependency is outside your direct control and would be hard to replace quickly, treat it as part of the go-live risk decision, not as a post-live operational issue. That is especially important where the system supports clinical workflows or critical business continuity.
Practitioner takeaway: The safest go-live decisions are made when procurement, testing, and continuity planning are treated as one assurance process, because supply chain risk becomes real only when the system meets the local environment.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
