GDPR, MDR, supply-chain pressure — operationally feasible.
TL;DR. Healthcare suppliers — medical devices, IVD, logistics, pharma suppliers. We know the tension between compliance burden (MDR, GDPR, ISO 13485) and operational reality. AI-native operations that produce regulatory traces.
What this sector typically struggles with
The MDR transition period ended May 2024. Notified bodies are now auditing hard — cybersecurity is no longer a "nice addition" to medical devices, it's part of Art. 15 MDR (risk analysis). In parallel: IEC 62304 and IEC 81001-5-1 specify what cybersecurity means for medical device software. A device manufacturer unable to document IT security won't get CE marking renewed.
At the same time, patient data are special categories (Art. 9 GDPR) — ransomware at a healthcare supplier is double pressure: notified body checks, BfArM checks, patient ombudsman checks. TISAX for pharma suppliers makes it worse — many large pharma customers demand TISAX maturity from suppliers.
ERP stacks are specialized and validation-intensive: SAP S/4HANA with MDR module, Aras Innovator for ECM, PTC Windchill for PLM. Each system change is a validation activity — costs time and money. Cyber insurers additionally demand medical-device-specific cybersecurity policies. Supply-chain pressure is acute: ransomware at a healthcare supplier becomes breaking news.
How we typically help
We build validation-capable IT security: every action is auditable, every log documentable in validation format. This means: endpoint agents don't collect data wildly, but structured and GDPR Art. 32-compliant. Patient data are minimized — pseudonymized where possible. The LLM gateway uses no patient data without explicit approval (and even then with DLP filters).
Business agents automate validation requirements: patch management with change logs, security updates with traceability, incident response with full documentation (for notified bodies or regulatory requests). Knowledge base stores MDR/IVDR requirements and GDPR Art. 9 mappings — so technical and regulatory teams are on the same page.
Cloud engagements are standard (EU cloud at dynexo), but with validation preparation: subprocessor list, DPA (data processing agreement), audit logs in standardized form. For high-risk applications or very sensitive patient data: on-prem is also an option.
Where it usually pays to start
Healthcare suppliers should start with three things: data protection mapping, validation readiness, notified-body evidence.
- GDPR Art. 9 compliance mapping: Which systems process patient data? Minimization and pseudonymization feasible? Audit trail complete?
- MDR cybersecurity requirements (IEC 81001-5-1): How are your ERP, PLM and ECM systems hardened against IEC-81001 requirements?
- Validation IT hardening: Patch management, backup, incident response with change logs and rollback planning — all validation-ready.
- Supply-chain risk register: Where are your suppliers vulnerable? TISAX, NIS2, ransomware exposures — list and mitigate.
- ERP security review: SAP S/4HANA, Aras, Windchill — check authentication, authorization, audit logging per MDR standard.
- Notified-body preparation: Evidence pack for next audit: IT risk analysis, cybersecurity measures, change logs, incident history.
What you can hand off
-
GDPR Art. 9 compliance mapping
Catalog patient-data processing, identify minimization points, pseudonymize where possible.
-
MDR cybersecurity requirements (IEC 81001-5-1)
Assess software security requirements per standard and build hardening plan.
-
Validation IT hardening
Patch management, backup, incident response with full change logs and rollback planning.
-
Supply-chain risk register
Catalog supplier risks (TISAX, NIS2, ransomware) and create mitigation roadmap.
-
ERP security review
Check SAP/Aras/Windchill for authentication, authorization, audit logging and MDR conformity.
-
Notified-body preparation
Build evidence pack with IT risk analysis, cybersecurity measures, change logs for next audit.
Obligations we address
Healthcare suppliers stand in multi-layered regulatory stack in 2026: MDR and IVDR for products, GDPR Art. 9 for patient data, ISO 13485 for quality processes, plus IEC standards for medical device cybersecurity and EU AI Act for AI-assisted diagnostics.
-
MDR Art. 15EU 2017/745 MDR · Art. 15 cybersecurity in risk analysis
Medical devices must systematically document and prove cybersecurity risks. Notified bodies audit evidence before CE marking and in ongoing surveillance. We build the evidence trail, document threat modeling and integrate cybersecurity in product validation processes.
-
MDR Annex IMDR · Annex I Section 17 software requirements
Medical device software must follow state-of-the-art development — secure architecture, IT security measures, protection against unauthorized access. We deliver technical documentation and manage ongoing vulnerability management and update strategy.
-
IVDREU 2017/746 IVDR · in vitro diagnostic regulation
Analogous to MDR, but for in vitro diagnostics and lab diagnostics. Stricter risk classification — Class C and D devices need notified-body approval. We prepare IT security documentation and vulnerability disclosure policy per IVDR requirements.
-
IEC 81001-5-1IEC 81001-5-1 · Health software security
Specifies cybersecurity requirements from MDR/IVDR at software level — secure development lifecycle, threat modeling, penetration testing. We integrate this lifecycle in your development processes, document threats and deliver audit-ready compliance stack.
-
IEC 62304IEC 62304 · Medical device software lifecycle
Classifies medical device software per safety class A/B/C and defines software lifecycle per class. We build the lifecycle process, document software items and integrate cybersecurity measures in each lifecycle step.
-
GDPR Art. 9GDPR · Art. 9 special categories of personal data
Health data are special categories with processing ban — only with explicit consent, legal basis or further exceptions. We build privacy-by-design (minimization, pseudonymization, encryption) and deliver audit trails for each processing action.
-
ISO 13485ISO 13485:2016 · Quality management system for medical devices
Sector standard QMS — IT validation, change management, documented processes, audit trails are mandatory. We build the QMS tooling on Nova9, integrate validation trails and deliver notified-body-compliant reports at audit.
-
MDCG 2019-16MDCG 2019-16 · Cybersecurity for medical devices (guidance)
EU guidance documents concrete expectations for MDR cybersecurity evidence. Necessary for notified-body conformity. We map our evidence packages to the MDCG requirements list and deliver the compliance report in notified-body-accepted format.
-
AI ActEU AI Act · Art. 6 high-risk AI in medical devices
AI components in medical devices (CDSS, diagnostic support, triage algorithms) fall under high-risk AI. Governance, transparency, bias testing, audit trail mandatory. We build the AI governance stack on LLM gateway with output validation and bias metrics.
-
NIS2NIS2 Implementation Act · Health sector (Annex II)
Hospitals and healthcare suppliers above threshold are important entities — with detection, continuity and reporting obligations. We deliver NIS2 stack: detection engineering, BCM plans, 24h BSI reporting workflow.
Sector facts
| Typical engagement size | 100–1,500 employees (typical: development + production + supply-chain support) |
|---|---|
| Most common triggers | MDR notified-body audit, ransomware incident, cyber-insurer requirement, TISAX for large pharma customers |
| Typical deployment model | EU cloud at dynexo (with DPA and subprocessor list) or on-prem for high-risk patient data · Reason: validation requirements and GDPR Art. 9 sensitivity |
| Core regulation | MDR, IVDR, GDPR Art. 9, ISO 13485, IEC 62304, IEC 81001-5-1, optional TISAX |
| Nova9 modules in use | Knowledge base (MDR/IVDR mapping), business agents (validation automation), endpoint agents (ERP/PLM monitoring), observability |
| Typical onboarding | 30–60 days (data mapping, validation setup, ERP hardening, notified-body evidence pack) |
| Audit mirror | Fully in EU · Retention: 10 years (MDR requirement) |
| Clone handover | Available · Validation documentation goes with it |
Asked before the briefing
-
Are you GxP-experienced (good manufacturing practice)?
Indirectly — we build validation-capable IT, not GxP processes themselves. We know good GxP validation partners. Together we deliver IT compliance meeting GxP standards. -
How do you practically handle patient data?
Art. 9 is our default assumption. We process as little as possible. Pseudonymization where practical. Audit logs are segregated and GDPR-compliant. Subprocessor agreements (DPA) are in place and public. -
Can healthcare data go to cloud — or only on-prem?
EU cloud (dynexo) is GDPR Art. 32-compliant and sufficient for most cases. BYOK (bring-your-own-key) possible. If you have stricter requirements: on-prem is also an option. Notified body sees both as state-of-the-art. -
How do you prepare us for notified-body audits?
We build evidence pack: IT risk analysis per MDR Art. 15, cybersecurity measures list, change logs, incident history (with remediation). That's the foundation for notified-body questionnaire. Usually that covers 80% — remaining 20% are product-design questions.
How do we make your healthcare IT MDR/IVDR-compliant?
The industry briefing analyzes your data processing (GDPR Art. 9), shows validation gaps and sketches a notified-body readiness plan — with realistic timelines for audit preparation.