- There's no database, framework, or cloud provider that makes an application "HIPAA compliant" by itself — HHS doesn't certify or endorse specific products. What matters is how the software is designed and operated.
- HIPAA doesn't just add security tasks near deployment. It changes how a team thinks about data collection, architecture, authentication, APIs, third parties, logging, testing, deployment, and ongoing operation.
- Four questions organize the whole problem: Where does the data live? How does it move? Who can access it? Can you prove what happened?
- Encryption is necessary but not sufficient — it doesn't address integrity, availability, risk analysis, or physical safeguards on its own.
- Every integration — CRM, scheduling, analytics, payments, AI — can expand where ePHI lives. Connecting systems is exactly where this tends to go wrong.
Direct answer: HIPAA doesn't simply add security tasks near deployment — it changes how developers think about data collection, architecture, authentication, APIs, third parties, logging, testing, deployment, and ongoing operation. The engineering team has to be able to answer four questions with certainty: where does the data live, how does it move, who can access it, and can you prove what happened. Software designed around clear answers to all four is in a fundamentally different position than software that simply encrypted a database and called it done.
01 — The organizing question
The Short Answer: Follow the Data
Most conversations about HIPAA-compliant development start with a tool — a database, a hosting provider, an encryption library. That's backwards. HHS's own guidance treats risk analysis as the foundation of the Security Rule, and risk analysis starts by identifying every location where electronic protected health information (ePHI) is created, received, maintained, or transmitted. Not the primary database. Every location.
That's the framework we use with clients, and it holds up as an organizing principle for the rest of this article:
02 — Before architecture
First: Are You Actually Handling ePHI?
Not every healthcare-related application, and not every piece of health-related information, is automatically ePHI. Whether a workflow falls within HIPAA — and where the regulated data boundary actually sits — is a question worth answering deliberately before architecture decisions get made, not after. A wellness app that never touches a covered entity's data operates under different rules than a patient portal built for a hospital system. This article covers the engineering side of that question, not the legal one — a qualified HIPAA compliance attorney or privacy officer should confirm your organization's specific obligations before you treat any of this as a compliance determination.
03 — Question #1
Where Does the Data Live?
This is the question a "HIPAA-compliant database" answer tends to stop at — and it's exactly where the real problem starts. ePHI rarely stays in one place for long.
Production databases, object and file storage, employee devices, in-memory caches, backups and replicas, application logs, analytics events, support and helpdesk tools, test and staging environments, and third-party vendor systems can all end up holding a copy of regulated data — often without anyone deciding that on purpose. Putting the primary database behind encryption and access controls solves one location. The other nine are where audits and breaches actually happen.
04 — Question #2
How Does the Data Move?
Every hop is a boundary, and every boundary deserves its own answer: browser to application, application to API, API to database, mobile app to backend, system to integration partner, queue to worker, notification service to inbox, file transfer to a partner's SFTP, CRM to EHR and back, export to a report a human downloads. At each of those boundaries, the real questions are the same ones, repeated: Is this hop encrypted? Is the caller authenticated? Is only the minimum necessary data included? Whose responsibility is this leg — yours or a vendor's? What happens, and what gets logged, if this transfer fails partway through?
05 — Question #3
Who Can Access It?
This turns "put MFA on it" into actual application design. It means unique user identification for every person who touches the system — no shared logins. It means authentication and authorization treated as separate problems, with role-based access mapped to least privilege rather than a single admin flag. It means thinking through administrative access, service-account and machine-to-machine credentials, support personnel who need visibility but not full access, vendors who need narrower access still, what happens the moment someone's account should be revoked, and what an emergency-access scenario looks like when the normal path isn't available.
06 — Question #4, the distinctive one
Can You Prove What Happened?
This is the question most teams treat as an afterthought, and it's the one that actually distinguishes a defensible HIPAA-regulated system from one that merely has security controls. The Security Rule requires safeguards protecting the confidentiality, integrity, and availability of ePHI — and integrity and availability both depend on being able to show, after the fact, what actually happened.
In practice that means audit controls covering access history, authentication attempts (successful and failed), data exports, permission changes, administrator activity, API-level actions, and security events — ideally logged somewhere tamper-resistant, with an actual review process behind it rather than logs nobody reads until there's a problem. A system that can't answer "who looked at this record, and when" isn't a system anyone can defend during a review, regardless of how strong its encryption is.
07 — Through the whole SDLC
What Actually Changes During Development?
The four questions aren't a phase — they run through the entire development lifecycle:
Discovery takes longer, because data fields have to get classified before design starts. Architecture has to establish data boundaries explicitly, not let them emerge by accident. Development and staging environments need real controls, not an exemption because "it's not production yet." Every integration needs a vendor review. Logging needs deliberate design so debug output doesn't accidentally capture ePHI. QA has to test permissions and access rules as rigorously as features. Deployment needs secrets, access, and environment configuration managed on purpose. And production needs monitoring and a recovery plan that actually gets tested, not just written down.
08 — A common misconception
Why Encryption Alone Does Not Make Software HIPAA Compliant
Encryption is necessary. It is not sufficient, and HHS says so directly: encryption alone doesn't address data integrity, system availability, the underlying risk analysis a covered entity is required to perform, or the physical safeguards that sit alongside the technical ones. A perfectly encrypted database sitting behind an access-control system nobody reviews, with no audit trail and no recovery plan, is not a HIPAA-compliant system — it's an encrypted database. The four-question framework above is what closes that gap; encryption answers one piece of "how does it move" and part of "where does it live," and stops there.
09 — Where this actually breaks
The Hidden Risk: Every Integration Expands the Data Boundary
This is where system integration expertise becomes directly relevant to HIPAA work, because every connected system is a new place ePHI can be processed or transmitted. A CRM that stores patient contact and appointment information. A scheduling tool that syncs with a calendar. An analytics platform that receives event data by default. An EHR integration. A messaging or notification service. A payment processor. A reporting tool. An AI feature that sends data to a third-party model. Each one can turn a vendor into a business associate the moment it creates, receives, maintains, or transmits ePHI on a covered entity's behalf — which is exactly why "we're using a reputable vendor" isn't the same question as "do we have a signed BAA and do we know what that vendor actually does with the data." We cover this exact boundary-expansion problem in general terms in how CRM integrations actually work, and specifically for HubSpot in when a native connector stops being enough — both apply directly the moment ePHI is anywhere near the systems being connected.
10 — Where the line actually sits
Development Responsibility vs. Organizational Responsibility
This distinction matters commercially as much as technically, because it defines what a development partner can actually promise.
- Authentication and authorization design
- Encryption in transit and at rest
- API design and integration boundaries
- Audit logging and monitoring capability
- Backup, recovery, and resilience architecture
- Technical access controls and role design
- Risk analysis and risk management program
- Written policies and procedures
- Employee training and workforce security
- Vendor agreements and BAAs
- Incident-response governance
- Periodic access reviews and physical safeguards
A development team can build a system capable of supporting HIPAA compliance. It can't, on its own, make an organization compliant — that requires the administrative and physical safeguards on the right, which sit outside the codebase entirely.
11 — A dated, honest note
What About the Proposed HIPAA Security Rule Changes?
HIPAA cybersecurity requirements are evolving. In December 2024, HHS proposed the first major update to the Security Rule in more than two decades — moving encryption and multi-factor authentication from "addressable" to required, adding technology asset inventories and network-mapping requirements, and requiring more frequent risk analyses, vulnerability scans, and penetration testing. As of this writing, that rule is still proposed, not final — federal regulatory filings have pushed the projected finalization date out to mid-2027. Regardless of the final regulatory outcome, designing software around clear data boundaries, access control, encryption, auditability, recovery, and risk management puts an organization in a stronger position either way.
We're deliberately not turning this article into a tracker of that rulemaking — it's a moving target, and a blog post is a bad place to chase it. For the current, authoritative status, HHS's own Office for Civil Rights page is the source worth checking directly rather than a secondhand summary.
12 — Before you scope the project
Questions to Ask Before Building HIPAA-Regulated Software
Turn the four-question framework into a discovery checklist
Worth answering before a single line of code gets written.
- What data is actually regulated, and what isn't?
- Where does it enter the system?
- Where can copies of it appear — backups, logs, exports, caches?
- Which services and integrations touch it, even briefly?
- Who requires access, and at what level?
- What happens, technically, when someone's permissions change?
- What must be logged, and who reviews those logs?
- What happens to access and data during an outage?
- Which vendors need a signed BAA before integration work starts?
- How are backups actually restored, and has that been tested?
- What does the organization need to demonstrate during a security review?
13 — How we work
How Virgo Development Approaches Secure Software
Short version: identify the sensitive data, map the data flow, define the security boundary, design access and integration controls, build, verify, then monitor and maintain — the same four questions, applied in order, before a single feature gets designed. It's the same engineering discipline behind our broader custom software and healthcare development work, and it's the same reason system integration gets treated as a security decision, not just a data-plumbing one, whenever ePHI is anywhere near the systems being connected. If you're earlier in the process and still evaluating who should build this at all, our framework for choosing a development partner applies here too — with data-handling and audit questions weighted more heavily than usual.
14 — Common questions
Frequently Asked Questions
What makes software HIPAA compliant?
There's no certification that makes software "HIPAA compliant" on its own — HHS doesn't endorse or certify specific products. What matters is whether the software is designed and operated with clear answers to where data lives, how it moves, who can access it, and whether you can prove what happened, alongside the organization's own policies, training, and risk management.
Does HIPAA require encryption?
Encryption of ePHI is a required safeguard under the current Security Rule (with limited, documented exceptions), and the proposed 2024 update would make it mandatory with fewer exceptions than today. Either way, encryption alone doesn't satisfy the full Security Rule — integrity, availability, and access controls all still apply.
Is there a HIPAA-compliant database?
Not in the sense of a product that's certified compliant out of the box. Several databases and cloud services can be configured and operated to support HIPAA compliance — under a signed BAA, with the right encryption, access controls, and logging — but the compliance comes from how it's configured and used, not from the product itself.
Does AWS or Azure hosting make an application HIPAA compliant?
No. Major cloud providers offer services that can support HIPAA-compliant architectures and will sign a BAA for eligible services, but hosting on them doesn't automatically make an application compliant — that still depends on how the application is built and operated on top of that infrastructure.
Does a software developer need a BAA?
If the developer or their platform creates, receives, maintains, or transmits ePHI on behalf of a covered entity, they're generally acting as a business associate and a BAA is appropriate — this is worth confirming with qualified counsel for your specific arrangement rather than assuming either way.
Can HubSpot or a CRM contain ePHI?
It can, if health information is stored in it — which is exactly the kind of integration-boundary question covered above. Whether that's appropriate depends on what data is involved, what the CRM vendor's BAA covers, and how access is controlled inside the CRM itself.
How do APIs affect HIPAA compliance?
Every API is a data-movement boundary — see Question #2 above. Each endpoint that touches ePHI needs its own answer on encryption in transit, authentication, minimum-necessary data exposure, and logging.
Does HIPAA require audit logs?
The Security Rule requires audit controls that record and examine activity in systems containing ePHI — in practice, this means the "can you prove what happened" question above isn't optional.
What changes when building a HIPAA-compliant mobile app?
The same four questions apply, with mobile-specific answers: where data is cached or stored on the device, how it's protected if the device is lost, how the app authenticates over potentially untrusted networks, and how access is revoked if a device is compromised or an employee leaves.
None of this is legal advice, and it isn't a substitute for a qualified HIPAA risk analysis specific to your organization. It's the engineering lens: what changes about how the software itself gets built when the data behind it is regulated. Most of the work is genuinely just good software architecture, applied with more discipline and less flexibility to skip a step.
Building something that needs to handle ePHI, or auditing something that already does? Book a Discovery Call with me and the team.
Jamie Lords ↗ LinkedIn is CEO of Virgo Development, which builds HIPAA-compliant patient portals, telehealth interfaces, and health data systems as a first-class engineering concern, not an afterthought. This article is general engineering guidance, not legal advice. HIPAA Security Rule and rulemaking status are drawn from HHS's own current guidance and public regulatory filings, compiled 2026 — consult a qualified HIPAA compliance attorney or privacy officer for your organization's specific obligations.