HIPAA and GDPR Can Block Your Launch: Check These 12 Software Gaps First

A HIPAA and GDPR compliant software development checklist covers twelve control areas: data minimisation, lawful basis, access control, audit logging, encryption, retention and erasure, vendor contracts, breach readiness, log hygiene, non-production test data, DSAR handling, and cross-border transfers. Most launches stall on the last four.

One correction first. Most of the "2026 HIPAA requirements" articles ranking today will tell you encryption is mandatory and MFA is required for everyone touching ePHI. That's wrong, and treating it as settled law means arguing the wrong points with your auditor.

Those requirements come from a Notice of Proposed Rulemaking. Proposed. What follows separates what binds you today from what's proposed for 2027, then walks the twelve gaps that hold up launches.

What actually triggers HIPAA and/or GDPR for your software?

HIPAA applies if you are a covered entity (a health plan, healthcare clearinghouse, or provider transmitting health information electronically for covered transactions) or a business associate handling ePHI on their behalf. GDPR applies whenever you process personal data of people in the EU or EEA, wherever your company is registered.

Teams get this backwards. They over-apply HIPAA and under-apply GDPR.

A consumer wellness app storing sleep and heart rate is usually neither a covered entity nor a business associate. Then a clinic pays you to process their patients' records, and you became a business associate that day. The trigger is the relationship, not the data type.

GDPR has no such gate. An IP address tied to a session is personal data. Health data is also a special category under Article 9, so you need an Article 9 condition sitting on top of your Article 6 lawful basis. I've watched teams document one, feel finished, then find the Article 9 gap during a buyer's security review weeks before launch.

Governance failures land well before engineering ones in regulated verticals, the same reason AI projects die faster in fintech and healthtech.

What's legally binding today, and what's only proposed for 2027?

Under current law the HIPAA Security Rule classifies encryption of ePHI at rest and in transit as addressable, not required, and it does not mandate multi-factor authentication anywhere. HHS proposed changing both in an NPRM published in the Federal Register on 6 January 2025. That rule is still not final.

The proposed amendments (RIN 0945-AA22) moved to the Long-Term Actions section of the Unified Agenda, with July 2027 as the anticipated date for final action, pushed from the previously listed May 2026. That placement generally signals no final rule within twelve months.

Now the nuance most articles get wrong in the other direction. Addressable doesn't mean optional. Under 45 CFR 164.306(d)(3) you assess whether the specification is reasonable and appropriate, implement it if it is, and if it isn't, document why and put an equivalent alternative in place. Skipping it silently is a finding.

Read the last column again. Almost none of it is architecture you'd regret if the rule never lands. The gap between today's obligations and the 2027 proposal is mostly documentation and cadence. Build for the proposal and you clear current law on the way past.

Which 12 gaps block launches, and how do you close each one?

The twelve gaps are data minimisation, lawful basis and consent, access control, audit logging, encryption, retention and erasure, vendor DPAs and BAAs, breach readiness, PHI leaking into application logs, test data in non-production, DSAR handling, and cross-border transfers. Each maps to an artifact a reviewer will ask for.

1. Data handling and minimisation. Article 5(1)(c) wants data limited to what's necessary; HIPAA's Privacy Rule says minimum necessary. Both come down to what this endpoint actually returns. Default ORM serialisers dumping the whole model are the usual offender.
2. Consent and lawful basis. Consent is one of six lawful bases under Article 6, and health data needs an Article 9 condition on top. Store the notice version, timestamp, and scope agreed. If you can't reconstruct what a user agreed to on a given date, you have a checkbox.
3. Access control and unique IDs. Unique user identification and an emergency access procedure are both required today. Shared service accounts reading patient records fail review. So does a break-glass path nobody has tested.
4. Audit logs. 164.312(b) wants mechanisms that record and examine ePHI activity. Article 30 wants records of processing activities. Teams conflate them. Your audit log answers who read this record; Article 30 answers what categories you process and why.
5. Encryption at rest and in transit. Addressable today, proposed as required. Turn it on. Disk encryption won't stop an application-layer leak, so encrypt direct identifiers at field level where your threat model justifies it.
6. Retention and erasure. Article 17 grants erasure rights. HIPAA retention duties and state medical-record laws pull the other way, so reconcile them as policy before writing code. Soft deletes that never hard-delete are the failure I see most in review.
7. Vendor DPAs and BAAs. Article 28 requires a written processor contract with mandatory clauses. HIPAA requires a BAA with every business associate and their subcontractors. Your error tracker. Your log aggregator. Your LLM API. If regulated data reaches it, the paper comes first.
8. Breach readiness. Article 33 gives 72 hours from awareness to notify the supervisory authority, unless a risk is unlikely. HIPAA's Breach Notification Rule runs off discovery. Seventy-two hours won't cover inventing a process, so run a tabletop first.
9. PHI and PII leaking into application logs. This fails more audits than anything else here, and it's invisible in a pull request. Request bodies logged at DEBUG. A stack trace with a serialised patient object. Redact at the logging boundary, then write a test that asserts on it. Log pipelines stay under-defended, which is why they surface in current AI security attack surfaces too.
10. Test data in non-production. Copying a production dump into staging is a disclosure, and staging usually has weaker access controls plus no audit logging. Bake deterministic masking into the restore script so nobody skips it.
11. DSAR handling. Article 12(3) sets one month to respond, extendable by two further months for complex requests. The clock is legal; the implementation is a data map. If you can't enumerate every store holding one user's data in an afternoon, you won't meet it.
12. Cross-border transfer. Chapter V needs an adequacy decision, standard contractual clauses, or another Article 46 safeguard. EU patient data hitting a US inference endpoint is a transfer, and the answer comes down to a private or on-premise LLM data residency decision.

What does compliance cost built in versus retrofitted?

Built-in compliance is mostly design decisions and configuration: schema shape, an auth provider, a redaction layer at the logging boundary, a retention job, a vendor register. Retrofitting the same controls means data migration, backfilling audit history you never captured, and reopening contracts with vendors already holding your data.

The expensive part isn't the control. It's the history.

You can't backfill an audit log. Nothing recreates who viewed a record last March. You can't retroactively obtain consent for processing that already happened, or un-send data to a processor you engaged without a DPA.

Compare the builds. A retention job with a dry-run mode is a day. Swapping your auth provider after launch is weeks, because every mobile client and partner webhook holds a token from the old one. I'd quote a multiplier for late-stage defect cost, but I've never found one with working I could check. The day-against-weeks gap above you can measure on your own codebase, which makes it the stronger argument anyway.

At Shanti Infosoft we run a CMMI Level 5 process across 80+ engineers, and for regulated work the badge isn't the point. The evidence an auditor wants (who approved this change, what testing ran) falls out of how the work already happens. Fold these controls into the software development service from sprint one and they cost what any cross-cutting concern costs. Bolted on later, they become their own project.

Who signs this off before you launch?

Four owners, minimum: an engineering lead for the technical safeguards, a named data protection contact for Article 30 records and DSARs, an assigned security official for HIPAA (the Security Rule requires one by name), and a commercial owner for BAAs and DPAs. Legal review sits on top, not instead.

Two GDPR obligations decide whether that sign-off is real or ceremonial.

Article 35 requires a DPIA for high-risk processing, and health data at any meaningful scale qualifies. Its output is supposed to change the design. Run it after the architecture is frozen and you've produced a document, not an assessment.

Article 25 is the other. Privacy by design and by default is a legal obligation with a named article, not a philosophy. "By default" is the part teams skip: the least privacy-invasive setting has to ship switched on.

My position on sequencing isn't the popular one. Do the DPIA and the data map before you write the schema. Both answer questions your schema encodes permanently. Retention windows and identifier placement are cheap on a whiteboard, expensive after go-live.

If you want a second pair of eyes on where your build stands, book a call and we'll walk your architecture instead of a questionnaire.

Frequently Asked Questions

Is encryption mandatory under HIPAA in 2026?

No. It remains an addressable implementation specification under 45 CFR 164.312. The NPRM published 6 January 2025 proposes making it required, with anticipated final action now July 2027.

Does HIPAA require multi-factor authentication today?

No. The current Security Rule requires person or entity authentication without specifying a method. MFA appears in the proposed rule only. Build it anyway; enterprise buyers ask during procurement.

Does GDPR apply if my company has no EU office?

Yes, if you offer goods or services to people in the EU or EEA, or monitor their behaviour. Territorial scope follows the data subject's location, not your registration.

Do we need both a BAA and a DPA with the same vendor?

Often yes, because they cover different regimes. A BAA addresses HIPAA obligations for ePHI; an Article 28 processor contract addresses GDPR. Many vendors publish both.

Can we use production data in staging if we anonymise it?

Only if the anonymisation is genuine and irreversible. Pseudonymised data is still personal data under GDPR, and a re-identifiable dataset in a lower-controlled environment is a disclosure.

How fast do we have to report a breach?

Article 33 sets 72 hours from awareness for the supervisory authority, with individual notification handled separately where risk is high. HIPAA's Breach Notification Rule runs from discovery.

Do we need to appoint a Data Protection Officer?

Not always. A DPO is mandatory where you carry out large-scale processing of special category data, which catches most healthtech products. Otherwise, still name an owner for Article 30 records and DSARs.