Before You Sign: What Healthcare Companies Should Ask Their Cloud Provider

Before signing a cloud contract for a clinic, laboratory or healthcare platform, ask the supplier to walk through a difficult working day. A staff member cannot open a patient record, the application team suspects a database problem, and the cloud support team says its infrastructure is available. Who takes responsibility for getting the service working again?

That hypothetical situation is a useful procurement exercise. It forces a conversation about the service you need, the people who operate it and the evidence behind their commitments. This article explains how to turn that conversation into questions and written conditions before you sign.

The starting point is ENISA's July 2026 procurement guidance for hospitals and healthcare providers. ENISA, the EU cybersecurity agency, addresses security throughout procurement and includes dedicated cloud clauses covering matters such as data location, recovery and incident communication. We use that guidance below as a starting point for our own practical buying recommendations, rather than a universal contract template.

What Exactly Are We Buying, and Who Operates Each Part?

Ask the supplier to describe the proposed service using one real workflow from your organisation. For a laboratory, that might mean receiving a sample, processing a result and making it available to the referring clinician. Have your application supplier and internal IT lead join the discussion so that the answer covers the complete workflow.

Request a written responsibility table for the cloud infrastructure, database, application, staff accounts, backups and monitoring. For each part, name who configures it, who maintains it and who responds when it fails. Where a supplier writes "customer responsibility", assign an actual person or contracted team on your side before accepting the proposal.

Consider a hypothetical offer that includes a managed database but leaves application upgrades to the customer. Ask who checks that a database upgrade will still work with your clinical software, where that check happens and who can postpone the change. An answer such as "our platform handles upgrades" leaves your application compatibility question unresolved.

Keep the legal roles equally explicit. Under GDPR Article 28, an organisation deciding how personal data is used, the controller, must select processors offering sufficient safeguards and put the processing arrangement in a binding contract. A processor handles personal data on the controller's behalf.

Our recommendation is to finish this discussion with a short service description that both the operational lead and the contract reviewer can recognise. Include exclusions next to the relevant responsibility. Give the signing manager a clear account of the work your own team is agreeing to retain.

Where Can Patient Data Go, and Who Can Reach It?

Give the supplier a concrete request: draw the route taken by a fictional patient record through the proposed service. Include the working database, backup copies, diagnostic records and any support process that might receive patient information. Use invented data for the exercise.

Then ask for a separate explanation of administrative access. Which organisations can authorise access, from which countries, and for what tasks? Ask the supplier to demonstrate how a temporary support account is approved, limited, recorded and removed, using a test environment.

For example, suppose your contract promises storage in Germany. During the walkthrough, ask what happens when an engineer needs a diagnostic copy to investigate a fault, whether that copy includes patient information and where it would be handled. Have your privacy lead assess the proposed arrangement against your actual requirements before it becomes normal practice.

Request the names and functions of subprocessors, meaning other organisations engaged to process the data. GDPR Article 28 requires prior specific or general written authorisation for their use; under general authorisation, intended additions or replacements must be communicated so the controller can object.

Make that change process usable. Ask which inbox receives notices, who reviews them and what happens if a proposed arrangement is unacceptable. We recommend recording approved locations and access arrangements alongside the contract, with a named owner for reviewing changes.

What Evidence Supports the Service We Will Actually Use?

Ask suppliers to connect each assurance claim to the proposed configuration. Request the relevant certificate or assurance report, its scope, the services and entities covered, and any responsibilities assigned to customers. Give your reviewer access to the underlying evidence, under confidentiality terms where appropriate.

Turn the review into a small set of acceptance decisions. If the proposal includes restricted administrator access, request a demonstration with the permissions your team will receive. If it promises an activity record, ask your security lead to find a test administrator's actions and export the record without supplier assistance.

For a hypothetical patient portal, choose a few representative tasks: creating a staff account, removing access for a departing employee and investigating an unsuccessful sign-in. Have the people who will operate the system perform them. Record which tasks they can complete and which require additional access, training or supplier intervention.

There is a regulatory reason to examine supplier practices. For organisations within its scope, Article 21 of NIS2, the EU cybersecurity directive, includes supply-chain security and assessment of security measures among its requirements. Applicability needs checking against the organisation and relevant national law; a supplier's use of the term "NIS2-ready" should prompt a request for specifics.

Our suggested decision record has four fields: requirement, evidence, reviewer and unresolved condition. Separate items that must be resolved before signing from those that must pass before patient data enters the environment. This gives leadership a precise decision to make when a supplier has answered most, but not all, of the questions.

How Will We Restore the Clinical Workflow?

Ask for recovery commitments in terms your clinical or operational lead can assess. How long could the workflow be unavailable, and how much recent work could you accept losing? Agree those limits internally before asking a supplier to propose a recovery design.

GDPR Article 32 includes timely restoration of personal-data availability and regular testing among the measures to consider when providing security appropriate to risk. Your procurement exercise should turn that principle into a test of the service you intend to run.

For the laboratory example, we would propose a rehearsal that restores fictional results into an isolated environment. Ask staff to sign in, locate the results and verify that the application associates them with the correct fictional records. Measure elapsed time from the recovery decision to successful use, and document any manual steps.

Ask the supplier which parts of that rehearsal it will perform and which parts your application team must complete. Include a situation where the usual administrator is unavailable. Have a second authorised person follow the instructions and record where they need help.

Before signing, agree the recovery commitments, the test method and each party's participation. Before launch, require the agreed evidence and resolve failures against your acceptance criteria. Use the rehearsal to decide what staff should do while the digital service is unavailable, with the clinical lead owning that operational procedure.

What Happens During the First Hours of an Incident?

Run a discussion exercise with the proposed support contacts. Describe a suspected exposure of patient information on a weekend and ask who receives the first message, who joins the investigation and how your organisation gets updates. Repeat the exercise for an outage where no data exposure is suspected.

Keep the contractual notification language precise. GDPR Article 33 requires processors to notify controllers of a personal data breach without undue delay after becoming aware of it. The controller's separate regulatory reporting timetable is not a general allowance for suppliers to wait before telling you.

We recommend asking for an initial incident message containing the affected service, known impact, immediate actions, contact person and time of the next update. Allow the supplier to distinguish confirmed facts from ongoing investigation. Agree how corrections and additional evidence will reach your incident lead.

Test your side of the arrangement too. If the supplier calls the designated number outside office hours, who answers and what can that person authorise? Record the route for involving your privacy lead, clinical operations and application supplier without depending on one employee being available.

How Will We Leave, and Who Reviews Changes Until Then?

Bring the end of the relationship into the buying discussion. ENISA's cloud procurement measures include defining exit triggers and incorporating an exit or migration strategy into planning. Ask the supplier how its proposed terms support the situations that matter to your organisation.

Our practical recommendation is a sample export exercise before committing to the service. Use fictional records with attachments, dates and access permissions, then ask your application team to inspect the output in a separate environment. Record what transfers successfully, what needs reconstruction and which supplier assistance is required.

Agree who owns the migration instructions and who checks that the receiving service is usable before the original is withdrawn. Ask for the proposed handling of remaining copies, including backups, and have your privacy lead confirm the appropriate retention and deletion conditions. Schedule a review whenever the application or storage arrangement changes materially.

End the procurement process with a decision document short enough for leadership to read. It should identify the service being bought, the responsibilities retained internally, the evidence reviewed and the conditions still outstanding. Give each outstanding condition an owner and a date, and make clear which ones prevent signing or launch.

For your next supplier meeting, bring one clinical workflow and the people accountable for keeping it available. Ask the supplier to work through these questions using that example, then put the agreed answers into the contract and acceptance plan. That gives your team something concrete to operate, review and test throughout the relationship.

Thinking about migration? Book a free consultation to discuss your situation.