If you build or operate software that touches protected health information on behalf of someone else, you are almost certainly a HIPAA Business Associate, and that carries direct federal liability. This play is about execution: turning the law and your signed Business Associate Agreement into a finite list of work products you can produce, store, and hand to an auditor. It builds on the broader idea in Right-Size Security by Data Sensitivity and the response mechanics in Incident Response and Severity Classification, but focuses on the specific evidence machine HIPAA demands.

When to use this play#

Run this play whenever you create, receive, maintain, or transmit protected health information (PHI) for a covered entity or another business associate. Building the application is not the only trigger. If your team operates the infrastructure, configures the database, holds production credentials, or your engineers can pull real patient data onto a laptop for debugging, you are in scope.

Two documents govern everything:

• The law. The HIPAA Privacy Rule, Security Rule, Breach Notification Rule, and HITECH Act. HITECH makes you directly liable for Security Rule violations, with enforcement from federal regulators and state attorneys general.
• The BAA. Your signed agreement frequently imposes stricter obligations than the statutory defaults, especially on notification timelines. Read it as the binding contract it is.

A key liberating fact: both the Security Rule and most BAAs are technology-neutral. They require "reasonable and appropriate" safeguards, not a specific encryption algorithm or vendor. You choose the implementation and document why it is reasonable. Do not invent obligations the agreements do not contain. If a framework like HITRUST is not referenced in the BAA, MSA, or SOW, you are not contractually bound to it.

How to run it#

1. Map your real obligations. Read the BAA line by line and extract every concrete duty and deadline. Watch for timelines that beat the statutory defaults. It is common to see security-incident reporting in a few business days and breach-of-unsecured-PHI notification in around ten calendar days, far tighter than the 60-day statutory ceiling. Also capture response windows for accounting of disclosures, access and amendment requests, the cure period for material breach, and the obligation to provide proof of compliance on request.

2. Designate a Security Officer. HIPAA requires a named individual. This cannot be "everyone's job." Give them time, authority, and ownership of the evidence program.

3. Run the Risk Analysis first. This is the single most enforced provision and the foundation of everything else. Inventory every asset that stores, processes, or transmits PHI: servers, databases, object storage, backups, developer endpoints, remote-access paths, CI/CD pipelines with production reach, and communication tools where PHI could leak. Identify threats and vulnerabilities per asset, rate likelihood and impact, and prioritize. Then write a Risk Management Plan that names a mitigating control, an owner, and a timeline for each risk.

4. Build the incident response capability next. Because BAA notification clocks are short, you need to know exactly what to do before an incident occurs. Bake the contractual timelines, the breach-risk-assessment process, the partner's contact protocol, evidence preservation, and cost-allocation awareness into a written plan plus an incident log.

5. Flow obligations down to subcontractors. Any non-employee who handles PHI on your behalf is a subcontractor needing an equivalent BAA. Inventory them, execute BAAs, and for each one decide whether they actually touch PHI. If a contractor can be architected away from PHI with synthetic test data and no production access, document that control. Anyone who will not sign and cannot be removed from PHI access gets access revoked. No exceptions.

6. Produce the rest of the evidence. Work through the Security Rule's administrative, physical, and technical safeguards plus the documentation requirements, treating each as a discrete work product with named evidence. You can combine many into a single policy document (one access-control policy can satisfy several sections), but every individual requirement must be independently findable by an auditor.

The evidence checklist, grouped:

• Administrative: risk analysis and management, workforce authorization and termination procedures, access management, security training and reminders, incident procedures, contingency plans (backup, disaster recovery, emergency mode, testing), periodic evaluation, and subcontractor BAAs.
• Physical: workstation use and security policies and device/media disposal and reuse procedures, focused on endpoints for a remote workforce.
• Technical: unique user IDs, emergency (break-glass) access, automatic logoff, encryption at rest and in transit, audit logging and a log-review process, integrity controls, and an authentication policy.
• Documentation: written, accessible policies, a six-year retention scheme, and a review/update process.
• BAA-specific: a PHI inventory and data-flow map, a disclosure log, access/amendment request procedures, a PHI return-or-destroy procedure for termination, a partner communication protocol, and a pre-assembled proof-of-compliance package.

7. Store and operate it. Keep everything in a central, version-controlled repository configured for six-year retention. Several requirements are recurring processes, not one-time documents: access reviews, log reviews, training, risk-analysis updates, and contingency testing all generate ongoing dated evidence.

Common traps#

• Treating "reasonable and appropriate" as "do everything." Let the Risk Analysis decide what is needed, then document your reasoning. Over-building burns effort you could spend on real exposures.
• Inventing requirements the agreements never imposed. If HITRUST or specific technical standards are not in your governing documents, you are not bound to them.
• Shadow PHI in your own tools. An engineer pasting a stack trace with patient data into chat, a ticket, an email, or an AI prompt has just handed PHI to a vendor that now needs a BAA. Train against this explicitly.
• Production data on developer laptops. Real PHI pulled down for debugging is PHI on an endpoint with potentially zero controls. Use synthetic data and lock down access.
• Building to the 60-day statutory clock when your BAA says three days. The contract wins. Design incident response around the tightest deadline you signed.

Signals it's working#

• You have a current, dated Risk Analysis with a named author, and a Risk Management Plan that ties every risk to an owner and a control.
• Every subcontractor who touches PHI has an executed BAA, and access removal is provable for every departure.
• Your incident response plan is built around the BAA's actual notification clocks, and you could meet them under pressure.
• Asked for proof of compliance, you can hand over a pre-assembled package in days, not scramble for weeks.
• Recurring reviews are actually happening on schedule and leaving a dated trail, not sitting as good intentions in a policy document.

Compliance does not eliminate risk. It reduces it to a level that is defensible, documented, and monitored, which is exactly what an auditor and a healthcare partner are looking for.