HIPAA-compliant software development means building an application so that the organisation running it can meet the HIPAA Privacy, Security and Breach Notification Rules for any protected health information (PHI) it touches. There is no "HIPAA certified" badge for software: compliance comes from documented risk analysis, technical safeguards, business associate agreements (BAAs) with every vendor that handles PHI, and ongoing operation. This guide is for healthcare providers and health-tech teams commissioning that software.
Key takeaways
HHS does not certify any person or product as "HIPAA compliant". Treat any vendor "certification" claim as marketing.
The Security Rule requires administrative, physical and technical safeguards, starting with a documented risk analysis. OCR runs a dedicated Risk Analysis Initiative to enforce it.
Any vendor that creates, receives, maintains or transmits PHI for you, including your developer and your cloud provider, is a business associate and needs a BAA.
A "HIPAA-eligible" cloud service is a starting point, not a compliant system. Configuration, access control and logging are still your responsibility.
Healthcare breaches remain the most expensive of any industry: an average of $6.64 million per incident in IBM's 2026 report.
Why HIPAA scrutiny of software keeps rising
The numbers explain why boards and investors now ask hard questions about health software. According to the HHS Office for Civil Rights (OCR) 2024 breach report to Congress, OCR received 663 reports of breaches affecting 500 or more people that occurred in 2024. Together they exposed the PHI of roughly 242.9 million individuals, a figure driven largely by the Change Healthcare incident, which alone affected around 192 million people. Hacking and IT incidents made up 81% of those large breaches, and network servers were the most common location of breached PHI (HIPAA Journal summary of the 2024 OCR reports).
The financial impact is just as stark. IBM's Cost of a Data Breach research put the healthcare average at $7.42 million in 2025 and $6.64 million in 2026. That's lower than before, but healthcare is still the costliest sector.
Software vendors are not exempt. In March 2026 OCR settled with MMG Fusion, a SaaS company serving dental and orthodontic practices, over a breach affecting about 15 million individuals. OCR cited a failure to conduct an accurate and thorough risk analysis and a failure to notify the covered entities it served. It was the 12th action under OCR's Risk Analysis Initiative.
This article is general information, not legal advice. HIPAA obligations depend on your specific role, data flows and contracts, so confirm your position with qualified healthcare privacy counsel.
What HIPAA actually requires of software
HIPAA isn't a software specification. It sets obligations for covered entities (health plans, clearinghouses and most healthcare providers) and their business associates. Your software has to make those obligations achievable. Three rules matter most.
The Privacy Rule
The Privacy Rule governs how PHI may be used and disclosed, and gives patients rights over their records. In software terms, it drives:
Minimum necessary access. Users and integrations should see only the PHI their job requires.
Patient rights workflows. You may need to export a patient's record, record amendments and account for certain disclosures.
Purpose limits. Using PHI for marketing, analytics or AI training needs patient authorisation or another permitted basis under the rule. You can't assume it.
The Security Rule
The Security Rule applies to electronic PHI (ePHI) and requires safeguards for its confidentiality, integrity and availability. It's deliberately flexible: some implementation specifications are "required" and others "addressable", meaning you must implement them or document why an equivalent alternative is reasonable. "Addressable" does not mean optional.
The Breach Notification Rule
The Breach Notification Rule requires notice to affected individuals without unreasonable delay and no later than 60 days after a breach is discovered. Breaches affecting 500 or more people must also be reported to HHS, and those affecting more than 500 residents of a state or jurisdiction require media notice too. Business associates must notify the covered entity. Your software therefore needs logging and alerting good enough to tell you what was accessed, by whom and when. Without that, you can't scope a breach.
There is also a useful safe harbour. PHI that was encrypted in line with HHS guidance on rendering PHI unusable, with keys not compromised, is not "unsecured PHI", so notification duties may not apply. That's one of the strongest practical arguments for encryption everywhere.
Mapping the safeguards to your architecture
The table below translates the Security Rule's three safeguard categories into the controls a development team should design in from the first sprint.
Safeguard category | What the rule expects | What it looks like in the build |
|---|---|---|
Administrative | Risk analysis and risk management, assigned security responsibility, workforce training, access management, incident procedures, contingency planning, BAAs | Documented threat model and data-flow diagram, named security owner, joiner/mover/leaver process, incident runbook, tested backup and restore |
Physical | Facility access controls, workstation and device security, media disposal | HIPAA-eligible data centres under a BAA, managed device policy for staff, encrypted laptops, documented data deletion |
Technical: access control | Unique user IDs, emergency access, automatic logoff, encryption | Role-based access control, SSO with MFA, session timeouts, break-glass accounts with alerting |
Technical: audit controls | Mechanisms that record and examine activity in systems containing ePHI | Immutable, centralised logs of reads and writes to PHI, retained and reviewed |
Technical: integrity | Protect ePHI from improper alteration or destruction | Database constraints, checksums, versioned records, backups |
Technical: authentication | Verify that a person or entity is who they claim to be | MFA, strong service-to-service authentication, short-lived tokens |
Technical: transmission security | Guard ePHI sent over networks | TLS 1.2+ everywhere, including internal service calls and integrations |
Encryption: at rest and in transit, with real key management
Encrypt ePHI in databases, file storage, backups and message queues, and over every network hop. Use a managed key service with separated duties, so the people who administer databases can't also read the keys. Note that encryption is currently "addressable" under the Security Rule. That may change: the proposed Security Rule update published in January 2025 would make encryption and multi-factor authentication required, with limited exceptions. As of 2026 it had not been finalised, and reporting on the federal regulatory agenda puts a target date of July 2027. Building to the proposed standard now costs little and avoids a retrofit.
Access control and audit logs
Role-based access is the backbone of the minimum necessary standard. Design roles around real jobs (front desk, clinician, billing, admin), keep PHI out of API responses that don't need it, and log every access to PHI, not just logins. OCR's 2024 findings pointed to "scant internal controls limiting lateral movement and excessive privileges for many user accounts" (HIPAA Journal). That's a design problem, and it's far cheaper to solve before launch.
Hosting on HIPAA-eligible cloud services
Major cloud providers sign BAAs and publish lists of services covered by them, such as the AWS HIPAA-eligible services reference. Two points matter here:
Only the listed services are covered. If a developer adds an uncovered logging, analytics or AI service to the stack, PHI can leak outside your BAA.
The provider secures the infrastructure; you secure your configuration. Public storage buckets, over-privileged roles and unencrypted snapshots are customer-side failures.
HHS's guidance on HIPAA and cloud computing is explicit that a cloud provider storing ePHI is a business associate even if it only holds encrypted data and has no decryption key. Any web application handling PHI should be designed on the same assumption: every party that touches the data is in scope.
Business associate agreements: who needs one
A BAA is the contract that binds a vendor to protect PHI, report incidents and pass the same obligations down to its own subcontractors. You need one with any party that creates, receives, maintains or transmits PHI on your behalf. That typically includes:
your cloud host and any managed database, backup or logging provider;
email, SMS and telehealth vendors that carry PHI;
your software development partner, if its engineers can access production data or real PHI during testing;
analytics, support and AI tools that see patient data.
The cleanest pattern is to keep developers away from production PHI altogether: synthetic or de-identified data in development and staging, and production access only through audited, time-limited break-glass procedures. Where a vendor genuinely needs access, sign the BAA first.
Risk analysis and security testing
Risk analysis is the first administrative safeguard and the focus of OCR's Risk Analysis Initiative. For a software project, it should produce:
an inventory of every place ePHI is created, stored, processed or sent, including logs, caches, exports and third-party APIs;
the threats and vulnerabilities for each, with likelihood and impact;
a risk management plan with owners and dates;
a schedule to repeat the analysis whenever the architecture changes.
Testing then verifies the controls actually work. The proposed Security Rule would require vulnerability scanning at least every six months and penetration testing at least annually (Federal Register). Even before that's final, it's a sensible baseline. Independent security audits and penetration testing before launch, and after major releases, give you evidence to put in your compliance file. Keep that documentation: the Security Rule requires covered policies and records to be retained for six years.
Questions to ask a software vendor before you sign
Use these in your RFP or discovery calls. Vague answers are a signal in themselves. For broader selection criteria, see our guide to choosing a software development partner.
Question | What a good answer includes |
|---|---|
Will you sign a BAA, and do your subcontractors sign one too? | Yes, with a flow-down clause and a named list of subprocessors |
Will your engineers ever see real PHI? | No by default; synthetic data in non-production; audited break-glass for production |
How do you run the risk analysis, and who owns it? | A documented method, a named owner, a deliverable you keep |
Which cloud services will hold PHI, and are they all under the provider's BAA? | A specific service list checked against the provider's HIPAA-eligible list |
How is PHI encrypted, and who controls the keys? | At rest and in transit, managed KMS, separated key administration |
What do your audit logs capture, and for how long? | Reads and writes to PHI, user and service identity, tamper-resistant storage, defined retention |
How will we know about an incident, and how fast? | A contractual notification window, an incident runbook, named contacts |
What independent testing happens before go-live? | External penetration test, remediation evidence, retest |
Do you claim to be "HIPAA certified"? | No. There is no official HIPAA certification for vendors or products |
Common mistakes that cause problems later
Treating HIPAA as a launch milestone. Access reviews, patching, log review and risk analysis updates continue for the life of the system.
PHI in places nobody mapped. Error trackers, application logs, analytics events, push notifications and support tickets often capture names, dates of birth or appointment details.
Uncovered third-party tools. A chat widget, email service or AI API without a BAA can turn a compliant core into a reportable disclosure.
Shared or generic accounts. They break unique user identification and make audit logs useless during an investigation.
Relying on a "HIPAA-compliant" hosting label. The host's controls cover their layer. Yours still need to be designed, configured and evidenced.
Our work on a medical booking system for Orion Aesthetics shows how quickly patient data spreads through bookings, reminders and staff views, which is exactly why the data-flow inventory has to come first. More on how we approach regulated builds is on our healthcare industry page.
How this shapes your project plan
Building for HIPAA from day one changes the plan predictably: discovery includes a data-flow map and first-pass risk analysis, architecture choices are checked against BAA coverage, and the release plan includes an external test with time to fix findings.
For multi-clinic or multi-customer products, tenant isolation becomes a compliance question as well as a technical one. That's a core concern in SaaS development, where one customer's PHI must never be visible to another. Teams that also need ongoing monitoring and hardening typically pair the build with cybersecurity services.
Frequently asked questions
Is there an official HIPAA certification for software?
No. HHS states that it does not endorse private "certifications" and does not certify any person or product as HIPAA compliant. Third-party assessments can be useful evidence, but they don't transfer your legal obligations.
Does my app need to comply with HIPAA if it handles health data?
It depends on who you are and who you work for. HIPAA applies to covered entities and their business associates. A consumer wellness app with no covered entity involved may fall outside HIPAA but still face other federal and state privacy laws. Confirm your status with counsel.
Is a HIPAA-eligible cloud service enough to make my software compliant?
No. A HIPAA-eligible service under a signed BAA covers the provider's responsibilities for that service. You still need correct configuration, access control, encryption, logging, risk analysis and policies for your own application.
Does my software developer need to sign a BAA?
If the developer's staff will create, receive, maintain or transmit PHI on your behalf, including viewing production data while supporting the system, then yes. The better approach is to design the engagement so developers don't need PHI access at all.
Will the proposed Security Rule changes affect a project starting now?
Possibly. It isn't final, but building to its encryption, MFA and testing standards now avoids rework if it's adopted.
Conclusion
HIPAA-compliant software isn't a feature you add at the end. It's the result of decisions about data flows, hosting, identity, logging and vendor contracts, made early and documented well. Verify those decisions before development starts and you'll save yourself the hardest conversations later.
VulcanTech has delivered 80+ projects for clients in 16 countries, including healthcare booking and AI systems, with senior-led teams from our offices in London, Dubai, Pensacola and Lahore. If you're scoping software that will handle PHI, book a free 30-minute discovery session and we'll walk through your data flows, hosting options and security requirements with you.