HIPAA & GDPR Compliance for Healthcare Software: A Practical Guide
⚠️Important disclaimer
This article is general educational guidance, not legal advice. It does not create a lawyer–client relationship, and it cannot account for your specific product, data flows, contracts, or jurisdiction. Compliance is a legal and organizational program as much as a technical one. Before making decisions, consult a qualified privacy attorney, a HIPAA Security/Privacy Officer, and/or a Data Protection Officer (DPO). Laws and enforcement guidance change over time and vary by region - verify the current status of anything below against the primary sources listed at the end.
For Healthcare System Engineers
If you're building a web or mobile application that touches people's health information, a telehealth platform, a patient portal, a wellness app that syncs clinical data, a provider-facing SaaS tool, then two frameworks dominate the conversation: HIPAA (United States) and GDPR (European Union / EEA, with a close UK equivalent). This guide is written for the engineers, product managers, and founders who have to turn those frameworks into real systems.
It covers what the two laws require, a build-along checklist organized by system area, what full implementation does and doesn't get you, and the truth about certificates and testing.
Understanding the landscape
What the two frameworks are
HIPAA (the Health Insurance Portability and Accountability Act) governs Protected Health Information (PHI) in the US healthcare system. Its core components are the Privacy Rule (how PHI may be used and disclosed), the Security Rule (administrative, physical and technical safeguards for electronic PHI), and the Breach Notification Rule.
GDPR (General Data Protection Regulation) is a broad data-protection law covering all personal data of people in the EU/EEA, with health, genetic and biometric data treated as "special category" data that gets extra protection. The UK has its own near-identical UK GDPR - very similar in substance, but a legally distinct regime, so the assumption that EU guidance applies unchanged in the UK or vice versa doesn't fit.
Do they apply to you? Know your role
Your obligations depend on your role, so pin this down first:
HIPAA - Covered Entity vs. Business Associate. A Covered Entity is a healthcare provider, health plan, or clearinghouse. A Business Associate is a vendor that handles PHI on a Covered Entity's behalf - which is what most healthcare software companies are. Both are directly liable under HIPAA.
GDPR - Controller vs. Processor. A Controller decides why and how personal data is processed; a Processor processes it on the controller's instructions. You can be a controller for some data (e.g. your own account holders) and a processor for other data (e.g. patient records you handle for a clinic client). Your role changes your duties.
Key terms to internalize
PHI (HIPAA): health information tied to any of 18 identifiers - names, dates, contact details, medical record numbers, device identifiers, biometric data, full-face photos, and more.
Special category data (GDPR): health, genetic and biometric data. Processing it requires both a lawful basis (Article 6) and an additional condition (Article 9) - commonly explicit consent or the provision of health care.
De-identified / anonymized data: properly de-identified data falls largely outside HIPAA, and truly anonymized data falls outside GDPR. But the bar is high, and re-identification risk is real - stripping a name is not enough in all cases.
The compliance checklist
A checklist organized by the parts of a system engineers actually build, rather than by legal citation.
Each item is tagged:
[H] (HIPAA)
[G] (GDPR)
[H|G]: (both)
Two items also carry a status flag because of a major pending HIPAA change (explained in Part 3):
🟢 Required under current rules
🔵 Best practice today, and likely mandatory under the proposed HIPAA Security Rule - build to this standard now
0. Scoping and foundations (do this first)
[H]: Determine whether you are a Covered Entity or Business Associate.
[G]: Determine whether you are a Controller or Processor (both).
[H|G]: Build a data inventory / data-flow map: every category of health/personal data you collect, where it's stored, who accesses it, and every third party it flows to. 🟢|🔵
[G]: Establish and document a lawful basis (Art. 6) and an Art. 9 condition for each processing purpose involving health data.
[H]: Confirm each use/disclosure of PHI maps to a permitted purpose or a valid authorization.
[H]: Sign a Business Associate Agreement (BAA) with every vendor that touches PHI - including cloud, email, analytics, and error-tracking providers. 🟢
[G]: Sign a Data Processing Agreement (DPA) (Art. 28) with every processor and sub-processor.
[H|G]: Appoint accountable owners: a HIPAA Security Officer and Privacy Officer; a GDPR DPO where required (large-scale special-category processing usually triggers this).
1. Privacy and data protection by design
[H|G]: Data minimization - collect only what the stated purpose needs.
[H]: Enforce the minimum necessary standard in queries, API responses, and UI.
[G]: Purpose limitation - don't silently reuse clinical data for new purposes (e.g., marketing or model training) without a basis.
[G]: Data protection by design and by default (Art. 25) - privacy-protective defaults, not opt-in.
[H|G]: Publish clear, accurate privacy notices (GDPR Art. 13/14; HIPAA Notice of Privacy Practices where applicable).
2. Access control and authentication
[H]: Unique user IDs - individual accounts, no shared logins. 🟢
[H|G]: Multi-factor authentication (MFA) on all access to health data, admin consoles, and infrastructure. 🔵
[H|G]: Role-based access control (RBAC) with least privilege.
[H]: Automatic logoff / session timeout on inactivity. 🟢
[H]: A logged, reviewable emergency ("break-glass") access procedure.
[H|G]: Provisioning and immediate de-provisioning on role change or offboarding; periodic access recertification. 🔵
[H|G]: Strong credential policy; secrets stored in a vault, never committed to source control.
3. Encryption and data protection
[H|G]: Encrypt data at rest - database, object storage, backups, disk (AES-256 or equivalent). 🟢-> 🔵
[H|G]: Encrypt data in transit - TLS 1.2 + everywhere, weak ciphers disabled. 🔵
[H|G]: Key management via a KMS/HSM, with rotation and access control, separate from the data.
[G]: Pseudonymization where feasible (Art. 32).
[H]: De-identification (Safe Harbor or Expert Determination) for analytics and testing.
[H|G]: No health/personal data in logs, error messages, analytics events, URLs, or crash reports - scrub before logging.
4. Audit logging and monitoring
[H]: Audit controls logging create/read/update/delete/export of PHI, with who/what/when. 🟢
[H|G]: Make logs tamper-evident (append-only / integrity-protected) and access-restricted.
[H|G]: Monitoring and alerting for anomalous access (mass exports, off-hours access, repeated failures). 🔵
[H]: Support an accounting of disclosures of an individual's PHI on request.
5. Individual / data-subject rights (build these as features)
[H/G]: Right of access - HIPAA: within 30 days (one 30-day extension); GDPR: within 1 month (extendable by 2).
[G]: Rectification; HIPAA offers an amendment right (may append rather than overwrite clinical records).
[G]: Erasure ("right to be forgotten") - conflicts with HIPAA and medical-record retention laws. Build so you can delete when legally permitted and document lawful retention when you can't.
[G]: Data portability in a structured, machine-readable format (e.g., JSON/FHIR).
[G]: Restrict/object to processing and withdraw consent as easily as it was given.
[G]: No solely-automated decisions with significant effect without safeguards (Art. 22) - relevant to clinical AI.
H/G | Verify identity before honoring any rights request, to prevent social-engineering data theft.
6. Data retention and disposal
[H|G]: Define a retention schedule per data type. HIPAA requires documentation retention for 6 years; medical-record retention varies by US state law. GDPR requires keeping data no longer than necessary.
[H|G]: Secure deletion - cryptographic erasure or verified wipe; ensure deletes reach backups, caches, search indexes, and replicas.
7. Breach and incident response
[H|G]: Maintain a written, tested incident response plan.
[H]: HIPAA breach notification: notify affected individuals without unreasonable delay, no later than 60 days from discovery. Breaches of ≥500 individuals -> notify HHS (and prominent media in the area) within 60 days; <500 -> log and report to HHS annually. As a Business Associate, notify your Covered Entity per your BAA.
[G]: GDPR breach notification: notify the supervisory authority within 72 hours of becoming aware (unless unlikely to pose a risk), notify affected individuals without undue delay if high risk. Processors must alert controllers without undue delay.
[H|G]: Keep a breach register documenting facts, effects, and remediation.
8. Infrastructure, cloud, and secure development
[H]: Use HIPAA-eligible cloud services and sign a BAA with your cloud provider; only place PHI in covered services. 🟢
[G]: Confirm data residency / hosting region meets your commitments.
[H|G]: Network segmentation - isolate systems handling health data; private subnets for databases. 🔵
[H|G]: Encrypted backups + tested disaster recovery (documented RTO/RPO, restore tests). 🟢
[H|G]: No real health data in dev/test/staging - use synthetic or de-identified data, with separated environments and credentials.
[H|G]: Secure SDLC - code review, SAST/DAST, dependency and container scanning, secrets scanning in CI, patch management. 🔵
[H|G]: Change management and least-privilege CI/CD.
[H|G]: Scheduled vulnerability management and penetration testing. 🔵
[H]: Integrity controls to detect improper alteration or destruction of ePHI. 🟢
9. Mobile-specific
[H|G]: Encrypt local storage; store secrets in iOS Keychain / Android Keystore.
[H|G]: Suppress health data in push notifications, lock-screen previews, and app snapshots (mask on backgrounding).
[H|G]: Keep health data out of device logs, default clipboard behavior, and analytics SDK events.
[H|G]: Certificate pinning for API calls.
[H|G]: Require device security (passcode/biometric) before access; consider jailbreak/root detection.
[H|G]: Handle lost/stolen devices - remote session revocation, short-lived tokens.
[G]: Complete App Store / Play Store data-safety and privacy labels accurately; obtain valid consent for tracking SDKs.
10. Third parties and international transfers
[H|G]: Maintain a list of all sub-processors; flow down BAA/DPA obligations to each.
[G]: For transfers outside the EU/EEA, use a valid mechanism - adequacy decision, Standard Contractual Clauses (SCCs), or BCRs - with a transfer impact assessment.
[H|G]: Scrutinize analytics, telemetry, and AI/LLM vendors - check whether your data is used for training, whether a BAA/DPA exists, and where it's hosted.
11. Governance, documentation, and training
[H]: Conduct and document a Security Risk Analysis - a formal HIPAA requirement and the single most-cited deficiency in enforcement. Repeat at least annually and on major changes. 🟢/🔵
[G]: Conduct a Data Protection Impact Assessment (DPIA) (Art. 35) for high-risk processing - large-scale health data almost always qualifies.
[G]: Maintain Records of Processing Activities (RoPA) (Art. 30).
[H|G]: Write, version, and follow your policies (security, access control, incident response, retention, BYOD).
[H|G]: Deliver workforce privacy/security training at onboarding and annually; track completion. 🟢
[H|G]: Retain evidence - risk analyses, training records, access reviews, BAAs/DPAs - for at least the required period (6 years under HIPAA).
An important pending change: the HIPAA Security Rule update
There is a significant overhaul of the HIPAA Security Rule in progress, and builders should understand its status precisely.
The proposed rule (a Notice of Proposed Rulemaking, or NPRM) was published in the Federal Register on January 6, 2025, with the comment period closing March 7, 2025. As of this writing it is still a proposed rule, not law. The regulatory agenda now targets around July 2027 for final action - pushed back from earlier estimates - and that timeline is not binding and could shift again. Until a final rule is issued, the current Security Rule remains in effect and is what regulators enforce.
Why it matters to you now: the proposal is a clear signal of where the bar is heading. It would remove the long-standing distinction between "required" and "addressable" safeguards and make a number of controls explicitly mandatory - including MFA, encryption at rest and in transit, asset inventories, network segmentation, annual risk analysis, and regular vulnerability scanning and penetration testing. Building to that standard today (the 🔵 items above) is a low-regret decision: it strengthens your security now and spares you a scramble when the rule finalizes.
Beyond HIPAA and GDPR
A critical caveat: HIPAA plus GDPR is not the whole map. Depending on your product and markets, you may also be subject to:
US state privacy laws - California's CPRA and roughly twenty other state laws, some with specific health-data provisions (e.g., Washington's My Health My Data Act).
Medical device regulation - if your software diagnoses, treats, or drives clinical decisions, it may qualify as Software as a Medical Device (SaMD) and fall under the FDA (US) or the Medical Device Regulation / MDR (EU). This is an entirely separate and demanding compliance track.
Other national data-protection laws wherever your users are, plus emerging EU rules like the European Health Data Space (EHDS).
Map your obligations to your actual product and footprint; don't assume two frameworks cover everything.
Does full implementation make you "safe"?
Implementing this checklist thoroughly puts you in a genuinely strong position and substantially reduces both legal and breach risk. But it does not produce a guarantee of immunity, and it's important to be clear about why.
Compliance is contextual, and part of it is non-technical. A checklist can't know your specific data flows, contracts, or jurisdiction. It can't sign your documented risk analysis, write your policies, or replace a qualified person exercising judgment. HIPAA's Security Risk Analysis, for example, is a formal legal requirement - not a box a generic checklist can tick for you.
Compliance is continuous, not a one-time build. Every new feature, vendor, and threat can reopen it. A system that was compliant at launch drifts out of compliance without ongoing risk assessment, monitoring, and review.
There are real trade-offs to implementing everything, and they're worth naming honestly: engineering overhead and slower delivery, some performance cost from encryption and audit logging, ongoing maintenance burden, and financial cost (tooling, audits, and sometimes hiring). The failure mode to avoid is spending effort on visible "security theater" while neglecting the documented risk analysis and governance that regulators actually examine. Depth where it matters beats breadth for show.
The realistic framing: thorough implementation plus documented risk analysis, governance, and regular testing - validated by a privacy professional - is what "compliant" actually means. It's risk reduction and demonstrable diligence, not a force field.
Certificates and testing: required or not?
This is one of the most misunderstood areas, so here is the accurate picture.
Certification is not legally required by either law
HIPAA has no official government certification. The US Department of Health and Human Services does not certify anyone as "HIPAA compliant." Any "HIPAA Certified" badge comes from a private vendor and has no legal standing - and no one can lawfully require you to hold one as proof of HIPAA compliance.
GDPR has no mandatory certification either. Article 42 provides for voluntary certification schemes (for example, Europrivacy, the first scheme approved at EU level), but they are optional and still maturing.
But regular testing and evaluation effectively are required
You don't need a certificate, yet both laws require you to verify - repeatedly - that your security actually works:
HIPAA requires periodic technical and non-technical evaluation of your safeguards, and the proposed 2025 update would explicitly add vulnerability scanning and penetration testing.
GDPR Article 32 requires "a process for regularly testing, assessing and evaluating the effectiveness" of your security measures.
So skipping testing is not okay, even though no certificate is involved. Regular risk analysis, vulnerability scanning, and ideally periodic third-party penetration testing are part of the baseline expectation - and you must document them.
The commercial reality: certificates you'll often need anyway
Even though no certificate is legally mandatory, if you sell into hospitals, health systems, or enterprises, buyers will frequently demand one contractually before signing. The common ones in healthcare are:
SOC 2 Type II - the near-universal baseline enterprise buyers ask for.
HITRUST CSF certification - the most recognized healthcare-specific security certification, often the one hospitals specifically want.
Sometimes a third-party HIPAA readiness assessment or attestation.
These take time and money (SOC 2 and HITRUST are multi-month efforts), but for a healthcare product they're often what actually unlocks enterprise deals. Many teams pursue them not because the law compels it, but because their customers do. If you sell direct-to-consumer, you may be able to defer or skip some of these; if you sell into healthcare institutions, plan for them early.
Where to read the primary sources (all free)
You can learn everything above from the regulators themselves at no cost.
HIPAA (US HHS):
HHS "HIPAA for Professionals" portal - the one-stop hub for the Privacy, Security, and Breach Notification Rules, with plain-language summaries and FAQs.
The combined regulation text (45 CFR Parts 160, 162 and 164) - published free by HHS.
NIST Special Publication 800-66 Revision 2 - a free, detailed, engineer-friendly guide mapping each Security Rule requirement to concrete controls.
The HIPAA Security Rule NPRM materials on the HHS site - watch these for the final rule.
GDPR (EU / UK):
The full regulation - official text on EUR-Lex; article-by-article with recitals at GDPR-info.eu, which is the easiest way to read it.
The European Data Protection Board (EDPB) - authoritative EU interpretive guidelines.
The UK Information Commissioner's Office (ICO) Guide - an excellent free plain-language walkthrough with checklists. Note it covers UK GDPR, which is close to but legally distinct from EU GDPR, so confirm EU-specific points against the EDPB or the relevant national supervisory authority.
Watch the European Health Data Space (EHDS) if you operate in the EU, as it adds health-data-specific obligations.
Key takeaways
Know your role first (Covered Entity/Business Associate; Controller/Processor) - it determines your duties.
Work the checklist by system area, and build to the stronger proposed HIPAA standard now (MFA, encryption, segmentation, testing).
HIPAA + GDPR isn't the whole map - watch state privacy laws and medical-device regulation.
Full implementation reduces risk; it doesn't guarantee immunity. Documentation, governance, and continuous review are part of "compliant."
No certificate is legally required, but testing effectively is - and SOC 2 / HITRUST are often commercially necessary to sell into healthcare.
Verify everything against primary sources and qualified counsel before you rely on it.
Final note on scope and currency
This guide reflects the regulatory landscape as of its last-updated date and is intended as an educational starting point, not a substitute for professional legal and compliance advice. Regulations, enforcement priorities, timelines (including the pending HIPAA Security Rule update), and certification schemes change. Before making product or compliance decisions, confirm the current position with the primary sources above and with a qualified privacy attorney and/or compliance professional familiar with your specific product and markets.