HIPAA compliance checklist for app development

Start with HIPAA scope, not a technology stack

A practical hipaa compliance checklist for app development starts with two questions: Does your organization have HIPAA obligations, and where does protected health information travel? Encryption, secure hosting, and a signed vendor agreement matter, but none independently makes an app HIPAA compliant.

This MyDiscussions guide translates those questions into implementation tasks and release evidence for product leaders, engineers, security teams, and procurement. Use it alongside qualified legal and compliance advice: HIPAA obligations depend on your role, contracts, workflows, and applicable rules.

HIPAA generally applies to covered entities and their business associates. A development company handling protected health information on behalf of a healthcare provider may be a business associate. A direct-to-consumer wellness app is not automatically subject to HIPAA simply because it stores health information.

However, an app outside HIPAA may still face FTC requirements, state consumer-health privacy laws, and contractual restrictions. “HIPAA does not apply” is not equivalent to “health data is unregulated.”

Step 1: Define your role and map every PHI flow

Before selecting infrastructure, document the app’s intended users, business relationships, and permitted uses of data.

Protected health information, or PHI, includes individually identifiable health information held or transmitted by a covered entity or business associate, subject to applicable exclusions. Electronic PHI, or ePHI, is the subset governed by the HIPAA Security Rule.

Scope checklist

• [ ] Identify the covered entity, business associate, and relevant subcontractors.
• [ ] Record which contracts and workflows create those relationships.
• [ ] Identify PHI fields, including identifiers connected to care, billing, or health status.
• [ ] Inventory collection, processing, storage, transmission, backup, and deletion.
• [ ] Mark trust boundaries between mobile clients, APIs, databases, vendors, and support systems.
• [ ] Assign an owner to each data flow and system.

Include less obvious destinations: push notifications, crash reports, analytics events, email, screenshots, session replay, and customer-support tickets. A patient identifier associated with a clinical appointment may be PHI even without a diagnosis.

Acceptance criterion: The team can trace a patient record from collection to final disposition, including logs, caches, exports, and backups.

Separate necessary collection from convenient collection

For each field, ask whether the app needs it to perform an authorized function. Apply HIPAA’s minimum necessary standard where applicable, recognizing that it has exceptions, including certain treatment disclosures.

Avoid collecting full dates of birth, addresses, or clinical narratives merely because a future feature might use them. Smaller datasets reduce exposure and simplify access control.

Do not assume that hashing an identifier or removing a name de-identifies a dataset. HIPAA recognizes specific de-identification methods; pseudonymized records may remain PHI.

Step 2: Perform and document a security risk analysis

A penetration test is useful, but it is not a substitute for HIPAA’s required risk analysis. The analysis must address risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI within scope.

Use the HHS Security Rule summary to anchor requirements in official guidance.

Risk-analysis checklist

• [ ] Inventory ePHI systems, infrastructure, users, and dependencies.
• [ ] Identify threats such as credential theft, ransomware, tenant crossover, device loss, and vendor compromise.
• [ ] Assess vulnerabilities in technology, procedures, facilities, and workforce practices.
• [ ] Evaluate likelihood and impact using a documented methodology.
• [ ] Assign remediation owners, deadlines, and residual-risk decisions.
• [ ] Revisit the analysis after material changes and on a defined review schedule.

NIST SP 800-66 Rev. 2 helps translate Security Rule requirements into cybersecurity activities. The NIST Cybersecurity Framework can organize governance and operational work, while OWASP ASVS provides application-security verification criteria. These frameworks support HIPAA compliance; they do not certify it.

Build a risk register with evidence links rather than a spreadsheet of unexplained “compliant” labels. For example, connect a tenant-isolation risk to authorization tests, architecture decisions, and monitoring rules.

Step 3: Evaluate vendors before sending them PHI

A business associate agreement, or BAA, establishes required responsibilities when a vendor is acting as a business associate. It does not excuse an unsafe integration or guarantee that every vendor product is eligible for PHI.

Review the HHS guidance on HIPAA and cloud computing, particularly before assuming that encrypted storage eliminates a cloud provider’s business-associate status.

Vendor-evaluation checklist

AWS, Microsoft Azure, and Google Cloud offer HIPAA-related contractual arrangements and guidance. Verify the specific services and features you intend to use; a cloud-wide marketing statement is insufficient. Consult AWS’s HIPAA compliance guidance as one example of the shared-responsibility model.

Repeat this review for authentication, observability, messaging, AI, support, and backup vendors. A secure database does not protect PHI copied into an unapproved troubleshooting platform.

Trade-off: Managed services can reduce maintenance work, but they introduce contractual dependencies, configuration obligations, and potential migration constraints. Include all three in procurement decisions.

Step 4: Implement access controls and tenant isolation

Healthcare applications often need distinct permissions for patients, clinicians, billing staff, administrators, and support personnel. Broad “staff” roles usually fail to represent those boundaries adequately.

Identity and authorization checklist

• [ ] Give workforce users unique identities; prohibit shared administrative accounts.
• [ ] Require MFA for privileged access and other risk-appropriate workflows.
• [ ] Enforce authorization on the server for every sensitive operation.
• [ ] Scope database queries and object-storage access to the authorized tenant and user context.
• [ ] Implement prompt offboarding and periodic access reviews.
• [ ] Define session expiration, revocation, and reauthentication behavior.
• [ ] Restrict service accounts and rotate credentials.
• [ ] Log and review emergency “break-glass” access where supported.

Tools such as Microsoft Entra ID, Okta, or Amazon Cognito can support identity controls, but integration design remains your responsibility. Verify contractual coverage if an identity service receives PHI, including through custom attributes.

Test object-level authorization explicitly. Changing a patient ID in a request must never expose another patient’s records. Include file downloads, background jobs, exports, and administrative endpoints.

Trade-off: Very short session timeouts can disrupt clinical work. Choose risk-based settings, use appropriate device controls, and document the rationale instead of copying arbitrary defaults.

Step 5: Protect PHI across storage, transport, and mobile devices

Under the HIPAA Security Rule framework, “addressable” implementation specifications are not simply optional. Organizations must assess them and document appropriate implementation decisions and, where applicable, equivalent alternatives.

Data-protection checklist

• [ ] Use modern TLS for external connections and protect internal PHI transfers.
• [ ] Encrypt databases, object storage, backups, and necessary local caches.
• [ ] Manage keys separately from application code using services such as AWS KMS or Azure Key Vault.
• [ ] Store application secrets in a dedicated secrets manager.
• [ ] Remove PHI from URLs, notification previews, and unnecessary logs.
• [ ] Use synthetic data for development and routine testing.
• [ ] Restrict bulk exports and apply expiration to download links.
• [ ] Define retention and secure-disposal rules by data category.

For mobile apps, minimize offline PHI. Use platform protections such as iOS Keychain and Android Keystore for appropriate credentials or key material. Review local files, operating-system backups, clipboard behavior, screenshots, and notification content.

Certificate pinning may reduce certain interception risks, but it increases certificate-rotation and recovery complexity. Evaluate it through the threat model rather than treating it as a universal HIPAA requirement.

Acceptance criterion: Engineers can demonstrate where encryption operates, who can decrypt data, and how access changes when a credential or device is compromised.

Step 6: Build auditability without creating another PHI repository

Audit controls should help reconstruct sensitive activity while limiting unnecessary data capture.

Logging and monitoring checklist

• [ ] Record authentication events, access failures, permission changes, and administrative actions.
• [ ] Capture appropriate record access, modification, export, and deletion activity.
• [ ] Include actor, timestamp, action, target reference, and outcome.
• [ ] Protect logs from unauthorized alteration or deletion.
• [ ] Restrict log access and define retention.
• [ ] Alert on suspicious exports, privileged changes, and unusual access patterns.
• [ ] Synchronize system clocks and test event correlation.

Avoid recording entire request bodies, authorization headers, clinical notes, or uploaded documents by default. Tools such as Datadog, Splunk, and cloud-native logging services require the same PHI-flow and vendor review as primary application infrastructure.

HIPAA does not prescribe one universal retention period for every application log. Certain required HIPAA documentation must generally be retained for six years; that is not a blanket six-year rule for medical records or telemetry. Establish retention with legal, security, operational, and contractual input.

Step 7: Make secure development a release requirement

Security checks work best when they are repeatable and attached to release decisions.

Engineering checklist

• [ ] Threat-model new PHI workflows and significant architecture changes.
• [ ] Require peer review for authorization and data-handling changes.
• [ ] Run static analysis with tools such as CodeQL or Semgrep.
• [ ] Scan dependencies and container images with tools such as Dependabot or Trivy.
• [ ] Detect committed secrets and block exposed credentials from deployment.
• [ ] Test web APIs against appropriate OWASP ASVS controls.
• [ ] Use OWASP MASVS for mobile-specific verification.
• [ ] Conduct risk-based penetration testing and track remediation.
• [ ] Protect CI/CD credentials and production deployment permissions.

Prioritize findings by exploitability and PHI impact, not scanner severity alone. An authorization bypass affecting patient records may deserve faster action than a high-scoring vulnerability in an unreachable development dependency.

Keep production PHI out of CI artifacts, screenshots, issue trackers, and AI coding prompts unless the workflow has been explicitly approved and appropriately safeguarded.

Step 8: Prepare operational, privacy, and incident procedures

HIPAA compliance extends beyond security controls. The app must support applicable Privacy Rule obligations and the organization’s incident response, workforce, and contingency processes.

Operational readiness checklist

• [ ] Designate responsible privacy and security officials as applicable.
• [ ] Train personnel before granting access to PHI.
• [ ] Document acceptable use, sanctions, offboarding, and access-review procedures.
• [ ] Address physical access, workstation safeguards, and device disposal.
• [ ] Establish backup, disaster recovery, and emergency-mode procedures.
• [ ] Set business-appropriate recovery objectives and test restoration.
• [ ] Maintain an incident response plan with vendor and legal contacts.
• [ ] Support applicable access, amendment, and disclosure-accounting workflows.

A successful backup job is not proof of recoverability. Test restoration into a controlled environment and verify application functionality, access controls, and data integrity.

Incident playbooks should distinguish security incidents from reportable breaches. HIPAA breach-notification deadlines vary by recipient and circumstance; required notifications generally must occur without unreasonable delay, with specified outer limits for certain notices. Contracts may require much faster escalation. Have counsel validate the decision tree before an incident occurs.

Step 9: Require evidence-based launch approval

Release approval should verify operating controls, not just planned work.

Unresolved critical authorization flaws, missing required BAAs, unknown PHI destinations, or untested recovery capabilities are strong reasons to delay launch. A business sign-off does not waive legal obligations.

Reassess after adding vendors, integrations, AI features, exports, or new care workflows. For related implementation resources, browse more Checklists topics.

Common mistakes that undermine compliance

• Treating a BAA as certification: It allocates obligations; it does not validate your code.
• Assuming SOC 2 equals HIPAA compliance: Useful assurance is not interchangeable with HIPAA-specific requirements.
• Adding tracking tools without review: Analytics and session replay can expose sensitive patient interactions.
• Confusing consent with authorization: Generic terms or cookie consent do not automatically satisfy HIPAA authorization requirements.
• Documenting controls that do not operate: Policies need implementation evidence and accountable owners.
• Treating launch as the finish line: Access reviews, training, vendor oversight, and risk management continue throughout the app lifecycle.

Frequently asked questions

Can an app be officially HIPAA certified?

HHS does not provide an official HIPAA certification for apps. Private assessments can help evaluate controls, but they do not eliminate liability or guarantee compliance. Evaluate their scope, methods, and evidence rather than relying on a badge.

Does every health app need to comply with HIPAA?

No. Applicability depends on the entities involved and the app’s relationship to covered entities or business associates. Consumer health apps may fall outside HIPAA while remaining subject to other privacy and breach-notification laws.

Is a HIPAA-eligible cloud service enough?

No. You still need applicable agreements, appropriate configurations, secure application code, workforce safeguards, and documented processes. Eligibility also may not extend to every feature or integration offered by that provider.

What should be completed before the first production patient uses the app?

Complete the scope assessment, risk analysis, necessary BAAs, access controls, data protection, audit logging, recovery testing, workforce training, and incident procedures. Verify applicable privacy workflows, resolve launch-blocking findings, and retain evidence supporting the release decision.