Last updated: March 2026

This HIPAA compliance checklist covers the technical, physical, and administrative safeguards required under the HIPAA Security Rule for systems that store, process, or transmit protected health information. It's organized by who owns each requirement: some controls belong to your hosting infrastructure, some to your application code, and some to your organization's policies and procedures.

Working through it tells you where you have gaps. Closing the gaps is how you get compliant.

This is a technical checklist for engineering and product organizations. It does not cover Privacy Rule requirements (notice of privacy practices, patient rights), billing rules, or workforce training administration. Those are real obligations but belong to a different owner.

Before you start: scope and definitions

What is PHI?

Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate. That means any data that could identify a person AND relates to their health condition, care, or payment for care. Names, dates of birth, geographic data below state level, email addresses, phone numbers, medical record numbers, and IP addresses can all qualify as PHI when combined with health information.

Data that has been de-identified under HIPAA's Safe Harbor method (removal of 18 specific identifiers) or Expert Determination standard is no longer PHI and falls outside HIPAA's scope. If you're sending data to an LLM or analytics tool without a BAA, de-identification is how you stay legal. If you have a BAA, you don't need to de-identify.

Are you a covered entity or a business associate?

Covered entities are healthcare providers, health plans, and healthcare clearinghouses. If you're a health tech startup building software for covered entities, you're almost certainly a business associate. The practical difference: covered entities have additional Privacy Rule obligations. Both are subject to the Security Rule requirements on this checklist.

Required vs. addressable implementation specifications

HIPAA distinguishes between required specifications (no discretion; you must implement them) and addressable ones (you must assess whether implementation is reasonable and appropriate for your risk profile; if not, document why and implement an equivalent alternative). In practice, every addressable specification on this list is appropriate for production healthcare workloads. "Addressable" does not mean optional.

Shared responsibility

Your hosting platform handles some of these controls by default. You handle others at the application and organizational layer. A managed HIPAA platform reduces what you need to build and document, but it doesn't eliminate your responsibilities. Know which side of the line each item falls on before you start.

Technical safeguards (45 CFR §164.312)

Technical safeguards are the controls most directly tied to infrastructure and code decisions. These are where platform choice matters most.

Physical safeguards (45 CFR §164.310)

For cloud-hosted workloads, most physical safeguards transfer to your hosting provider. Your job is to verify they're in place, not implement them yourself.

[ ] Data center physical access controls: your provider's facilities have documented access restrictions, surveillance, and visitor procedures. Request their SOC 2 Type II report; Section 9 (Physical and Environmental Security) documents this. Type II validates that controls operated over time. Type I only validates their design, which is not sufficient for due diligence.

[ ] Workstation security policy: only authorized personnel can access workstations that reach PHI. This covers employee laptops and any hardware in your offices.

[ ] Device and media disposal: documented procedures for disposing of hardware and media that held PHI. For cloud workloads this is largely the provider's responsibility. For employee devices, you own it.

[ ] Full-disk encryption on employee devices: any laptop with access to PHI systems should have FileVault (macOS) or BitLocker (Windows) enabled and enforced.

[ ] Mobile device policy: if employees or users access PHI on mobile devices, either prohibit it or enforce MDM with remote wipe capability.

Administrative safeguards (45 CFR §164.308)

Administrative safeguards are your organization's responsibility. No hosting platform covers these. They're also what auditors spend the most time reviewing.

[ ] Risk assessment completed and documented: a documented analysis of risks to PHI confidentiality, integrity, and availability. This is a required specification, not an addressable one. It must be redone when systems or threats change materially.

[ ] Risk management plan: documented actions to reduce risks identified in the assessment, with timelines and owners. Updated annually at minimum.

[ ] Workforce authorization: every person with PHI access has a defined role with documented justification. Access is role-based, not individual.

[ ] HIPAA training completed: all workforce members with PHI access have completed HIPAA privacy and security training. This includes contractors.

[ ] Training records maintained: completion dates, materials used, and participant names are documented and retained.

[ ] Access review conducted regularly: a periodic audit of who has access to what. Active users only; no stale accounts from departed employees or contractors. Quarterly is a commonly adopted cycle but not a required standard.

[ ] Offboarding checklist: PHI access revoked on the employee's last day, not whenever someone gets around to it. This includes VPN, hosting platform access, database credentials, and any shared accounts.

[ ] Security incident procedures: a written runbook for how incidents are detected, escalated, contained, and documented. Verbal processes don't hold up in audits.

[ ] Breach response process documented: who decides if something is a breach, how you notify HHS, how you notify affected individuals. Timeline: 60 days from discovery. Many enterprise customers and hosting providers require shorter timelines from you.

[ ] Contingency plan: documented backup procedures, disaster recovery process, and emergency access. Must be tested. "We have backups" is not a contingency plan.

[ ] Internal audit schedule: a recurring review of whether controls are operating as documented. Once a year minimum.

Business Associate Agreements

A BAA is required before any vendor creates, receives, transmits, or maintains PHI on your behalf. No BAA means no legal basis for sharing PHI with that vendor. This applies to your hosting provider, your LLM provider, your logging service, your error monitoring tool, and any other third party that touches patient data.

[ ] BAA in place with every vendor that touches PHI: this includes your hosting provider, database provider, logging service, email provider, and any AI/LLM API you send PHI to.

[ ] BAA scope verified: some BAAs cover only specific service tiers or products. Confirm the agreement covers the exact services you're using. A BAA that covers your hosting plan but not your logging add-on has a gap.

[ ] Subcontractor coverage confirmed: your provider's BAA should require equivalent obligations from their own subcontractors. If it doesn't, their AWS or GCP dependency creates a gap.

[ ] Breach notification timeline documented: HIPAA requires your provider to notify you within 60 days of discovering a breach. The better providers commit to 2 days. Know what your providers commit to and factor it into your own response timeline.

[ ] Vendor inventory maintained: a running list of every vendor with PHI access, their BAA status, and last review date.

[ ] New vendors: BAA before PHI: the BAA must be in place before PHI flows to the vendor. Not afterward.

For a detailed breakdown of what a BAA must contain and what to watch for, see What is a HIPAA BAA.

Application-layer controls

This is where most compliance gaps actually live. Your hosting platform enforces infrastructure controls. Your application code is your responsibility.

[ ] PHI not logged in plain text: application logs often capture more than developers intend. Request parameters, error messages, and debug output can contain patient names, dates, or identifiers. Audit what your logging framework captures.

[ ] PHI scrubbed from error messages: stack traces and exception messages can include PHI if your error handling isn't careful. Test this explicitly.

[ ] No PHI in URLs or query parameters: PHI in URLs ends up in server logs, browser history, referrer headers, and analytics tools. Use POST bodies or encrypted tokens for anything that includes patient identifiers.

[ ] No PHI in analytics tools without a BAA: Google Analytics, Mixpanel, Segment, and similar tools do not sign BAAs by default. If any PHI reaches them, you have a violation. Audit your tracking events.

[ ] Authentication on every PHI endpoint: every API endpoint that returns or accepts PHI requires authentication. No exceptions for "internal" endpoints if they're network-accessible.

[ ] Input validation on PHI-handling endpoints: validate and sanitize all inputs that could reach PHI storage or retrieval logic.

[ ] Dependency scanning active: vulnerabilities in third-party libraries are a common breach vector. Dependabot or equivalent should be running on every PHI-handling repository.

Before your first audit

Compliance is the art of proving to outsiders that you're doing what you say you're doing. Auditors want to see evidence, not assertions.

[ ] Shared responsibility model documented: a written breakdown of which controls your platform handles and which ones you own. Your hosting provider should have this document; ask for it. Aptible publishes its division of responsibilities here.

[ ] Third-party certifications obtained from provider: request your provider's SOC 2 Type II report and any HITRUST certification documentation. These become evidence in your own audit package.

[ ] Compliance evidence organized: audit logs, access review records, training completion records, risk assessment, and incident response runbooks in one place. When an auditor asks, you need to produce evidence within hours, not days.

[ ] Data flow diagram exists: a diagram showing where PHI enters your system, where it's stored, who can access it, and where it exits. This is what auditors use to determine your audit scope. If PHI scope is larger than you thought, so is your audit.

Code examples

The checklist items above describe what's required. These snippets show what a few of them look like in practice.

PHI access logging (Python)

import json
import logging
from datetime import datetime, timezone

audit_logger = logging.getLogger("phi_audit")

def log_phi_access(user_id: str, action: str, resource_id: str, ip_address: str) -> None:
    entry = {
        "timestamp": datetime.now(timezone.utc).isoformat(),
        "user_id": user_id,
        "action": action,           # READ | WRITE | DELETE | EXPORT
        "resource_id": resource_id,
        "contains_phi": True,
        "ip_address": ip_address,
        "retention_policy": "6_years_minimum",
    }
    # This logger must write to encrypted, access-controlled, immutable storage.
    # Application logs and audit logs should not share the same sink.
    audit_logger.info(json.dumps(entry))

The logger destination matters as much as the log content. Logs that contain PHI must be encrypted at rest, isolated from general application logs, and retained for the required period. For a full implementation including log drain configuration, see HIPAA Hosting Requirements.

Session timeout

For a session timeout implementation with notes on the session store requirements, see Hosting Requirements.

PHI pattern scrubbing (Python)

import re

# Extend these patterns for your specific PHI types.
# This is a starting point, not a complete de-identification pipeline.
PATTERNS = [
    (re.compile(r'\\\\b\\\\d{3}-\\\\d{2}-\\\\d{4}\\\\b'), '[SSN]'),
    (re.compile(r'\\\\bMRN[:\\\\s]?\\\\d{6,10}\\\\b', re.IGNORECASE), '[MRN]'),
    (re.compile(r'\\\\b[A-Z][a-z]+ [A-Z][a-z]+\\\\b'), '[NAME]'),  # Naive name pattern
]

def scrub_phi(text: str) -> str:
    for pattern, replacement in PATTERNS:
        text = pattern.sub(replacement, text)
    return text

Regex-based scrubbing catches known patterns. It doesn't catch freeform clinical notes, context-dependent identifiers, or novel PHI. For LLM use cases, a more robust de-identification pipeline is necessary. See HIPAA-Compliant AI: What Developers Need to Know.

What's not on this checklist

This checklist covers the Security Rule requirements most relevant to a development organization. It does not cover:

Privacy Rule obligations: Notice of Privacy Practices, patient rights to access and amend their records, minimum necessary standards for disclosures. These apply to covered entities and involve legal and administrative work beyond infrastructure.

Breach notification letters: if a breach occurs and notification is required, the content, format, and delivery of those letters involves legal counsel. This checklist gets you to the point of knowing when a breach occurred and having the evidence to investigate it.

HITECH accounting of disclosures: covered entities must track and provide an accounting of certain PHI disclosures on patient request. The requirements depend on your role and specific use cases.

HITRUST certification: HITRUST is an assurance framework, not a HIPAA requirement. If your customers are asking for it, see When to Invest in HIPAA Compliance for a stage-based breakdown of when it makes sense.

FAQs

What does a HIPAA compliance checklist need to cover?

HIPAA compliance for a software organization spans three categories of controls under the Security Rule: technical safeguards (encryption, access controls, audit logging), physical safeguards (data center controls, device security), and administrative safeguards (risk assessment, workforce training, incident response). Beyond the Security Rule, any organization handling PHI must have Business Associate Agreements in place with every vendor that touches patient data, and applications must prevent PHI from leaking into unauthorized systems. A complete checklist covers all of these areas and identifies which controls belong to your hosting platform and which belong to your organization.

What's the difference between required and addressable HIPAA specifications?

HIPAA's Security Rule divides implementation specifications into two categories. Required specifications are non-negotiable: you must implement them. Addressable specifications require you to assess whether implementation is reasonable and appropriate given your risk profile; if not, you must document that decision and implement an equivalent alternative. In practice, every addressable specification on this checklist is appropriate for production systems handling PHI. "Addressable" is not a synonym for "optional." Treating it that way is one of the most common compliance mistakes in healthcare software.

Do I need a BAA with every vendor that touches PHI?

Yes. HIPAA requires a signed Business Associate Agreement before any vendor creates, receives, transmits, or maintains PHI on your behalf. This applies to your hosting provider, database provider, logging service, error monitoring tool, email provider, and any AI or LLM API you send patient data to. The BAA must be in place before PHI flows to the vendor, not after. Vendors that cannot or will not sign a BAA cannot be used for any workload that touches PHI. For what a BAA must contain and what to watch for in vendor agreements, see What is a HIPAA BAA.

What counts as PHI under HIPAA?

Protected health information is individually identifiable health information held or transmitted by a covered entity or business associate. A piece of data qualifies as PHI when it could identify a person AND relates to their health condition, care, or payment for care. HIPAA identifies 18 categories of identifiers that can create PHI in combination with health information: names, geographic data below state level, dates other than year, phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate and license numbers, URLs, IP addresses, biometric identifiers, full-face photographs, vehicle identifiers and serial numbers, device identifiers and serial numbers, and any other unique identifying number or characteristic. Data that has been properly de-identified under HIPAA's Safe Harbor or Expert Determination standards falls outside HIPAA's scope.

How do I know if my application is HIPAA compliant?

There is no official HIPAA certification. No government body audits your application and issues a compliance certification. What HIPAA requires is that you implement and maintain appropriate safeguards, document that you've done so, and can demonstrate it when asked. In practice, this means your infrastructure controls are in place and evidenced (encryption, audit logs, access controls), you have BAAs with every vendor that touches PHI, your policies and procedures are documented and followed, and you've completed a risk assessment. The practical test: can you answer an enterprise customer's security questionnaire with real documentation? If you can't produce evidence quickly, you are not compliant in any meaningful operational sense.

Does HIPAA compliance mean my application is secure?

Not necessarily. HIPAA compliance establishes a floor of required controls. It does not guarantee a strong security posture. A system can technically satisfy each HIPAA specification while still being vulnerable, for example by having an audit logging tool installed but configured to capture nothing meaningful, or implementing encryption without key rotation. Compliance is about demonstrating that defined controls exist and operate. Security is about whether those controls meaningfully reduce risk. The goal is both: controls that are genuinely effective, and documented well enough to survive an audit.

Next Steps

Starting a compliance program: The HIPAA Compliance Guide for Startups covers the regulatory background, who HIPAA applies to, and how to scope your compliance program before you start implementing controls.

Infrastructure depth: HIPAA Hosting Requirements goes deeper on the technical safeguard requirements, with code examples for TLS configuration, audit logging, and network architecture, and a full breakdown of what to require from a hosting provider.

BAA specifics: What is a HIPAA BAA covers what must be in a BAA, what to watch out for, and how to evaluate whether a vendor's agreement actually protects you.