Anyone responsible for IT security in a hospital knows the situation: a clinical department or hospital management wants to introduce a new cloud solution. The vendor’s sales documents are professionally designed. ISO 27001 appears somewhere — sometimes as a logo, sometimes as a sentence. What this means in concrete terms remains unclear. And the questions that actually matter — Where is patient data processed? Are there transfers to third countries? What does client separation look like? — often remain unanswered.

This article is aimed at hospital IT managers and data protection officers who are evaluating cloud software for preoperative patient intake. It explains what lies behind the certification terms, names specific points to check — and discloses where medudoc stands today.

Health data is not ordinary data

Preoperative patient intake systematically records information classified under Art. 9 GDPR as special categories of personal data: medical history, pre-existing conditions, medication lists, risk factors, allergies, informed consent to the procedure. This means a restriction of the permissible legal bases for processing, higher requirements for technical and organisational measures (TOMs) under Art. 32 GDPR and, as a rule, the obligation to carry out a data protection impact assessment (DPIA) under Art. 35 GDPR.

A software vendor that processes this data on behalf of your hospital acts as a processor within the meaning of Art. 28 GDPR. The hospital remains the controller. In practice, this means that if the processor does not work carefully, the hospital bears the consequences in a liability case — towards the supervisory authority and towards the patients affected. Care in selecting a vendor is therefore not a bureaucratic duty but a concrete instrument for managing risk.

What ISO 27001 actually says — and what it does not

ISO/IEC 27001 is the international standard for information security management systems (ISMS). A valid certification means that an accredited external auditor has confirmed that the company operates a systematic framework to identify, evaluate, treat and continuously improve information security risks — and that this framework is documented and regularly reviewed.

What ISO 27001 does not mean: that no security incidents can occur, that all conceivable risks have been eliminated, or that the certificate automatically applies to all of the company’s products and services. The scope is decisive.

Specific points to check when selecting a vendor:

  • Is there a valid ISO 27001 certificate, issued by a certification body accredited by DAkkS or an equivalent accreditation body?
  • Does the scope explicitly cover development, operation and the processing of patient-related data — or only part of the company?
  • When was the certificate issued, and until when is it valid? ISO 27001 certificates are limited to three years and require annual surveillance audits.

An ISO 27001 logo that refers to a five-year-old certificate with a restricted scope is of no value for your risk assessment.

BSI C5 — the cloud-specific security benchmark

The BSI Cloud Computing Compliance Criteria Catalogue (BSI C5) was developed by the German Federal Office for Information Security (BSI) and specifically addresses the requirements for cloud services. It is therefore more directly applicable than ISO 27001 alone to the question of how secure a cloud service is for clinical use.

BSI C5 distinguishes between two types of audit:

  • Type 1: an audit of the suitability of the security controls as of a defined reference date. It documents whether the controls are in place and suitably designed.
  • Type 2: an audit of the operating effectiveness of the controls over an observation period (according to the BSI, three to twelve months). This type is considerably more meaningful as evidence of operational security — it shows whether the controls not only exist but actually work.

Among other things, BSI C5 audits organisational security, asset management, physical security, cryptography, access control, incident management, business continuity and — particularly relevant for hospital procurement — full transparency about sub-service providers and sub-processing chains.

A common pattern in vendor documents is the statement that BSI C5 is “being sought” or “in preparation”. This is not a negative sign per se — C5 audits are demanding. The relevant question is: is a specific, commissioned audit under way? And if so, for which period and with which audit firm? These questions should be answered in writing.

Five questions every hospital IT department should ask

Regardless of which cloud solution is being evaluated for preoperative patient intake, these five questions should be answered in writing before the contract is signed:

1. Where is patient data processed?

In the European Economic Area or in a third country? Are there sub-service providers outside the EU — for example for AI-supported processing steps, analytics or support services? Transfers to third countries are possible under the GDPR, but only subject to stricter requirements (standard contractual clauses or an adequacy decision).

2. How is client separation implemented?

Do several hospital customers of a vendor share the same database layers, or is your hospital’s patient data technically strictly separated from other clients? This question determines whether a security incident at another hospital can affect your own data — and whether configuration errors by another client can affect your instance.

3. Which TOMs are documented and verifiable?

Art. 32 GDPR requires appropriate technical and organisational measures. Specifically, this means: how is data at rest encrypted? Which transport encryption standard is used? How are access rights governed and documented? How are activities logged and made analysable for audits? A reputable vendor provides structured TOMs documentation without any particular effort.

4. Is there a complete data processing agreement under Art. 28 GDPR?

Does the data processing agreement (DPA) reflect the current state of the GDPR? Does it contain a complete, up-to-date list of the sub-processors used? Does it govern the procedure for data breaches, including the notification obligation under Art. 33 GDPR? The DPA template should be available before the pilot phase, not only after go-live.

5. How is a security incident handled?

What documented process does the vendor have for detecting, classifying and reporting data breaches? Who is your contact person, and within what time frame will you be informed? Which recovery objectives (RTO, RPO) are contractually guaranteed? And has this process been reviewed as part of an external audit?

What hospitals rightly demand

In procurement discussions with hospitals, I find that these questions are being asked with increasing precision — and rightly so. GDPR compliance is a given today, not a differentiator. What hospital IT managers and data protection officers rightly demand is evidence: an existing certificate with a clearly defined scope, a DPA template that is legally robust, and honest information about what is still being built and what is already available for review.

Vendors that can answer these questions specifically — with documented evidence — make your procurement work more efficient and reduce your residual risk.

Information on medudoc’s security standards and certifications and the DPA template are available in the Trust Center at trust.medudoc.com.

Where medudoc stands today

medudoc has been certified to ISO/IEC 27001:2022 since April 2026. The scope covers development, operation, maintenance and distribution of the medudoc platform, including the processing of patient-related data. The certificate is valid until March 2029. It can be viewed and downloaded at trust.medudoc.com.

In addition, medudoc has been fully audited against BSI C5 (Type 1 and Type 2) by an appointed audit firm.

Patient data is processed exclusively in Germany. AI-supported processing steps remain within the EU. There are no transfers to third countries.

We continuously update the current status of all quality and security standards.

Conclusion

In the procurement process for clinical cloud software, IT security and data protection are not a downstream topic — they belong in the first round of the evaluation.

The five points to check in this article — data storage location, client separation, TOMs, DPA and incident management — are not an exhaustive checklist, but a reliable starting point for every procurement discussion.

If you are evaluating the digital preoperative workflow for your hospital and have specific questions about security architecture, certification status or the DPA, contact us directly: Request a demo.