HIPAA Requirements: A Practical Checklist

If you're a digital health company selling into the US market, "HIPAA compliant" is probably sitting in a security questionnaire right now, waiting for an answer. The problem is that HIPAA isn't a certification you can buy off the shelf. There's no HIPAA badge, no accredited auditor stamping a report the way there is with SOC 2. It's a federal law with a set of rules, and "compliance" means you can show, with evidence, that you've met them.

This checklist covers what's actually required under the HIPAA Privacy Rule, Security Rule, and Breach Notification Rule. It's written for founders and engineering leads at digital health startups who need to know what a buyer, partner, or auditor will expect to see, not what a vendor wants to sell you.

1. Determine if you're actually a covered entity or business associate

Before you build a compliance program, confirm HIPAA applies to you. If you create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity (a health plan, provider, or clearinghouse), you're almost certainly a business associate. Most digital health SaaS companies fall here. This matters because it determines which contracts you need and which rules apply directly to you versus flow down through agreements.

2. Sign Business Associate Agreements (BAAs) with every relevant party

A BAA is a contract that obligates you to protect PHI the same way the law requires. You need one with:

• Every covered entity customer that shares PHI with you
• Every subcontractor or subprocessor that touches PHI on your behalf (cloud hosting, analytics, backup providers, email services if PHI passes through)

Missing a BAA with a subprocessor is one of the most common gaps we see. If your infrastructure vendor won't sign one, that's a disqualifying finding, not a negotiation point.

3. Conduct and document a Security Risk Assessment

This is the requirement most digital health teams underestimate. The Security Rule requires a documented, periodic risk assessment that identifies where PHI lives, how it flows through your systems, and what could go wrong. It's not a one-time checkbox. It needs to be revisited when your architecture changes and reviewed on a regular cadence. Auditors and enterprise buyers will ask to see the actual document, not just hear that you did one.

4. Implement the required administrative safeguards

• Assign a Security Officer and Privacy Officer (can be the same person at a small company) with clear accountability
• Workforce training on HIPAA obligations, documented and repeated at least annually
• Sanction policy for employees who violate PHI handling rules
• Access management procedures that grant PHI access based on role, not by default
• Incident response plan specific to PHI, tested rather than just written

5. Implement the required technical safeguards

• Access controls: unique user IDs, role-based permissions, automatic logoff
• Audit controls: logging of who accessed or modified PHI and when
• Encryption of PHI at rest and in transit (not strictly mandated as "required" in every case under the letter of the rule, but treated as the practical baseline by every buyer and auditor we've seen)
• Integrity controls to prevent improper alteration or destruction of PHI
• Transmission security for PHI moving across networks, including APIs and third-party integrations

6. Implement physical safeguards

Even for a cloud-native company, this section still applies. Document facility access controls for any offices, workstation security policies, and device and media controls covering laptops, backups, and decommissioned hardware. If you rely entirely on a cloud provider's data centre, your BAA with them covers the physical layer there, but you still need policies for your own offices and employee devices.

7. Build a breach notification process

The Breach Notification Rule sets hard deadlines: affected individuals must be notified without unreasonable delay and no later than 60 days after discovery, and breaches affecting 500 or more individuals must also be reported to Health and Human Services and, in some cases, the media. You need a defined process to determine whether an incident qualifies as a reportable breach, who makes that call, and how notifications go out. Waiting until an incident happens to figure this out is how deadlines get missed.

8. Handle Privacy Rule obligations if you touch patient-facing data directly

If your product interacts with patients directly rather than purely through a covered entity's workflow, review Privacy Rule obligations around minimum necessary use, patient access rights to their own records, and accounting of disclosures. Not every business associate needs a full Privacy Rule program, but it's worth confirming rather than assuming you're exempt.

9. Keep evidence, not just policies

A binder of policies nobody follows is worse than no binder at all, because it creates a paper trail showing you knew the requirement and didn't operate against it. Buyers, and any actual HHS investigation, want to see risk assessments with dates, training records with names, access reviews with logs, and incident response plans that reference real tooling. This is the evidence layer that separates a HIPAA program on paper from one that would survive scrutiny.

Where this fits with SOC 2

Most digital health companies selling to US healthcare organizations end up needing both HIPAA readiness and a SOC 2 report, because enterprise health systems and payers ask for both. The good news is the underlying control work overlaps heavily: access management, encryption, incident response, vendor management, and risk assessment all serve both frameworks. Running them together means you build the evidence once and map it to both sets of requirements, instead of duplicating the work twice on two separate timelines.

We cover how this works in more detail, including where HIPAA and HITRUST diverge and why we scope our engagements to readiness rather than a full HITRUST certification, on our HIPAA compliance for digital health page. If you're also weighing where HIPAA fits against a broader compliance roadmap, our compliance solutions overview lays out how we sequence multiple frameworks for growing health tech companies.

Get a straight answer on where you stand

If you're not sure whether your current controls would hold up against this checklist, or you're trying to figure out how to sequence HIPAA readiness alongside SOC 2 without duplicating the work, talk to us. We'll give you a plain assessment of the gaps and what it actually takes to close them. Contact traztech to get started.

Required versus addressable, and why "addressable" is not "optional"

The Security Rule splits implementation specifications into required and addressable, and the second word has done more damage to digital health security programs than any other in the regulation. Addressable does not mean you can skip it. It means you must assess whether the specification is reasonable and appropriate for your environment, and if you decide it is not, you must document why and implement an equivalent alternative measure that achieves the same purpose. Skipping the control and skipping the documentation is the failure mode, and it is the one that turns a technical gap into a demonstrable compliance violation.

Encryption at rest is the classic example. It is addressable, so a team decides it is not required, implements nothing, records nothing, and then loses an unencrypted laptop. At that point there is no risk analysis showing the decision was considered, no alternative control, and the incident is now both a breach and evidence of a deficient program. The cost of doing this properly is one paragraph in your risk analysis per addressable specification you decline. Write the paragraphs.

The BAA clauses that actually cost money

Everyone knows they need Business Associate Agreements. Far fewer teams read the ones they sign, and the terms that hurt are rarely the ones about safeguards.

Breach notification timing. The regulation gives a business associate up to 60 days to notify the covered entity. Enterprise health systems routinely write 24 hours, 48 hours, or "immediately upon discovery" into their template. If you sign a 24-hour clause you have committed to a triage capability most startups do not have, on a clock that starts at discovery by any workforce member, not at confirmation by your security lead. Negotiate to five business days if you can, and if you cannot, build the on-call rota before you sign.

Indemnity and liability caps. Health system templates frequently carve breach liability out of the general cap. Uncapped breach indemnity on a contract worth $80,000 a year is a real exposure, and it is the clause your cyber insurer will ask about at renewal.

Audit and inspection rights. Some templates grant the covered entity the right to conduct on-site audits with limited notice. That is manageable once. It is not manageable across forty customers, which is the point at which you need a SOC 2 report to redirect the demand.

Subcontractor flow-down. You are obligated to bind your own subprocessors to equivalent terms. If you signed a 24-hour notification clause upstream, you need something faster than that downstream, and most infrastructure vendors will not give it to you. Reconcile the two before you promise the customer anything.

Tracking technologies, the gap that catches digital health first

The single most common finding we see on a first pass through a digital health product has nothing to do with infrastructure. It is analytics. Marketing installs a pixel or a session recording tool, it ends up on an authenticated patient-facing page, and identifiable information about an individual's health condition starts flowing to an advertising platform that has not signed a BAA and would not sign one if asked.

The Office for Civil Rights has been explicit that individually identifiable health information collected by tracking technologies on user-authenticated pages is protected, and that the combination of an IP address with a page visit relating to a health condition can be enough on its own. The practical consequences are unglamorous. Inventory every script that runs on any authenticated surface. Separate your marketing site from your application domain so marketing tooling cannot reach authenticated pages by accident. Route product analytics through a vendor that signs a BAA, or self-host it. Strip identifiers and condition-revealing URL parameters before anything leaves your boundary. And put a control in the release process so a well-meaning growth hire cannot reintroduce the problem in a single pull request.

This one is worth checking today rather than at your next assessment, because remediating it is cheap and the disclosure that has already happened is not reversible.

De-identification is narrower than your team believes

"We de-identify the data" is said far more often than it is true. HIPAA recognizes exactly two methods. Safe Harbor requires removal of all eighteen listed identifier categories, which includes dates more precise than the year, ages over 89, geographic subdivisions smaller than a state with under 20,000 people, device identifiers, URLs, IP addresses, and any other unique identifying characteristic. Expert determination requires a qualified statistician to document that the re-identification risk is very small, and that determination has to be revisited when the data or the context changes.

Hashing a patient identifier is not de-identification, because the hash remains a unique code derived from the identifier. Removing names while keeping full dates of birth and postal codes is not de-identification. If your product roadmap depends on using aggregate data for model training or benchmarking, get the determination done properly and keep the report, because the first enterprise customer whose data feeds it will ask to see it, and the answer "we removed the direct identifiers" will not survive their privacy office.

What an OCR investigation actually looks like

Most enforcement begins with a complaint or a breach report, not a random audit. What arrives is a data request letter with a response deadline, typically asking for the same short list: your current risk analysis and the two preceding versions, your risk management plan, your policies with effective dates, workforce training records, the BAA with the relevant party, your audit logs for the period in question, and your breach determination documentation.

Notice what dominates that list. It is documentation with dates, not architecture. The most frequently cited deficiency in resolution agreements is a failure to conduct an accurate and thorough risk analysis across the whole environment where electronic protected health information lives, and the second most common is failing to act on the risks the analysis identified. Both are documentation and follow-through failures rather than technology failures.

Retention matters here too. HIPAA requires required documentation to be kept for six years from creation or last effective date, which is longer than most startups keep anything. That includes retired policies. Do not delete the old version when you publish a new one; archive it with its effective dates, because a request letter will ask what was in force at the time of the incident.

The proposed Security Rule changes

HHS has proposed a substantial update to the Security Rule, and while the final form is not settled, the direction is clear enough to plan around. The proposal would remove the required and addressable distinction and make most specifications mandatory, require multi-factor authentication broadly, require encryption of protected health information at rest and in transit, require a maintained asset inventory and network map, require network segmentation, mandate vulnerability scanning and annual penetration testing, and set a target for restoring critical systems after an incident.

If you build to that list now, you are building to where the regulation is heading and, not coincidentally, to what enterprise buyers already ask for in questionnaires. None of it is exotic. The asset inventory and network map are the items most teams do not have, and they are also the items that make everything else easier to evidence.

State laws and the Canadian equivalent

HIPAA is a floor, not a ceiling. Several states impose stricter obligations, and consumer health data laws now reach companies that are not covered entities or business associates at all: Washington's My Health My Data Act attaches consent requirements to consumer health data with a private right of action attached, and California's confidentiality rules for medical information apply to some app developers directly. If your product touches reproductive, mental health, or substance use data, assume the state layer is the binding constraint rather than HIPAA.

North of the border the analogue is provincial. Ontario's PHIPA governs health information custodians and their agents, and it uses different vocabulary for similar obligations, with mandatory reporting to the Information and Privacy Commissioner in defined circumstances. A company selling into both markets should build one control set and map it twice rather than running two programs, which is how we structure the work on our HIPAA and PHIPA readiness engagements.

How buyers verify a HIPAA claim

Since there is no certificate, buyers fall back on proxies. In practice they ask for one of four things: a SOC 2 Type II report with HIPAA-mapped criteria included, a HITRUST certification, a third-party HIPAA readiness assessment letter, or a completed questionnaire backed by your risk analysis and policy set. The first is the best value for most digital health companies, because a SOC 2 report answers the general security questions and the HIPAA mapping answers the regulatory ones, from one body of evidence. HITRUST carries more weight with large payers and health systems, and costs considerably more.

Whatever you provide, keep the artefacts current. A risk analysis dated two years ago undermines everything attached to it.

When you should not buy HIPAA readiness from us

If you are pre-revenue with no signed healthcare customer and no PHI in your systems yet, do not buy a readiness engagement. Choose infrastructure that can be configured compliantly, sign BAAs with your cloud and email providers, keep production data access limited and logged, and revisit when a real deal is in front of you. The architectural decisions are what constrain you later; the documentation can be produced in weeks.

If your only requirement is a single enterprise questionnaire and you have an in-house lead who can write policy, buy an hour of review rather than a program. We would rather tell you the four gaps that matter than sell you a full assessment that finds the same four.

And if you are being pushed toward HITRUST by a vendor and your customers have not asked for it, push back. Certification is expensive, and buyers who ask for HIPAA compliance are usually satisfied by readiness evidence plus SOC 2. Our compliance work starts by testing which artefact your buyer actually needs, and a scoping conversation costs nothing if the honest answer turns out to be that you need less than you were told.