Data residency and GDPR for medical device procurement platforms

When a European medical device company uploads tender documents to a cloud-based procurement tool, a simple question arises: where does that data physically reside? The answer has legal, regulatory, and competitive implications that most procurement teams don't consider until it's too late.

Why data residency matters for procurement

Tender documents aren't personal data in the traditional sense. But they often contain: employee names and contact details (personal data under GDPR), pricing strategies (trade secrets), regulatory filing details (confidential business information), and customer relationship data (potentially sensitive under data protection laws).

Under GDPR, if your data is processed outside the EEA, you need adequate safeguards: Standard Contractual Clauses (SCCs), binding corporate rules, or an adequacy decision for the destination country. Many US-based AI tools process data in the US, which requires SCCs at minimum.

The three residency models

1. Regional processing: Data is processed and stored in a specific region (EU, US, APAC). You choose the region. Most enterprise SaaS tools offer this. For EU companies, EU-only processing eliminates the need for cross-border transfer mechanisms.
2. Global processing with safeguards: Data may be processed in multiple regions but with contractual safeguards (SCCs, DPA). This is the default for most cloud tools. It's legally compliant but adds complexity to your data protection impact assessment.
3. Self-hosted/on-premise: The software runs on your infrastructure. Data never leaves your environment. Maximum control, but higher operational overhead. Available from some enterprise vendors.

GDPR compliance checklist for procurement SaaS

When evaluating a procurement tool under GDPR, verify:

• Data Processing Agreement (DPA): The vendor must offer a GDPR-compliant DPA. This isn't optional — it's a legal requirement if the vendor processes personal data on your behalf.
• Data processing locations: The vendor should list all locations where data is processed and stored, including sub-processors (cloud infrastructure, AI API providers, CDN).
• Sub-processor list: GDPR requires the vendor to notify you when they add new sub-processors. Ask for the current list and the notification mechanism.
• Data retention policy: How long is data kept? What triggers deletion? Can you request deletion at any time?
• Breach notification: GDPR requires notification within 72 hours. Does the vendor commit to this contractually?
• Data portability: Can you export all your data in a standard format? This is both a GDPR right and a practical requirement.
• Right to audit: Can you (or a third party) audit the vendor's data processing practices? Enterprise contracts should include this.

Beyond GDPR: country-specific requirements

GDPR is the baseline for EU companies, but other markets have their own rules:

• China (PIPL): Strict data localization requirements. Data about Chinese citizens or collected in China may need to stay in China.
• Singapore (PDPA): Requires consent for data transfer outside Singapore. Less restrictive than GDPR but still requires safeguards.
• Australia (Privacy Act): Requires reasonable steps to ensure overseas recipients handle data in accordance with Australian Privacy Principles.
• Brazil (LGPD): Similar to GDPR. Data transfers require adequate protection in the destination country.

MedStrato's data residency approach

MedStrato offers three deployment options:

• EU processing (default for EU customers): All data processed and stored in EU data centers. No cross-border transfers.
• US processing (default for US customers): Processing in US data centers with SOC 2 Type II certified infrastructure.
• Self-hosted (Enterprise): Full deployment on customer infrastructure. Data never leaves your environment. Available with customer-managed encryption keys.

All options include a GDPR-compliant DPA, sub-processor transparency, 72-hour breach notification, and full data portability.