HealthTech companies operate at the point where healthcare, software, and data protection law all overlap, and that overlap is precisely what makes compliance hard. A typical HealthTech scale-up has to satisfy GDPR because it processes patient data, ISO 27001 or NIS2 because it runs infrastructure that healthcare providers depend on, and often a device regulation on top of that if its software supports a diagnosis or treatment decision. None of these frameworks were written with the others in mind, so the overlap has to be managed by the company, not by the regulation.
This article works through what actually applies to a HealthTech company, why handling each framework separately burns through security and compliance capacity, and what a more automated, unified approach to HealthTech compliance looks like in practice.
Key takeaways
- Health data counts as a "special category" of personal data under Article 9 GDPR, which means HealthTech companies face stricter legal-basis, consent, and documentation requirements than most other sectors, on top of standard GDPR compliance.
- NIS2 classifies healthcare providers, EU reference laboratories, and companies that carry out research and development on medicinal products as entities in scope, so most HealthTech companies serving patients or health systems fall under the directive, not just hospitals.
- Medical device software can trigger MDR (Regulation (EU) 2017/745, fully applicable since May 2021) or IVDR (Regulation (EU) 2017/746, fully applicable since May 2022), each with its own conformity assessment separate from ISO 27001 or GDPR.
- The European Health Data Space Regulation (EU) 2025/327 entered into force in 2025 and phases in obligations for electronic health record systems and secondary data use through the early 2030s, adding a fourth compliance track for many HealthTech vendors.
- ISO 27001’s 2022 revision sets out 93 Annex A controls across four categories, and most HealthTech companies end up implementing 60 to 80 of them once ISO 27001, GDPR, and NIS2 requirements are mapped against each other.
Data protection requirements: why health data gets stricter rules
GDPR is the foundation, and health data gets treated differently from the start. Article 9 GDPR classifies health data as a special category of personal data, which means processing it requires both a standard legal basis under Article 6 and one of the narrower exceptions listed in Article 9(2), such as explicit consent or a legal obligation related to healthcare provision.
In practice, that shows up as several concrete obligations layered on top of ordinary GDPR compliance: a documented legal basis for every processing activity involving health data, consent flows that meet the higher bar for explicit consent where consent is the basis relied on, a Data Protection Impact Assessment for most new health-data processing under Article 35, since it is likely to result in high risk to individuals, and audit trails detailed enough to show a regulator or an auditor exactly who accessed which record and why.
A common misconception is that anonymizing or pseudonymizing health data removes it from GDPR’s scope entirely. Pseudonymized data, where a key or additional information could re-identify the individual, still counts as personal data under GDPR and still falls under Article 9 if it relates to health. Only genuinely anonymized data, where re-identification is not reasonably possible, sits outside the regulation.
Information security standards: ISO 27001, NIS2, and where they meet
Most HealthTech companies end up building an information security management system regardless of whether a regulator requires it, because healthcare customers and hospital procurement teams increasingly ask for it during due diligence. ISO 27001 certification covers this ground directly: the 2022 revision sets out 93 controls across four categories, 37 organizational, 8 people, 14 physical, and 34 technological, and gives HealthTech companies a structured way to demonstrate that patient data is protected by design, not just by policy.
NIS2 adds a second layer that is easy to underestimate. The directive’s Annex I lists healthcare among the sectors of high criticality, and its scope reaches beyond hospitals to healthcare providers, EU reference laboratories, and organizations carrying out research and development activities on medicinal products. A HealthTech company that operates infrastructure a hospital or clinic relies on for care delivery can fall into scope even if it never treats a patient directly. Our NIS2 requirements guide covers the classification test and the resulting obligations in detail.
ISO 27701, the privacy extension to ISO 27001, and ISO 27799, the health-sector-specific information security standard, both build on the same Annex A control base, which is exactly why mapping controls once across frameworks rather than rebuilding them per standard saves the most time for HealthTech teams specifically.
Healthcare-specific regulations: MDR, IVDR, and the EHDS
Beyond general security and data protection law, a HealthTech company whose software supports a diagnosis, prevention, monitoring, or treatment decision may fall under the Medical Device Regulation, Regulation (EU) 2017/745, which has applied in full since 26 May 2021, or the In Vitro Diagnostic Regulation, Regulation (EU) 2017/746, fully applicable since 26 May 2022. Software classified as a medical device needs a CE mark, a quality management system, and a conformity assessment involving a notified body for higher-risk classes, an entirely separate track from ISO 27001 or GDPR compliance.
The newest addition is the European Health Data Space, established by Regulation (EU) 2025/327, which entered into force in 2025. The EHDS creates EU-wide rules for patients accessing and sharing their electronic health data, and for the secondary use of health data for research and public health purposes, with obligations for electronic health record system providers phasing in over the following years. HealthTech vendors building patient portals, EHR systems, or health data platforms should expect EHDS conformity requirements to become a fourth compliance track alongside GDPR, NIS2, and any applicable device regulation.
National healthcare rules add a further layer that varies by member state: Germany’s Digitale-Gesundheitsanwendungen (DiGA) fast-track for reimbursable health apps is one example among several country-specific regimes a HealthTech company expanding across the EU will need to check market by market.
Market-driven requirements on top of regulation
Not every requirement a HealthTech company faces comes from a regulator. Customers set their own bar, particularly hospital systems and health insurers running vendor due diligence. A SOC 2 report is frequently requested by US healthcare customers and their business associates, and HITRUST certification is common in partnerships with US healthcare providers. Neither is legally mandated in the EU, but both function as de facto market-access requirements once a HealthTech company sells into a market where they are the norm.
[Placeholder: add a quote here from the named Kertos expert on the item, ideally about how HealthTech due diligence actually differs from other verticals.]
Why managing each framework separately doesn’t hold up
When GDPR, ISO 27001, NIS2, and a device regulation are each managed as a standalone project, the same underlying control gets documented, evidenced, and audited multiple times. Access control policies, incident response procedures, and encryption standards, for example, show up as requirements in nearly every one of these frameworks, but a team working in silos will build and maintain separate documentation for each.
Manual, spreadsheet-based tracking makes this worse as the number of frameworks grows. A control tracker built for one framework rarely extends cleanly to a second, so teams end up maintaining parallel systems, chasing evidence over email, and reassembling the same audit trail by hand every time a new certification or a periodic audit comes up.
The mistake most HealthTech teams make here is treating each new framework as an isolated project rather than mapping it against what they have already built. A NIS2 readiness project that starts from scratch, without checking which controls already exist from an ISO 27001 implementation, duplicates work that could largely be reused.
What compliance automation changes for HealthTech companies
Compliance automation platforms address this by building one control framework and mapping every applicable regulation and standard onto it, rather than maintaining a separate structure per framework. A control implemented once, such as encryption of data at rest, gets evidenced once and mapped to every framework that requires it, whether that is GDPR Article 32, ISO 27001 Annex A control 8.24, or the equivalent NIS2 technical measure.
Picture a 60-person telehealth platform based in Germany, expanding into France and the Netherlands. Before automation, its two-person security team spends most of its time re-answering the same due diligence questions for GDPR, ISO 27001, and hospital procurement checklists, each in a slightly different format. Mapping those requirements onto one control set with automated evidence collection means the same underlying proof, an access log, a penetration test report, an encryption configuration, gets reused across every framework it’s relevant to, instead of being gathered and formatted from scratch each time. What changes isn’t the underlying security work; it’s how much of the documentation burden the team carries manually.
Continuous monitoring works the same way. Instead of validating controls once a year for an audit, automated evidence collection pulls from source systems on an ongoing basis, so a misconfigured access control or an expired certificate surfaces close to when it happens rather than months later during audit preparation.
Getting started: a practical roadmap
A phased approach works better than trying to implement everything simultaneously.
Start by mapping every framework that actually applies: GDPR obligations from processing health data, NIS2 status if the company qualifies as an essential or important entity, MDR or IVDR if the software meets the medical device definition, and any customer-driven requirements like SOC 2. This mapping exercise on its own usually reveals where requirements overlap and where a control built for one framework already satisfies most of another.
From there, prioritize the controls that carry the heaviest evidence burden and the highest security impact, typically access control, encryption, incident response, and vendor risk management, and automate evidence collection for those first. Framework-specific gaps, such as MDR’s clinical evaluation requirements or NIS2’s incident reporting timelines, get layered on once the shared foundation is in place.
How Kertos supports HealthTech compliance
Kertos is a European compliance automation platform built for exactly this kind of multi-framework situation. It maps GDPR, ISO 27001, NIS2, and other frameworks onto a single control set, so a HealthTech company doesn’t need to rebuild documentation and evidence separately for each regulation or standard it has to satisfy.
The platform combines automated evidence collection from connected systems with access to certified compliance experts who understand where healthcare-specific requirements, like Article 9 GDPR or NIS2’s Annex I healthcare classification, diverge from general-purpose compliance advice. For HealthTech companies balancing regulatory obligations with commercial due diligence from hospital and insurer customers, that combination keeps the compliance workload from scaling linearly with every new framework or every new market.
If you want to see how this maps onto your own framework mix, book a demo and walk through it with the Kertos team.
Frequently asked questions
Does GDPR apply to health data collected by HealthTech apps?
Yes. Health data is a special category of personal data under Article 9 GDPR, which means HealthTech companies need both a standard legal basis and one of the narrower Article 9(2) exceptions, such as explicit consent, before they can process it.
Is ISO 27001 required for HealthTech companies?
ISO 27001 certification is not legally mandated by EU law, but it is frequently required by hospital and health insurer customers during vendor due diligence, and it directly supports the technical and organizational measures GDPR requires for health data.
Do HealthTech companies need to comply with NIS2?
Many do. NIS2’s Annex I lists healthcare among its high-criticality sectors, and its scope covers healthcare providers, EU reference laboratories, and companies conducting research and development on medicinal products, not only hospitals. Whether a specific company is in scope depends on its size and role in the healthcare supply chain.
What is the difference between MDR and GDPR for HealthTech software?
GDPR governs how personal and health data is processed, while MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746) govern whether software that supports a diagnosis, monitoring, or treatment decision qualifies as a medical device and needs a CE mark and conformity assessment. A HealthTech product can need both at once, and they are assessed separately.
Do HealthTech companies need a SOC 2 report?
There is no EU legal requirement for a SOC 2 report, but US healthcare customers and their business associates commonly request one during vendor due diligence, which makes it a practical requirement for HealthTech companies selling into the US market even though it is not a certification.
