More than 167 million people were affected by large healthcare breaches in a single recent year. That scale changes the engineering conversation. You're not adding a privacy policy to a finished app. You're deciding, from the first ticket, where health data can go, who can see it, and what proof you'll have when someone asks.
Table of Contents
- Why Breach Numbers Changed How Teams Build
- Technical Safeguards the Security Rule Expects
- How a Risk Analysis Shapes the Build
- What a Business Associate Agreement Covers
- PHI That Leaves the Database
- Controls in Real Health Product Builds
- Set the Compliance Boundary Before You Scope
<a id="why-breach-numbers-changed-how-teams-build"></a>
Why Breach Numbers Changed How Teams Build
HIPAA compliance for software development means designing, building, and operating software so that electronic protected health information, or ePHI, keeps its confidentiality, integrity, and availability, and being able to prove it with documented controls, a risk analysis, and vendor agreements. It's a continuous program, not a sticker added at release.
The U.S. Department of Health and Human Services Security Rule proposal page reports that large breaches, those affecting at least 500 individuals, increased by 102% between 2018 and 2023, while affected individuals increased by 1,002%, with more than 167 million people affected by large breaches in 2023 alone. Since 2019, large breaches caused by hacking increased by 89% and those caused by ransomware increased by 102%.
<a id="what-those-totals-mean-in-a-product-backlog"></a>
What those totals mean in a product backlog
Say a telehealth team ships a working video visit. No employee plans to misuse records, yet ePHI can still escape through compromised credentials, an insecure API, excessive privileges, a misconfigured cloud bucket, a vulnerable dependency, weak authentication, or monitoring nobody reviews. Each failure is ordinary engineering. Each one becomes a breach surface once patient data is involved.
That's why the response isn't a final checklist. Teams need least-privilege access, encryption, secure session management, dependency and vulnerability management, centralized audit trails, tested backups, incident playbooks, and recurring risk analysis. After launch, patching, log review, access recertification, and regression testing keep those controls real.
Vendor choices belong in the same pass. Hosting, analytics, messaging, storage, support, and integration providers can all touch ePHI, so they need scrutiny before data flows to them. Product leaders who want a broader view of managing regulatory penalty risks should connect that risk work to the build itself, not treat penalties as a legal topic after release.
The guide ahead follows that order. First the technical safeguards you must build, then the risk analysis that chooses proportionate controls, then what a business associate agreement does and doesn't do, the side channels where PHI escapes, and how those choices look in real health products.
<a id="technical-safeguards-the-security-rule-expects"></a>
Technical Safeguards the Security Rule Expects
Start with the table. Paste these rows into ticket acceptance criteria, because a reviewer won't accept "we take security seriously" as evidence. Each row names what the build must show and the miss that usually fails review.
| Safeguard | What the build must show | Common miss |
|---|---|---|
| Access control | Least privilege, role or attribute rules, tenant isolation, emergency access, separate service identities | Shared admin logins and broad production roles |
| Audit controls | Logs with actor, time, resource, action, allow or deny, and correlation id, without extra PHI | PHI written into debug or analytics logs |
| Integrity | Append-only audit storage, checksums or signatures, controlled migrations, alerts on odd edits | Silent overwrites of clinical records |
| Authentication | Every person and every system that requests ePHI is verified | Service accounts with long-lived shared secrets |
| Transmission security | Modern TLS, managed keys, encrypted service paths, no PHI in URLs or unapproved chat | PHI in query strings, crash reports, or email |
The standards behind the table sit in 45 CFR 164.312 in the electronic Code of Federal Regulations. Read them as design requirements, not as a certification. They don't give you legal advice, and passing your own review doesn't certify the product.
<a id="access-control-and-authentication"></a>
Access control and authentication
Access control means least privilege in two places, the application and the infrastructure. A clinician, a billing user, a support agent, and a background job should not share permissions. Use role-based or attribute-based authorization, enforce tenant isolation so one clinic can't read another clinic's records, and give every service its own identity.
Write the emergency-access procedure before an emergency. Break-glass access should be rare, time limited, logged, and reviewed. If your team can't explain who can use it and how you'll know they did, the control isn't ready.
Authentication verifies every person or system that requests ePHI. Don't stop at human logins. APIs, integrations, cron jobs, and admin tools request data too, and a long-lived shared secret pasted across services makes rotation and revocation painful.
<a id="audit-controls-and-integrity"></a>
Audit controls and integrity
Audit controls must record activity in systems that contain or use ePHI and support examination of that activity. A useful production log records user or service identity, timestamp, resource, action, authorization outcome, and a correlation id. It avoids copying unnecessary PHI into the log line itself.
Practical rule: If a log can't answer who touched which record, when, and whether they were allowed, it won't help during an incident.
Teams building evidence packs can compare their logging approach with Vigil Security's guide to audit evidence, then test their own logs against real scenarios. Simulate a denied request, a record export, and an admin change. Check that all three appear.
Integrity controls detect unauthorized alteration or destruction. Use append-only or immutable audit storage, checksums or signatures for critical records, controlled database migrations, and alerts on anomalous changes. A silent overwrite of a clinical note should be impossible to miss.
<a id="transmission-security-and-encryption-at-rest"></a>
Transmission security and encryption at rest
Transmission security protects ePHI while it traverses networks. In practice that means modern TLS, disciplined certificate and key management, and encrypted private service-to-service paths where appropriate. It also means a clear prohibition. Don't put PHI in URLs, debug logs, analytics payloads, or unapproved messaging channels.
Document encryption at rest in the same ticket as your transmission checks. Name who owns the keys, how they're rotated, and whether backups are encrypted with the same discipline. An encrypted primary database beside unencrypted backups leaves a plain gap.
Place the incident clock beside these safeguards, not as a sixth one. Affected individuals generally must be notified without unreasonable delay and no later than 60 days after breach discovery, and breaches affecting 500 or more individuals must also be reported to HHS within that period. Your logs and runbook exist so that clock doesn't start with a blank page.
<a id="how-a-risk-analysis-shapes-the-build"></a>
How a Risk Analysis Shapes the Build
A risk analysis isn't a form you complete after the stack is frozen. It's the first design step, the way a building survey decides where fire doors go instead of hanging a plaque after construction.
The HHS guidance on risk analysis identifies risk analysis as the first step in selecting safeguards and expects organizations to evaluate the confidentiality, integrity, and availability of ePHI across systems that create, receive, maintain, or transmit it. That scope is wider than your database. It includes every place data passes or rests.
<a id="four-steps-that-produce-buildable-work"></a>
Four steps that produce buildable work
Work in this order, and don't skip ahead to controls before you know what you're protecting.
- Inventory the system. Map PHI data flows, storage locations, APIs, user roles, service accounts, vendors, logs, backups, and administrative interfaces.
- Model reasonably anticipated threats. Consider stolen credentials, excessive access, lost backups, vendor compromise, and accidental disclosure through a support tool.
- Assess likelihood and impact. A likely exposure of many records outranks an unlikely exposure of one field, and that ranking should be written down.
- Map remediation to owners. Every accepted risk and every fix needs a named accountable owner and a test that proves the work landed.
Teams that want a worksheet alongside this process can work through the eight steps for assessing HIPAA risks and convert each gap into a ticket. The worksheet only helps if its outputs enter the backlog.
This short walkthrough shows how a structured review turns vague concern into sequenced engineering work.
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/F6XN32rs_ew" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a id="proportionate-does-not-mean-exempt"></a>
Proportionate does not mean exempt
The Security Rule is technology-neutral. Organizations may choose safeguards appropriate to their size, complexity, infrastructure, capabilities, costs, and the probability and criticality of risks. A small coaching MVP and a multi-tenant telehealth platform both need structured controls, but they won't implement every safeguard at the same scale.
An MVP isn't exempt. Its controls can be proportionate, which means fewer integrations, fewer PHI fields, and tighter scope, not missing access control. Collect less data and you have less to protect. That's a legitimate design decision when it's deliberate.
By the end, your team should be able to show a system data-flow diagram, a risk register, a minimum-necessary access matrix, retention and deletion rules, an incident runbook, and evidence that each identified risk was remediated or formally accepted. Each artifact becomes a ticket with an owner and a test. If an output has no owner, it will drift.
<a id="what-a-business-associate-agreement-covers"></a>
What a Business Associate Agreement Covers
A business associate agreement, or BAA, is a contract. It obliges a vendor that handles ePHI for a covered entity, or for another business associate, to protect that data under defined terms. It doesn't implement a single control by itself.
That obligation has a specific origin. According to the HHS Security Rule overview, the HITECH Act's 2013 Omnibus Final Rule extended key obligations to business associates and strengthened privacy, security, enforcement, and breach-notification requirements. A development agency handling ePHI is therefore in scope and needs an agreement before touching real records.
<a id="what-the-contract-should-force-into-delivery"></a>
What the contract should force into delivery
Read a BAA as a delivery checklist. It should pin down five things your team can verify during the engagement.
- Permitted uses and disclosures. Which PHI fields the vendor may use, for which purpose, and nothing beyond that purpose.
- Subcontractors. Which downstream providers may touch ePHI, with each provider in the chain signing its own agreement.
- Incident reporting. How fast the vendor tells you about a security incident or breach, and what detail that notice must contain.
- Return or destruction. What happens to the data when the engagement ends, including backups and exports.
- Provider scrutiny. Explicit review of hosting, analytics, messaging, storage, support, and integration providers, not just the main cloud account.
If you're drafting your first agreement, our explanation of what a BAA means for healthcare apps walks through the parties and clauses in plain language. Bring that understanding to your lawyer rather than signing a template unread.
<a id="where-the-agreement-stops"></a>
Where the agreement stops
HIPAA is not a product certification or a one-time technical review, and signing an agreement does not certify the software or replace counsel.
The customer's lawyer still decides covered-entity status, whether a use is permitted, and what minimum necessary means for a given workflow. Engineers can't make those calls in a sprint planning meeting. A studio can implement controls and sign the agreement while stating plainly that it provides no certification or legal sign-off.
Keep confidentiality, integrity, and availability as design goals after signature, because the agreement doesn't implement them. The contract creates accountability. Architecture, testing, monitoring, and risk analysis create the protection the contract describes.
<a id="phi-that-leaves-the-database"></a>
PHI That Leaves the Database
Teams often protect the primary database first, then discover PHI everywhere else. It turns up in source-control tickets, crash reports, prompt logs, analytics events, staging databases, customer-support tools, wearable APIs, and developer laptops. Those paths rarely appear on an architecture diagram, which is exactly why they leak.
The exposure isn't theoretical. The American Hospital Association cybersecurity review reported that 364 hacking incidents affecting more than 33 million people had been reported to HHS OCR by October 3, 2025. HHS has also proposed stronger written, tested, and regularly updated security procedures for regulated entities and business associates, so informal vendor habits won't age well.
<a id="run-a-feature-approval-test-before-shipping"></a>
Run a feature approval test before shipping
Apply six checks to every new processor, integration, or AI feature. Block the feature until all six pass.
- Decide whether each field is PHI. Names and diagnoses are obvious, but device identifiers, timestamps, and free text can identify a patient too.
- Map every processor and country. List where the data is processed and stored, including subprocessors you didn't choose directly.
- Confirm permitted use and retention. Write down why the vendor receives the data and how long it keeps it.
- Disable model training or secondary use unless it's expressly authorized for that data.
- Redact telemetry before events, crash reports, or session data leave the app.
- Verify deletion and incident-notification terms in the contract, not in a sales email.
| Channel | How PHI escapes | Required check |
|---|---|---|
| AI prompts and model logs | Clinical text sent for summaries or letters | No training or secondary use unless authorized |
| Analytics and crash reports | Identifiers in events, stack traces, or session replay | Redact telemetry before it leaves the app |
| Tickets and support tools | Screenshots and pasted records in trackers or chat | Keep PHI out of tools without a BAA |
| Staging and laptops | Production copies and local exports | Synthetic or minimized data, with deletion rules |
| Wearables and messaging | Health API payloads and SMS or email bodies | Map processor, country, retention, and incident terms |
Integrations deserve the same scrutiny as AI features. When you scope work like the exchanges described in our guide to EHR and FHIR integration costs, budget for the vendor review and data mapping, not just the API calls.
A business associate agreement does not make an unsafe architecture safe.
Responsibility stays distributed across the covered entity, developers, cloud provider, AI vendor, and integration partners. If you send full clinical notes to a model endpoint that retains prompts, a signed agreement doesn't undo that design. Send less data, redact what you can, and choose paths you can defend.
Globally delivered teams face one more boundary. HIPAA compliance for software development does not by itself resolve GDPR, UK, or other local privacy and cross-border transfer requirements. A processor country that's acceptable under one framework may need separate analysis under another, and that analysis belongs to counsel before launch.
<a id="controls-in-real-health-product-builds"></a>
Controls in Real Health Product Builds
Rules become clearer when you attach them to a stage of work. Three situations cover most of what health-tech founders bring to a first scoping call.
<a id="a-live-telehealth-app-with-ai-summaries"></a>
A live telehealth app with AI summaries
We built a HIPAA-compliant mobile platform that captures consultations, generates AI-powered medical summaries, and securely connects patients with caregivers. In that shape of product, the recording, the summary prompt, and the caregiver link are all PHI paths. Encrypting the database doesn't cover the model log, and the caregiver relationship itself can reveal health information.
Testing has to follow those paths. Our approach to HIPAA compliance testing for mobile apps checks access, logging, and data handling on device, because a mobile client creates local storage and notification exposures a web-only review can miss.
<a id="a-prior-authorization-workflow"></a>
A prior-authorization workflow
Previa requires encryption, access control, and audit logging for all patient data, clinical documents, and submission records. A prior-authorization flow moves those records through intake, document handling, and payer submission as one connected process. Controls must apply to every hop rather than to a single table, because a document sitting in an unlogged intermediate step is still patient data.
<a id="a-prototype-with-no-real-records"></a>
A prototype with no real records
A healthcare and mental-health prototype built on synthetic non-sensitive data supports usability testing and stakeholder alignment without touching real ePHI. Ours costs from $3,500 and stays on synthetic data, so no business associate relationship is needed for that stage. The scope should say so explicitly, so nobody later assumes production controls were included.
Contrast the stages before you estimate. A live consultation or authorization flow needs access, audit, and transmission checks plus a stated boundary before the first real record is stored. Name every hosting, model, and messaging account before the build starts so none sits outside the compliance map.
Ask which stage you're in. Prove the flow with synthetic data, or design production controls first. Mixing the two, by testing a prototype against real records, creates obligations nobody scoped.
<a id="set-the-compliance-boundary-before-you-scope"></a>
Set the Compliance Boundary Before You Scope
Ask one decision first. Will this release create, receive, maintain, or transmit real ePHI? If yes, write the boundary before tickets and quotes. Name the data flows, the covered entity, whether a business associate agreement is required, which safeguards ship in the first release, and which risks are formally accepted.
If the work is only a prototype on synthetic non-sensitive data, say so in the scope and stop there. Don't let a demo become a pilot with real patients.
Take three actions this week.
- List every PHI field and every processor, including AI, analytics, and support tools.
- Refuse to send real records to any vendor until a signed agreement is in place.
- Hold a planning pass that records what the build will and will not claim.
Our split is plain. We offer HIPAA-compliant builds and telehealth and RPM builds, and health-tech startups get bounded MVPs and stable releases with the compliance boundary stated up front. We build HIPAA-aware, compliance-conscious systems and sign a business associate agreement where we handle ePHI, but we don't issue certifications or legal sign-off. Counsel keeps responsibility for permitted uses and for any claim that the product is compliant. You get a scoped release with an honest boundary, not a certificate.
If you're scoping a health product and need that boundary written before the build, visit Zee Palm to see how we plan HIPAA-aware apps, telehealth platforms, and bounded MVPs with safeguards scoped up front. Bring your field list and vendor list, and we'll help you turn them into a release your team and your counsel can both defend.