A modern hospital rarely runs fewer than a hundred external software and infrastructure suppliers: the hospital information system (HIS), the laboratory information system (LIS), the radiology PACS, medication software, the patient portal, cloud backups, the remote-maintenance access of medical-device manufacturers, billing service providers and dozens of SaaS tools. Each of these suppliers is a potential entry vector, and at the same time a single point of failure. The largest healthcare cyber incidents of recent years were rarely a direct attack on the hospital itself; they traced back to a compromised service provider, a vulnerable third-party system, or a cloud provider whose outage paralysed clinical operations.

Supply-chain and third-party risk is therefore the biggest blind spot in many healthcare organisations' risk management. It is at the same time an explicit regulatory obligation, through Art. 21(2)(d) NIS2, through Art. 9 nDSG and Art. 28 GDPR for data processing, and through the ISO/IEC 27001:2022 controls A.5.19 to A.5.23.

This article covers:

• Why cloud, EHR and MedTech suppliers are legally part of your own liability.
• How vendor due diligence is structured before signing.
• How risk tiering governs the depth of review.
• Which contractual controls and DPA building blocks are mandatory.
• How supplier management is embedded into the ISMS (A.5.19–A.5.23).
• How a Trusted-Third-Party escrow secures continuity when a critical software supplier fails.
• How a vCISO takes over ongoing vendor monitoring.

Outsourcing a function never outsources the responsibility. In healthcare this holds in three respects. First, in data-protection terms: a hospital or practice that lets patient data be processed by a cloud, HIS or billing provider remains the controller within the meaning of Art. 5(j) nDSG and Art. 4(7) GDPR. The duty of data security under Art. 8 nDSG and Art. 32 GDPR stays with the principal. A security failure by the provider is legally your failure.

Second, in cybersecurity terms: where a hospital falls within the scope of the NIS2 Directive (Directive EU 2022/2555) through an EU establishment or EU operations, Art. 21(2)(d) expressly requires "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers". NIS2 is an EU directive that Switzerland has not transposed; it does not directly bind Swiss-only hospitals. For those, the Information Security Act (ISG) applies instead, with the reporting duty to the BACS. The two regimes must be kept cleanly distinct.

Third, operationally: an outage of the HIS or PACS halts clinical operations, with immediate patient-safety relevance. Third-party risk is therefore not only a compliance matter but a continuity-of-care matter.

Supplier due diligence ideally happens before the signature, not after the first incident. For health data, a tiered review programme is advisable:

• Security evidence: ISO/IEC 27001:2022 certificate (checking the Statement of Applicability and the scope), SOC 2 Type II report or C5 attestation. Important: a supplier's certificate evidences the supplier's maturity. It does not certify your own ISMS.
• Data residency: where is patient data stored and processed? Is there a cross-border transfer (Art. 16 f. nDSG), and is there an adequate level of protection or an appropriate safeguard?
• Sub-outsourcing: which sub-processors does the supplier use (hyperscalers, support partners, remote maintenance)? Every sub-processor extends the chain.
• Vulnerability management: patch process, penetration-test reports, coordinated disclosure under ISO/IEC 29147 and, for products, a software bill of materials (SBOM) in CycloneDX or SPDX format.
• Operational stability: financial soundness, RTO/RPO, business-continuity plan, exit and data-return concept.

Self-declarations alone (completed vendor-security questionnaires without external verification) no longer suffice for critical health suppliers. Demand objective evidence and document the assessment. The documentation is part of your accountability.

You cannot review a hundred suppliers to the same depth. Risk tiering steers the effort according to criticality. A proven three-tier model for healthcare organisations:

• Tier 1 – critical: suppliers whose failure immediately halts clinical operations, or who have direct access to large volumes of sensitive health data (HIS, LIS, PACS, EHR connection, primary cloud platform). Full due diligence, annual audit or evidence review, continuity provision (escrow), strict contractual controls.
• Tier 2 – significant: suppliers with access to patient data but without immediate operational shutdown on failure (billing, patient portal, specialised clinical software). Standardised due diligence, periodic evidence review.
• Tier 3 – supporting: suppliers with no access to patient data and no clinical-operations relevance (facility, general office tools). Lightweight review, self-assessment sufficient.

The classification should combine at least two axes: data-protection sensitivity (which and how much health data) and operational criticality (what care consequences an outage would have). The tiering is documented in the supplier register and reviewed at least annually, in particular whenever a supplier takes on new data categories or functions.

The contract is the most important steering instrument for third-party risk. For health suppliers, two contractual layers must be kept clearly separate: the data-processing agreement (DPA) under Art. 9 nDSG and Art. 28 GDPR, and the general security and service-level clauses.

Under Art. 9 nDSG the DPA must in particular provide that the processor acts only on instruction, ensures data security under Art. 8 nDSG, engages sub-processors only with authorisation, and returns or deletes the data at the end of the engagement. Under Art. 28 GDPR, for EU-affected processing further mandatory contents apply (support with data-subject rights, with DPIAs, with breach-notification duties). A NIS2 or general supplier contract is not automatically a valid DPA. The two must be modelled separately.

In addition, the contract should contain: incident-notification deadlines with a clearly defined notion of a reportable incident, an audit or inspection right (or the right to engage an independent third party), patch and vulnerability SLAs, sub-outsourcing authorisation including an identical flow-down obligation, encryption and access requirements, and exit clauses with data return, secure deletion and migration support. Do not accept standard contracts unchecked. Your own clause library with standard positions creates negotiating certainty.

Supplier management is not a one-off project but an ongoing ISMS process. ISO/IEC 27001:2022 maps third-party risk across five connected controls:

• A.5.19 – Information security in supplier relationships: the underlying processes and policies for handling risks arising from supplier relationships.
• A.5.20 – Addressing information security within supplier agreements: contractual anchoring of the security requirements, the direct bridge to the DPA and the security clauses.
• A.5.21 – Managing information security in the ICT supply chain: steering the whole chain, including sub-suppliers and component provenance (SBOM).
• A.5.22 – Monitoring, review and change management of supplier services: the ongoing monitoring, evidence reviews, SLA control, response to changes at the supplier.
• A.5.23 – Information security for use of cloud services: the control that is central to EHR and cloud scenarios, responsibility demarcation, data residency, exit.

An organisation that operationalises these controls simultaneously meets the core of the NIS2 supply-chain requirements and the nDSG data-processing duties. The supplier register, the tiering, the due-diligence dossiers and the contract control matrix are the demonstrable artefacts an auditor wants to see.

The most severe third-party risk is not data leakage but the total failure of a critical software supplier: insolvency, business closure, acquisition with product discontinuation, or an escalated contractual dispute. If the HIS or a specialised clinical module suddenly stands without vendor support, continuity of care is at risk.

A software and data escrow through a Trusted Third Party addresses exactly this scenario. At a neutral deposit agent, source code, build instructions, documentation and, in the extended model, current data exports are deposited. Defined release events (insolvency, withdrawal of support, breach of contract) give the hospital governed access to continue operations with a third-party partner or to perform an orderly migration. Verification is decisive: a deposit that has never been checked for completeness and buildability is worthless when it matters.

SIDD offers a fiduciary role for health data and critical health software: we design the escrow and continuity model, define the release events and access rights, and set up the periodic verification of the deposit. More at Trusted Third Party. The service is a fixed-price module; the terms are clarified on request after a scoping.

SIDD builds an end-to-end third-party risk programme for healthcare organisations: from the supplier register with risk tiering, through the due-diligence dossiers and the DPA and contract-control library, to anchoring in the ISMS under controls A.5.19–A.5.23. In doing so we combine legal depth (Art. 8 and 9 nDSG, Art. 28 and 32 GDPR, NIS2 supply-chain logic, ISG/BACS) with technical review capability: penetration tests and vulnerability scans serve as objective evidence, see ISMS & ISO 27001 and penetration testing.

So that supplier management does not fall dormant after the project, our external CISO/ISB takes over the ongoing vendor monitoring: periodic evidence reviews, SLA and patch control, re-tiering on changes, maintenance of the register, and preparation of supplier-audit evidence. More at external CISO/ISB. Where a SIDD lawyer advises in a legal capacity, your disclosures may be subject to professional secrecy under Art. 321 of the Swiss Criminal Code.

Write to us via /kontakt for a no-obligation initial discussion, or request a tailored proposal at /offerte. For clearly scoped modules, supplier register, DPA library, escrow setup, you receive a written quote with fixed-price options after a scoping call.