Insights  /  Regulatory
Digital Health · Data security

Data security for digital health: GDPR & BSI

Germany's data-protection and data-security bar is high and rising — and for a non-EU digital-health company it's usually the hardest, most underestimated hurdle. It's not one rule but a stack, and it gates your DiGA listing regardless of how good the clinical evidence is.

9 min read Reviewed by Ralf Müller, Market Access & Regulatory Lead Updated 2026
In one paragraph

Health data is a special category under the GDPR, tightened further by Germany's BDSG and health-sector rules that push processing onto German / EU soil. On top of that, a DiGA must clear a defined data-security bar — BfArM requirements plus a BSI security certificate (based on the technical guideline BSI TR-03161), typically backed by an information-security management system (ISO/IEC 27001) and, for cloud, the BSI C5 criteria. It's a layered programme, not a checkbox — and it gates the listing.

Data security is a gate, not a checkbox

For most software, security is a quality attribute. For digital health in Germany, it's a pass/fail condition of market access.

A DiGA can have excellent clinical evidence and still fail to list if the data-security programme isn't certified. For any health product — app, device software, platform — data protection is also decisive in hospital and payer procurement. Non-EU teams routinely underestimate this because the bar is higher, more formal, and more German-specific than in their home market.

The clinical study proves it works. The security certificate proves you're allowed to run it here.

The compliance stack

Five layers, each built on the one below

You don't pick one of these — you satisfy all of them, bottom to top. The top layer is what actually gates a DiGA listing, but it only holds if the foundation is solid.

L1
GDPR baseline Health data is a special category (Art 9); needs a strong legal basis, DPIA, and a DPO where thresholds are met.
L2
German BDSG layer The federal data-protection act supplements the GDPR with German specifics and stricter conditions for health data.
L3
Health-data localisation Social-law rules (SGB V) push processing of DiGA health data onto German / EU / EEA soil, with tight limits elsewhere.
L4
ISMS & cloud criteria An information-security management system (ISO/IEC 27001) and, for cloud hosting, the BSI C5 catalogue.
L5
BSI security certificate The DiGA-specific bar: BfArM requirements + a BSI certificate based on BSI TR-03161. This is what gates the listing.

Build bottom-up. Teams that start at L5 without L1–L4 in place stall — the certificate can't be issued on shaky foundations.

GDPR: health data is special

Health data isn't ordinary personal data. Under the GDPR (Regulation (EU) 2016/679), it's a special category (Art 9) — processing is prohibited unless a specific condition applies, and it demands extra safeguards.

  • Lawful basis + Art 9 condition. You need both a general legal basis and a special-category condition (e.g. explicit consent, or a health-provision basis).
  • DPIA. Large-scale processing of health data typically requires a Data Protection Impact Assessment before you launch.
  • DPO. A Data Protection Officer (Datenschutzbeauftragter) is required where core activities involve large-scale special-category processing.
  • Data-subject rights & breach reporting. Access, deletion, portability, and 72-hour breach notification all apply, sharply, to health data.

The DiGA security bar (BSI)

For a DiGA, data security isn't just GDPR compliance — it's a certified, product-specific programme verified before listing.

The requirement

BfArM + BSI certificate

Alongside BfArM's data-protection and security requirements, a DiGA must hold a security certificate issued on the basis of the technical guideline BSI TR-03161 — a hard prerequisite for listing.

What underpins it

ISMS, ISO 27001, C5

Certification rests on a functioning information-security management system (commonly ISO/IEC 27001) and, where you host in the cloud, alignment with the BSI C5 criteria for cloud providers.

None of this is fast to retrofit. It's the reason we tell digital-health entrants to start the security workstream first: it gates the listing regardless of how strong the clinical evidence is, and it has the longest lead time.

Where companies go wrong

  • Starting the security programme last. It has the longest lead time and gates the listing — it should start first.
  • Assuming home-market compliance transfers. HIPAA or a home-country certificate does not equal GDPR + BSI + BfArM.
  • Hosting wherever is cheapest. Data localisation and transfer rules can force EU / German hosting — plan the architecture around it.
  • Treating certification as a document. It rests on a live ISMS with named roles and evidence, not a one-time audit.
RM
Reviewed by Ralf Müller
Market Access & Regulatory Lead · 15 years in German healthcare
Building a DiGA or health platform?

We map the security path — and the specialists to certify it.

In a focused session we outline the full stack for your product — GDPR, German rules, hosting, the BSI certificate path — sequence it so it doesn't block your listing, and connect you to the right certification partners.