By Ebrahim Khan
14 min read
Key Takeaways
The OCR collected over $9.9 million in HIPAA settlements across 22 enforcement actions in 2024 alone, with Business Associate Agreement deficiencies cited as a contributing factor in numerous cases, while GDPR penalties can reach 4 percent of global annual turnover — a maximum exposure that dwarfs HIPAA's inflation-adjusted per-category annual cap of $2,190,294. For a HealthTech leader building a platform that serves both US and EU patients, or handles health data for populations in both jurisdictions, these are not two separate compliance projects that happen to run in parallel — they are two regulatory frameworks with materially different scope, consent requirements, and breach notification timelines that need to be reconciled into a single technical architecture. This guide provides the dual compliance crosswalk, PHI handling protocols, and BAA execution steps a HealthTech platform needs to satisfy both frameworks without building and maintaining two parallel, redundant compliance systems.
HIPAA and GDPR overlap substantially on technical security controls — encryption, access controls, audit logging — but diverge meaningfully on scope, consent, breach notification timing, and individual rights, meaning a platform built to satisfy one framework needs deliberate additional work, not automatic compliance, to satisfy the other.
| Requirement Area | HIPAA | GDPR |
| Scope | Protected Health Information (PHI) held by covered entities and business associates within the US healthcare context | All personal data of EU/UK residents, including but not limited to health data, regardless of where the processing organization is based |
| Consent basis | Permits certain uses without explicit patient consent for treatment, payment, and healthcare operations | Requires explicit, opt-in consent or another valid legal basis for processing, with health data classified as a special category requiring heightened protection |
| Breach notification timeline | Up to 60 days to notify affected individuals and HHS OCR | 72 hours to notify the relevant supervisory authority from the point of becoming aware of the breach |
| Individual rights | Right to access and request correction of records; no comprehensive right to erasure | Right to access, rectification, erasure ('right to be forgotten'), data portability in machine-readable format, and restriction of processing |
| Geographic transfer restrictions | No inherent geographic restriction on where PHI is stored or processed | Restricts transfers outside the EU/UK absent an adequacy decision or an appropriate transfer mechanism such as Standard Contractual Clauses |
| Encryption requirement | Classified as 'addressable' rather than strictly mandatory, though unencrypted PHI involved in a breach is presumed reportable in practice | Required 'where appropriate,' with regulators consistently treating health data as a context where encryption is expected |
| Data retention | Minimum retention periods apply to certain records (commonly six years for specific documentation) | Data minimization principle favors retaining data no longer than necessary for the stated purpose, creating potential tension with HIPAA's retention minimums |
| Tiered penalties up to $2,190,294 per violation category per calendar year (2026 inflation-adjusted ceiling, effective for penalties assessed on or after 28 January 2026) | Tiered penalties up to approximately $2.13 million per violation category per year (2026 inflation-adjusted ceiling) | Up to 4% of global annual turnover or €20 million, whichever is greater |
The practical implication of this crosswalk is that a HIPAA-compliant platform is not automatically GDPR-compliant, and the reverse is equally true. A platform built to satisfy HIPAA alone will typically lack consent management infrastructure, data subject rights fulfillment workflows, and a compliant cross-border transfer mechanism — all of which GDPR requires but HIPAA does not address. Conversely, a platform built purely for GDPR compliance may not satisfy HIPAA's specific technical safeguard requirements under the Security Rule, or its minimum record retention periods, which can actually conflict with GDPR's data minimization preference for shorter retention.
The most efficient architectural strategy, given this crosswalk, is building to the stricter of the two requirements wherever they overlap and diverge only in degree, then layering the requirements unique to each framework as additional, clearly separated components. Breach notification is the clearest example: since GDPR's 72-hour window is considerably tighter than HIPAA's 60-day allowance, building a single incident response process triggered at the 72-hour mark automatically satisfies both frameworks' timing requirements, rather than maintaining two separate incident response playbooks running on different clocks.
HIPAA's 2024 proposed Security Rule updates, moving toward implementation in 2026, push toward mandatory multi-factor authentication, a defined 72-hour breach notification window for security incidents, and more prescriptive technical safeguard requirements — narrowing the historical gap between HIPAA's more flexible 'addressable' standard and GDPR's more explicit requirements.
This regulatory shift is genuinely convenient for a dual-compliance platform, since HIPAA's move toward a 72-hour notification standard for security incidents aligns it much more closely with GDPR's existing 72-hour supervisory authority notification requirement — meaning a platform built around the tighter, unified timeline is increasingly not just the more conservative choice but the more accurately compliant one under HIPAA's own evolving standard, not merely under GDPR's stricter rule. Similarly, MFA moving from an addressable HIPAA recommendation toward an effectively mandatory requirement removes what was previously one of the more common gaps between HIPAA's flexible language and GDPR's more concrete expectation of 'appropriate technical measures' for access control.
A platform architected today should build to these emerging 2026 HIPAA standards directly rather than to the older, more permissive language, since a platform built to the stricter emerging standard requires no rework once the updated rule takes full effect, while a platform built to the older, more permissive standard will require retrofitting exactly when regulatory scrutiny on this specific area is intensifying.
PHI handling requires field-level classification distinguishing protected health information from ordinary personal data, encryption applied consistently at the AES-256 standard for data at rest and TLS 1.3 for data in transit, and role-based access control enforced at the database layer, not merely the application layer, so that a compromised application component cannot expose PHI beyond what the compromised component's own role actually requires.
-- PHI classification tagging at the schema level
CREATE TABLE patient_records (
id UUID PRIMARY KEY,
patient_id UUID NOT NULL,
diagnosis_code VARCHAR(20), -- PHI: requires field-level encryption + audit logging
appointment_date DATE, -- PHI: subject to same protections as diagnosis data
created_by UUID NOT NULL REFERENCES staff(id),
created_at TIMESTAMPTZ DEFAULT now()
);
-- Every SELECT against a PHI-tagged table logged with requester identity
-- and purpose, satisfying both HIPAA's audit control requirement and
-- GDPR's accountability principle under Article 5(2)A specific technical discipline that satisfies both frameworks simultaneously is treating audit logging as a first-class architectural requirement rather than an afterthought: every access to a PHI-tagged field should be logged with the requesting user's identity, timestamp, and the stated purpose of access, since this single logging discipline satisfies HIPAA's audit control requirement under the Security Rule and directly supports GDPR's accountability principle, which requires an organization to be able to demonstrate compliance, not merely assert it. This logging infrastructure also becomes the evidentiary basis for responding to a GDPR data subject access request, since a well-structured audit log can quickly reconstruct exactly what data has been processed about a specific individual and by whom.
Data minimization deserves particular architectural attention given the tension it creates with HIPAA's retention minimums discussed in the crosswalk above. The practical resolution most dual-compliance platforms adopt is retaining the minimum data HIPAA requires for its specific mandated retention period, while ensuring that any data collected beyond what either framework strictly requires — optional profile fields, marketing preferences, non-essential behavioral tracking — is minimized aggressively and deleted promptly once its specific purpose is fulfilled. This distinction between mandatorily retained regulatory data and discretionarily collected data should be explicit in the data model, not left as an implicit assumption engineers have to reconstruct from business requirements each time a new feature touches patient data.
A Business Associate Agreement is a legally required contract under 45 CFR § 164.504(e) that must be executed before any PHI is shared with a vendor performing services on a covered entity's behalf, and business associates carry direct HIPAA liability independent of the covered entity — meaning a development partner handling PHI needs its own BAA, and needs to flow that same obligation down to any of its own subcontractors that touch PHI.
| Step | What Happens |
| 1 | Confirm whether the relationship actually involves PHI access — a vendor with a general business relationship not involving PHI does not need a BAA, and over-executing BAAs with vendors who have no PHI access creates unnecessary contractual liability and dilutes the seriousness of the agreements that genuinely matter |
| 2 | Draft or adapt a BAA covering the required elements under 45 CFR § 164.504(e): permitted uses and disclosures, required safeguards, breach notification obligations (aligned to the 72-hour standard discussed above), subcontractor compliance flow-down, PHI access and amendment rights, and PHI return or destruction terms at contract termination |
| 3 | Execute the BAA before any PHI is shared — sharing PHI with a vendor absent a signed BAA is itself a HIPAA violation, independent of whether any breach subsequently occurs |
| 4 | Require the business associate to disclose all subcontractors that will handle PHI and confirm those subcontractors have their own executed BAAs, since a broken subcontractor BAA chain is a direct, independently enforceable violation under the HITECH Act |
| 5 | Maintain ongoing documentation of BA identification, due diligence, and compliance monitoring — a covered entity that fails basic due diligence before signing a BAA can itself be held liable for a subsequent breach caused by that business associate's non-compliance |
For a HealthTech platform serving both US and EU patients through the same underlying vendor relationships, the practical approach is executing all three relevant instruments with each vendor handling both categories of data: a BAA covering PHI under HIPAA, a Data Processing Agreement covering personal data under GDPR, and Standard Contractual Clauses where the vendor relationship involves any cross-border transfer of EU-resident data. These three documents govern genuinely distinct legal obligations and do not substitute for one another, even where a single vendor relationship happens to trigger all three simultaneously.
A specific 2026 update worth building into every BAA template going forward is the breach notification timeline itself: BAAs referencing only vague language like 'prompt' or 'timely' notification are increasingly viewed as non-defensible under current enforcement expectations, and should specify a defined window — no more than 72 hours from discovery, aligning with the unified incident response standard discussed earlier — rather than the older, looser statutory language many existing BAA templates still carry forward unchanged.
For any EU or UK patient interaction, GDPR's explicit consent requirement and full suite of data subject rights need to be layered on top of HIPAA's baseline, since HIPAA's more permissive implied-consent model for treatment, payment, and healthcare operations does not satisfy GDPR's requirement for an explicit, freely given, and specific legal basis.
Practically, this means a dual-compliance platform needs a consent management layer, structured similarly to the purpose-specific consent architecture covered elsewhere in this series, that captures explicit consent for EU/UK patients before processing their health data for any purpose beyond the narrow treatment context HIPAA permits without separate consent. It also needs a data subject rights fulfillment workflow — covering access, rectification, erasure, and data portability requests — that HIPAA alone does not require a platform to support at all, since HIPAA's own patient rights are narrower, covering access and correction but stopping short of a comprehensive right to erasure.
The right to erasure specifically creates a genuine architectural tension worth resolving deliberately: a GDPR erasure request from an EU patient cannot simply delete data HIPAA legally requires the platform to retain for its mandated retention period. The resolution most dual-compliance platforms adopt is honoring the erasure request for all data beyond what HIPAA's specific retention mandate covers, while clearly documenting to the requesting individual which specific data elements are being retained under a legal retention obligation and for how long — a response that satisfies GDPR's erasure right to the extent legally possible while remaining honest about the genuine legal constraint HIPAA imposes on full erasure.
A platform transferring PHI or personal health data between the US and EU needs to satisfy GDPR's cross-border transfer restrictions specifically, since HIPAA itself imposes no geographic limitation on where PHI is stored or processed — meaning the transfer mechanism obligation flows entirely from GDPR's side of the compliance equation, not HIPAA's.
For any EU-resident health data being processed or stored in the US, Standard Contractual Clauses remain the primary transfer mechanism, generally supplemented by a Transfer Impact Assessment confirming that US legal protections around that specific data are adequate given the nature of the transfer — a requirement that carries particular weight for health data given its classification as a special category under GDPR requiring heightened protection. The EU-US Data Privacy Framework offers an alternative certification-based mechanism, but given the legal uncertainty around its long-term stability discussed elsewhere in the broader GDPR compliance literature, most dual-compliance HealthTech platforms maintain SCCs as a parallel or fallback mechanism regardless of DPF certification status, rather than relying on DPF alone.
The architectural implication for a platform handling both US and EU patient populations is that data residency needs to be a configurable, auditable property of the system rather than a fixed global default. A platform that can demonstrate, on a per-record basis, where a specific EU patient's data is physically stored and processed — and can produce this evidence quickly in response to a regulator's inquiry — is in a substantially stronger compliance position than one relying on a general architectural assurance that data 'is GDPR compliant' without the underlying data lineage tracking to back that claim up.
AI-powered clinical decision support and diagnostic assistance features introduce compliance obligations beyond baseline HIPAA and GDPR requirements — under GDPR specifically, Article 22's restrictions on automated decision-making apply directly to any AI feature that produces a decision with legal or similarly significant effects on a patient without meaningful human review.
A diagnostic-assistance AI feature that merely surfaces information for a clinician's own independent judgment sits in a meaningfully different compliance position than one whose output is treated as the effective decision with only nominal human sign-off — the latter is far more likely to trigger Article 22's requirement for a documented right to human intervention, an explanation of the automated reasoning, and the ability to contest the decision. A HealthTech platform building AI features should document, explicitly and specifically, where each AI-assisted workflow sits on this spectrum, since this classification directly determines what additional consent, explainability, and human-oversight infrastructure the feature requires under GDPR — obligations that HIPAA's own regulatory framework does not address at all, since HIPAA predates the current wave of AI-assisted clinical tooling by decades and has not yet been comprehensively updated to address it directly.
For AI features touching EU patient data specifically, a Data Protection Impact Assessment should be treated as effectively mandatory rather than optional, given that health data processing combined with automated decision-making sits squarely within the high-risk processing categories GDPR's DPIA requirement was designed to capture. This DPIA should be completed and its recommended mitigations implemented before the AI feature reaches production for EU patients, following the same design-gate discipline for DPIAs covered in more depth elsewhere in this series.
Every subprocessor touching PHI or EU patient personal data needs to be evaluated against both frameworks' vendor obligations simultaneously — HIPAA's business associate chain-of-trust requirement and GDPR's processor accountability requirement — with a single, unified due diligence process rather than two separate vendor review tracks that risk missing a gap either framework alone would have caught.
| Due Diligence Element | What to Verify |
| Security certification | SOC 2 Type II or ISO 27001, with the certification scope confirmed to cover the specific systems and personnel that will actually touch patient data, not a broader corporate certification that doesn't cover the relevant delivery environment |
| HIPAA-specific readiness | Evidence of an established HIPAA compliance program, not merely a general security posture — request the vendor's own HIPAA risk assessment documentation and confirm a BAA template that meets all 45 CFR § 164.504(e) elements |
| GDPR-specific readiness | A vendor-side Data Protection Officer or equivalent function, a documented data processing register, and clarity on where the vendor's own infrastructure physically resides for any EU patient data |
| Subprocessor transparency | A complete, current list of any further subprocessors the vendor itself relies on, with confirmation that appropriate BAAs and DPAs flow down through that entire chain, not just to the primary vendor |
This unified due diligence approach is more efficient than running HIPAA and GDPR vendor reviews as separate processes, since the underlying evidence — security certifications, subprocessor chains, data residency documentation — largely overlaps between the two, and a single comprehensive review avoids the risk of a gap that falls into the seam between two separately managed compliance tracks.
Geekssort builds dual-compliance HealthTech platforms with a unified architecture satisfying both HIPAA and GDPR's technical requirements from the initial design phase, rather than building to one framework and retrofitting the other. For a HealthTech leader serving both US and EU patient populations, a compliance architecture review against the specific crosswalk in this guide is the fastest way to identify which requirements are already satisfied by shared infrastructure and which need dedicated, framework-specific components.
No — the two frameworks overlap substantially on technical security controls but diverge on consent requirements, individual rights, and breach notification timing, meaning each requires its own dedicated compliance work beyond what the other provides.
HIPAA allows up to 60 days to notify affected individuals and HHS OCR, while GDPR requires notifying the relevant supervisory authority within 72 hours of becoming aware of a breach — building to the 72-hour standard satisfies both.
It can — the practical resolution is honoring erasure for all data beyond what HIPAA's specific mandated retention period covers, while clearly documenting to the individual what is being retained under a legal obligation and for how long.
A BAA is a HIPAA-specific agreement governing PHI handling between a covered entity and a business associate; a DPA is the GDPR equivalent governing how a processor handles EU-resident personal data — they address distinct legal obligations and neither substitutes for the other.
Technically classified as 'addressable' rather than strictly required, but in practice, unencrypted PHI involved in a breach is presumed reportable, making AES-256 encryption at rest and TLS 1.3 in transit the practical baseline regardless of the technical classification.
This breaks the chain of PHI custody and is a direct, independently enforceable HIPAA violation under the HITECH Act, regardless of whether the original covered entity's own BAA with the primary business associate was properly executed.
The Netherlands has near-universal English fluency and a persistent shortage of senior engineers in AI, MLOps and cloud infrastructure. Here is why Dutch companies are moving to remote development teams, and what to verify before committing.
The quote on your desk is not the price of the software. This guide splits the real cost of custom software into CapEx vs OpEx treatment, annual maintenance benchmarks by software type, and a 3-year TCO model to build before a CFO signs off.
Most offshore IP disputes trace back to a contract that never transferred ownership in the first place. Here are the clauses that fix it, the enforcement routes that actually cross borders, and the repository controls that make revocation instant.
Ebrahim KhanFounder & CEO
We’re happy to sign an NDA upon request.