Medical device data security — what your PLM actually holds, and why the threat model is different

Most medical device companies think of data security as an IT concern. Email encryption, VPN, endpoint protection, maybe some DLP controls on the finance folder. All of which matters. None of which is the actual problem for a medtech company.

The actual problem is that your PLM and your eQMS hold the complete engineering record of every device you've ever built. Design inputs, mechanical drawings, firmware source, risk analyses, test protocols, clinical data, supplier specifications, manufacturing parameters, CAPAs, complaint patterns. A competitor who gets that record doesn't need to reverse-engineer your device. They can build it.

What's actually in your engineering record

Take a connected infusion pump program. Three years of development. What's in the PLM and eQMS at submission time, approximately:

CAD models for 400+ mechanical parts. Schematics for 8 PCB assemblies. Firmware source code (hundreds of thousands of lines typically). Design specifications traceable to user needs. Verification test protocols and results across 2,000+ individual test cases. Validation study data including human factors summative testing. Risk management file with 300–500 identified hazards, each with risk controls traced to specific design elements. Biocompatibility evaluation including supplier material data, extractables profiles, toxicological assessments. Clinical evidence from Pre-Submission meetings and any IDE data. Manufacturing validation protocols and data. Supplier qualification records — often exposing your supply chain, including sole-source components. Post-market complaint data and CAPAs for any predecessor product. The 510(k) or PMA submission package itself.

That aggregate is valuable to three categories of actor: competitors (legitimate and less so), nation-state actors interested in medical supply chain manipulation, and plaintiffs' attorneys in product liability cases looking for design decisions to challenge.

The threat model that actually applies

Generic enterprise security frameworks — SOC 2, ISO 27001 — address the baseline. You need them. They're necessary and not sufficient.

What enterprise frameworks don't capture well is the adversary who wants your design decisions, not your customer data. For a hospital system, the threat model is patient data exfiltration and ransomware. For a device manufacturer, the patient data risk is real but the engineering data risk is often larger. Insurance actuarially values PHI in the hundreds of dollars per record. A complete DHF for a Class III device sells for figures that don't show up in insurance tables.

The adversary profile is different too. Patient data theft attracts opportunistic attackers and ransomware gangs. Engineering data theft attracts state-sponsored industrial espionage, competitor-adjacent consultancies, and nation-state operators in countries with active medical device industrial policy. These actors are patient, well-funded, and specifically targeted — not opportunistic.

SOC 2 Type II — what it actually proves

SOC 2 Type II is a report produced by an accredited auditor covering five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy. Type II means the audit covered a period (typically 6–12 months) rather than a point in time.

What SOC 2 Type II proves: the vendor documented controls in each criterion and operated them consistently over the audit period. What it doesn't prove: that the controls are adequate for your specific threat model. Two vendors can both be SOC 2 Type II and have materially different security postures — the audit tests whether the vendor's own controls work as designed, not whether the design is good enough for your use case.

For medical device engineering data, the Confidentiality criterion is where you want depth. Encryption at rest and in transit is table stakes. What matters more is access control granularity, audit trail completeness, key management practices, and data segregation between customers if the vendor is multi-tenant.

ISO/IEC 27001:2022 — the structural view

ISO 27001 is a management system standard for information security. It certifies that the vendor has an Information Security Management System (ISMS) covering organisational processes for identifying, mitigating, and monitoring security risks. The 2022 revision updated the control set (Annex A) significantly — 114 controls restructured into 93 across four themes: Organizational, People, Physical, Technological.

ISO 27001 certification is procedurally similar to ISO 13485 — certified by accredited bodies, three-year cycle, annual surveillance. Where SOC 2 is American and transaction-oriented, ISO 27001 is international and more management-system-focused. For vendors serving EU customers or operating globally, ISO 27001 is often required; for US-only vendors, SOC 2 may be the primary ask.

Medical device platforms increasingly hold both. The combination addresses different audit audiences and slightly different control emphases.

ISO/IEC 42001:2023 — the newer one most vendors don't have

ISO/IEC 42001:2023 is the AI Management System standard, published December 2023. It's new. The number of certified organisations is still in the low hundreds globally as of early 2026, which makes it a meaningful differentiator for AI-enabled platforms.

For medical device manufacturers using AI-enabled platforms — including MANKAIND — ISO 42001 certification addresses governance questions that SOC 2 and ISO 27001 don't. How is training data handled. How are model outputs audited. How is model drift monitored. How are AI-related risks surfaced and mitigated. For regulatory use cases, these questions aren't optional; they feed into your own ISO 14971 risk analysis of the tools in your quality system.

Encryption, key management, and where vendors get sloppy

AES-256 for data at rest is standard. TLS 1.3 for data in transit is standard. What's less standard is how keys are managed.

Customer-managed keys (CMK) via BYOK (bring your own key) or HYOK (hold your own key) let you revoke vendor access by revoking the key. If your vendor controls the keys, they control the data. In principle they won't read it. In practice, a subpoena, a rogue admin, or a compromised key management system gives them the access regardless of policy. For the most sensitive engineering data — PMA-level design dossiers, Class III device IP — CMK/HYOK is worth insisting on.

Key rotation cadence matters more than key strength. A cryptographically-strong key that's been in use for five years is weaker than a rotated-monthly key of the same length, because the window of exposure if the key leaks is proportional to how long it was active.

Zero data retention — what the phrase means

AI platforms in particular have started claiming "zero data retention." The phrase means different things for different vendors. Three variants worth understanding:

No training on customer data. Your prompts and documents are not incorporated into model training datasets. This is the minimum. OpenAI, Anthropic, and Google all offer API terms guaranteeing this for enterprise tiers.

No logging of customer content. Prompts and completions are processed and then purged, not retained for debugging or improvement. Stricter than the training-only guarantee. Some vendors offer this; fewer than advertise it.

No derivative data retained. No embeddings, summaries, or metadata derived from your content are retained beyond the specific request. This is the strictest interpretation, and it constrains what the vendor can do — no conversation history, no memory features, no cross-session context.

For medical device engineering data, the second tier (no logging) is usually the practical minimum. The first tier (no training) alone doesn't prevent logs from being subpoenaed or compromised.

GDPR, CCPA, and cross-border data

Medical device data is often mixed with personal data. Clinical study records include patient identifiers. Usability evaluation data includes participant identifiers. Supplier records include personal names and contact info. Any platform holding this data is subject to GDPR (if EU data is involved), CCPA/CPRA (if California residents), and various other regional frameworks.

Data residency is the sharp end. GDPR Standard Contractual Clauses and Schrems II put the burden on data exporters to verify that destination-country surveillance laws don't undermine the transfer. For US-based vendors holding EU device program data, this has been a compliance question that most ignored until the 2023 EU-US Data Privacy Framework provided a path forward. That path is under ongoing legal challenge. Vendors offering EU data residency sidestep the problem.

What MANKAIND's posture covers

SOC 2 Type II, ISO/IEC 27001:2022, and ISO/IEC 42001:2023 certifications. AES-256 encryption at rest and TLS 1.3 in transit. Customer-managed key options for enterprise. Zero data retention — no training on customer content, no logging of customer data, no derivative retention. EU data residency available. Role-based access control with audit trails for every read and write. Segregated customer environments — single-tenant options for customers requiring them.

The point of all of it: your engineering record is the most sensitive IP your company holds, and it deserves a security posture calibrated to that fact rather than to generic enterprise data handling.

Frequently asked questions

What security standards should a medical device platform hold?

At minimum: SOC 2 Type II (covering Security and Confidentiality Trust Services Criteria) and ISO/IEC 27001:2022 (Information Security Management System). For AI-enabled platforms, ISO/IEC 42001:2023 (AI Management System) is increasingly expected. For handling EU data, ISO 27701 (Privacy Information Management) adds GDPR coverage.

Is a HIPAA Business Associate Agreement required?

If the platform handles Protected Health Information as defined under HIPAA — which includes clinical trial data, post-market complaint data with patient identifiers, and some device telemetry — then yes, a BAA is required. Platforms that do not handle PHI do not require a BAA, but should document what data is and is not in scope.

What does zero data retention mean in practice?

It varies by vendor. Strongest interpretation: no training on customer data, no logging of customer content, no derivative data (embeddings, summaries) retained beyond the request. For medical device engineering data, verify which definition the vendor actually offers — the phrase is marketing, the contractual terms are what matter.

How does data residency work for EU data?

Under GDPR and the 2023 EU-US Data Privacy Framework, data can transfer between EU and adequacy-certified third countries with appropriate safeguards. For vendors offering EU data residency (processing and storing within the EU), these concerns reduce substantially. Verify residency claims cover both processing and storage, including derivative data like logs and backups.