HIPAA readiness checklist for healthcare SaaS engineering teams

Last substantive review: August 2026.

A healthcare SaaS team can have encrypted databases, multifactor authentication, and a signed cloud agreement and still be unprepared for a customer security review. The missing work is often at the boundaries: ePHI reaches an analytics tool nobody inventoried, support access bypasses the normal role model, a backup has never been restored, or no one can produce the last access review.

This checklist treats HIPAA readiness as an engineering and evidence problem. It helps a CTO turn requirements and risk decisions into system boundaries, controls, tests, owners, and records. It does not determine whether an organization is a covered entity or business associate, certify HIPAA compliance, replace a formal risk analysis, or provide legal advice. Make applicability, contract, policy, and compliance decisions with qualified counsel and the people accountable for privacy and security in your organization.

Use the current rule, not a proposed rule, as the legal baseline

The HHS Office for Civil Rights overview of the HIPAA Security Rule says the rule requires appropriate administrative, physical, and technical safeguards for the confidentiality, integrity, and availability of ePHI created, received, maintained, or transmitted by covered entities and business associates.

HHS issued a proposed Security Rule update on December 27, 2024; it was published in the Federal Register on January 6, 2025. As of this review, HHS still identifies that change as a proposed rule and says the current Security Rule remains in effect. Engineering teams can evaluate proposed controls as prudent preparation, but a roadmap should not label a proposal as current law. Track the rulemaking, customer contracts, state requirements, and other obligations separately so a change in one source does not silently rewrite every control.

For implementation help, NIST SP 800-66 Revision 2 maps Security Rule standards and implementation specifications to NIST resources. NIST describes it as practical guidance and resources for safeguarding ePHI and understanding the rule. The publication does not itself determine whether an organization complies.

Define the readiness outcome

A useful readiness review should leave the team with more than a pass or fail. At minimum, it should produce:

• an approved ePHI data-flow and system inventory;

• a vendor register with service boundaries, contract status, and accountable owners;

• a current risk analysis and a risk-treatment backlog;

• a control matrix linking requirements and risks to implementation and evidence;

• tested access, logging, backup, recovery, and incident-response procedures;

• documented exceptions with an approver, compensating measures, and review date.

The review should name blockers. A missing BAA decision for a vendor that receives ePHI is different from a low-priority dashboard improvement. The first may stop a launch or customer onboarding; the second can remain in a dated backlog. Let counsel and the designated compliance owner set the legal acceptance criteria. Engineering should state what the system actually does and what evidence exists.

1. Map ePHI from collection through deletion

Do not start with the cloud account. Start with the data. Work with counsel and privacy owners to identify which fields and combinations are PHI or ePHI, then trace them through every path the product uses.

Include direct collection, imports, APIs, file uploads, support tools, administrative consoles, emails, notifications, generated reports, logs, traces, analytics, caches, search indexes, machine-learning workflows, backups, exports, and deleted-record retention. Include temporary storage and developer workflows. A database may be clean while request bodies containing ePHI are copied into an error tracker.

For each data flow, record the data category, purpose, patient or customer context, source, destination, protocol, encryption, storage location, tenant boundary, retention, deletion behavior, system owner, and vendor. Mark where humans can view or export the data. Include production support, incident response, database administration, and customer-success workflows; privileged paths are part of the system.

Draw trust boundaries. Show where data leaves the product network, crosses accounts or regions, enters a customer-controlled system, or moves to a subcontractor. Link each arrow to a real integration or configuration. Architecture diagrams that are too abstract to expose a log sink or batch export will not support a credible risk analysis.

Use automated discovery where it helps, but require owner review. Scanners may find a column named diagnosis and miss a free-text note containing the same information. The final inventory needs a person who will maintain it when features, vendors, or retention rules change.

Engineering evidence

• a versioned data-flow diagram and asset inventory;

• a field-level or data-category classification maintained with product schemas;

• a list of ePHI stores, transfers, derived copies, backups, and deletion paths;

• tickets or change controls that update the inventory when a new data path ships.

2. Resolve BAA and vendor boundaries before integration

Whether an organization or vendor is a business associate is a legal determination. Engineering supplies the facts: what the service receives, what it does with the data, where it stores it, which subcontractors it uses, and which product features are enabled.

The HHS guidance on business associate contracts explains that these contracts must define permitted uses and disclosures, safeguards, incident reporting, downstream subcontractor restrictions, and return or destruction of PHI at termination, among other terms. A signed BAA is a contract boundary. It is not a statement that every service, region, configuration, integration, or line of application code is ready.

Maintain one vendor record per service with the business purpose, data received, integration owner, BAA decision and status, approved product features, deployment region, subprocessor review, retention and deletion terms, incident contact, offboarding procedure, and last review date. Link to the executed agreement in the authorized contract system rather than copying it into an engineering wiki with broad access.

Check the exact services in use. A cloud provider may offer a BAA while limiting coverage to specified products or configurations. The engineering plan should prevent unapproved services from receiving ePHI through infrastructure policy, account boundaries, or deployment controls. Apply the same review to observability, messaging, support, analytics, identity, backup, and AI vendors.

Engineering evidence

• a vendor and subprocessor register tied to the ePHI inventory;

• an approved-services list enforced in infrastructure and procurement workflows;

• data-processing configuration screenshots or exports with review dates;

• tested vendor offboarding and data-return or destruction steps where applicable.

3. Perform a risk analysis that reaches the real system

The current Security Rule requires an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. HHS's risk analysis and risk management guidance says the rule does not prescribe one methodology, and it describes risk analysis and management as ongoing processes that should respond to operational and environmental change.

Scope the analysis to all ePHI identified in the data map. Evaluate threats, vulnerabilities, current controls, likelihood, impact, and residual risk. Include ordinary engineering failures such as tenant-filter omissions, excessive service permissions, backup corruption, expired certificates, leaked support exports, webhook spoofing, vulnerable dependencies, and unreviewed vendor changes. Include malicious activity, human error, physical loss, and availability failures.

Turn findings into a risk register with an accountable owner, treatment decision, required resources, target date, evidence, and residual-risk approver. A statement that risk is accepted is incomplete if it has no decision owner or review date. A scanner result is input, not the whole analysis.

Refresh the analysis when the system changes in a material way: a new ePHI workflow, cloud migration, identity redesign, AI feature, acquisition, major vendor change, or significant incident. The legal and compliance owners should define the formal cadence. Engineering should make change-triggered review part of delivery so the analysis does not wait for an annual scramble.

Engineering evidence

• the documented scope, method, assets, threats, vulnerabilities, likelihood, impact, and controls;

• a dated risk register linked to remediation work and accepted exceptions;

• records of reassessment after material architecture or operating changes;

• management approval and evidence that overdue high-risk work is escalated.

4. Enforce least privilege across users, staff, and services

Map roles to tasks and data, not job titles alone. A billing user may need claim status without clinical notes. A support engineer may need a tenant identifier and error code without the patient record. Apply authorization in the service that returns the data; hiding a field in the interface is not an access control.

Use unique user identities, strong authentication, session controls, and centralized lifecycle management. Multifactor authentication is a sensible baseline for workforce and privileged access even when a team is still working with counsel on the exact legal and contractual requirement. Protect break-glass accounts, test them, alert on use, and review them after each activation.

Service accounts need the same discipline. Give each workload a distinct identity, avoid long-lived shared keys, scope access to the required resources, rotate or replace credentials, and record ownership. Tenant isolation deserves explicit tests at API, job, cache, search, and object-storage layers. Add negative tests that attempt cross-tenant access.

Review access periodically and after role changes. The review must show what the reviewer saw, what was removed, and who approved any retained privileged access. Do not export broad access lists to an unsecured spreadsheet and call the review complete.

Engineering evidence

• a role and permission matrix linked to product and infrastructure policies;

• automated tests for tenant and object-level authorization;

• privileged-access, break-glass, and service-account inventories;

• access-review records with removals, exceptions, and approvers.

5. Make authentication and session behavior inspectable

Document every authentication path: customer single sign-on, password login, workforce identity, service-to-service credentials, support impersonation, recovery flows, mobile tokens, and API keys. For each path, specify enrollment, verification, session lifetime, revocation, lockout or rate limiting, and audit events.

Recovery flows are often weaker than the login they bypass. Protect password resets, support-led identity recovery, email changes, and MFA resets with defined verification and logging. Avoid exposing whether a patient or user exists through error messages. Rate-limit automated attempts and alert on suspicious recovery activity.

Token revocation should work when a user leaves, a device is lost, a credential is exposed, or a tenant terminates service. Test it. Disabling an identity provider account is not enough if refresh tokens, API keys, database credentials, and active sessions remain valid elsewhere.

6. Protect ePHI in transit, at rest, and in backups

Inventory encryption by data path and store. Record the protocol or mechanism, termination point, key owner, key storage, rotation approach, exception, and test. Cover databases, object storage, queues, caches, search, snapshots, exports, developer tunnels, and vendor transfers.

The current Security Rule's treatment of particular implementation specifications requires careful legal and risk-based analysis. Do not translate addressable into optional. If a control is not implemented as written, the accountable team should document the decision and any reasonable alternative measures with counsel and security leadership. The proposed 2025 rule should not be described as current law while HHS still lists it as proposed.

Use managed key systems where they fit, restrict administrative access, separate duties for high-impact operations, and monitor key-policy changes. Encryption does not solve an authorization flaw when the application legitimately decrypts data for the wrong user. Test the full control path.

Keep ePHI out of logs, analytics, crash reports, and test fixtures unless the use is approved and protected. Redaction must happen before data leaves the trusted boundary. A masking rule that runs only in the logging viewer still leaves the raw record in the storage system.

Engineering evidence

• an encryption and key-management inventory tied to every ePHI store and transfer;

• configuration exports, policy tests, rotation records, and change alerts;

• automated checks for plaintext endpoints, public storage, and unsafe log fields;

• documented exceptions and alternative safeguards.

7. Build audit controls that support an investigation

An audit trail should answer who did what, to which record, in which tenant, through which path, when, and with what result. Capture authentication, access to sensitive records, creation and change of ePHI, exports, permission changes, support impersonation, administrative actions, key changes, and security-control changes. Use a correlation ID to follow activity across services.

Do not put full ePHI in the audit event merely to make it detailed. Store stable references, the action, relevant field names or change class, source, outcome, and protected context needed for investigation. Synchronize clocks. Restrict log access. Detect tampering or deletion, and separate high-value security records from application logs that developers routinely query.

Collection alone is not review. Define alerts and review procedures for suspicious access, bulk exports, disabled controls, repeated authorization failures, unusual support activity, and logging gaps. Assign each alert a responder and a runbook. Monitor the monitoring path so the team knows when an event source stops reporting.

Set retention with counsel, contracts, risk analysis, and operational needs. Avoid treating one retention period as universal for audit logs, application logs, security documentation, and customer records.

Engineering evidence

• an audit-event catalog and coverage tests for sensitive operations;

• retention, integrity, access, and deletion configuration;

• alert rules, review records, investigation runbooks, and response tickets;

• telemetry health checks that expose missing or delayed event sources.

8. Prove backup, disaster recovery, and emergency operation

A successful backup job is not proof that the product can recover. Define recovery-point and recovery-time objectives with business owners, then map each ePHI store and required dependency to those objectives. Include identity, encryption keys, infrastructure configuration, queues, audit records, vendor integrations, DNS, and the operational knowledge needed to restore service.

Separate backup failure domains from production where appropriate. Limit and monitor deletion privileges. Encrypt backups and include them in data retention and vendor reviews. If immutability or offline copies are part of the risk treatment, verify the configuration and the route for authorized recovery.

Run restore tests that produce a usable service, not only a restored database file. Validate record counts, integrity, tenant boundaries, application compatibility, key availability, and logging after recovery. Test a realistic scenario in which normal administrators or a primary region are unavailable. Record actual recovery time and every manual dependency.

Plan emergency-mode operation. Which functions must remain available to protect ePHI and support care or operations? Which integrations can pause? Who can authorize a degraded mode, and how will activity be reconciled later?

Engineering evidence

• backup coverage mapped to systems, owners, retention, and recovery objectives;

• restore-test reports with timestamps, results, defects, and remediation;

• a disaster-recovery runbook with contact and vendor dependencies;

• records from a tabletop or technical exercise that tested degraded operation.

9. Connect incident response to privacy and breach decisions

The engineering plan should define detection, triage, containment, evidence preservation, eradication, recovery, and post-incident work. It should also define the handoff to privacy, legal, customer, and executive decision-makers. Engineers provide facts; the authorized legal and privacy team determines whether an event is a reportable breach and which notices are required.

The HHS Breach Notification Rule guidance describes notification duties for covered entities and business associates, including a business associate's duty to notify the covered entity without unreasonable delay and no later than 60 days after discovery. Contracts may require a shorter operational deadline. The incident runbook should route suspected events immediately rather than treating the outer legal limit as a response target.

Preserve relevant logs, access records, system images, timelines, and decision records under the organization's evidence-handling procedure. Restrict incident workspaces because they may contain ePHI and sensitive security details. Record who made containment changes and why.

Exercise scenarios that fit the product: a cross-tenant authorization flaw, stolen support credential, exposed object-storage link, compromised vendor token, ransomware, corrupted backup, or logging outage. Verify notification contacts and contract escalation paths during the exercise.

Engineering evidence

• an incident plan with named technical, privacy, legal, communications, and executive roles;

• provider and customer notification paths with contract-specific timing;

• forensic logging and evidence-preservation procedures;

• exercise records, lessons, remediation owners, and completion evidence.

10. Terminate access and data deliberately

Offboarding applies to employees, contractors, vendors, customers, devices, and services. Define triggers and target times with HR, legal, security, and operations. Automate removal through the identity provider where possible, then verify the systems that sit outside it.

Terminate active sessions, API keys, service credentials, VPN access, cloud roles, support tools, database accounts, shared secrets, and physical access as applicable. Reassign owned alerts, repositories, dashboards, domains, certificates, and break-glass responsibilities. Rotate credentials when a shared secret could have been known.

Customer and vendor termination also needs a data decision. Follow the applicable agreement and approved retention rules for return, export, deletion, backups, and legal holds. Record completion and exceptions. A disabled user interface does not prove that data was deleted from object storage, analytics, or a downstream vendor.

11. Make evidence part of control ownership

For every control, maintain the requirement or risk it addresses, affected systems, implementation description, control owner, operating owner, evidence location, test method, review cadence, last result, open findings, and exception approver. This is the bridge between a policy and running software.

Prefer evidence generated by the system: policy-as-code results, access-review exports, restore logs, alert histories, deployment records, and tested runbooks. Screenshots may be useful, but they become stale quickly and often omit account, region, or timestamp context. Store evidence in a controlled location with access and retention appropriate to its contents.

Define what must be true before the product accepts ePHI or signs a customer security representation. A practical gate might require the data map, vendor decisions, risk analysis, high-risk remediation, authorization tests, audit coverage, restore test, incident exercise, and accepted exceptions. The legal and compliance owners decide whether that package is sufficient for the intended use and contract.

Use OCR's HIPAA Audit Protocol as one source for evidence-oriented questions, then tailor the control set to the product, contracts, and risk analysis. Do not design only for a questionnaire. Controls have to work between reviews.

What a senior engineering assessment should deliver

A useful assessment should inspect architecture and configuration, trace a representative ePHI workflow, review authorization and tenant boundaries, test logging and restore paths, and compare the evidence to the stated control matrix. Findings should name the affected system, realistic failure mode, evidence, severity rationale, owner, and recommended next step.

Horizon Labs can provide senior healthcare SaaS, cloud, platform, and security-minded engineers at $150–$200 per hour for a bounded technical-readiness assessment or remediation sprint. This is engineering work, not a legal opinion, compliance certification, or guarantee. We can help turn an existing risk analysis or customer requirement into code, infrastructure changes, tests, logging, recovery procedures, and evidence your internal owners can review. See our engineering capabilities or discuss a healthcare SaaS assessment with Horizon Labs.

Frequently asked questions

Does completing this checklist make a healthcare SaaS product HIPAA compliant?

No. The checklist organizes engineering readiness and evidence. HIPAA applicability and compliance depend on the organization's role, facts, contracts, policies, risk analysis, operations, and legal obligations. Qualified counsel and accountable privacy and security leaders should make those determinations.

Does a cloud provider BAA cover the whole SaaS application?

No. A BAA defines contractual duties for the covered services and relationship. The SaaS team still needs to configure approved services, control application access, assess vendors, protect data flows, operate safeguards, and maintain evidence for its own responsibilities.

Is encryption mandatory for every form of ePHI under the current Security Rule?

The current rule requires a fact-specific analysis of its standards and implementation specifications, including addressable specifications. Addressable does not mean optional. Work with counsel and security leadership to document the decision, safeguards, and reasonable alternatives for each data path while tracking proposed rule changes separately.

How often should a HIPAA security risk analysis be updated?

HHS describes risk analysis and risk management as ongoing processes and calls for evaluation in response to environmental or operational changes. The organization should set a documented cadence and also reassess after material changes or incidents, with counsel and accountable leaders defining the formal requirement.

What evidence should engineering have ready for a customer review?

Prepare a current data-flow and asset inventory, vendor and BAA register, risk analysis, control matrix, access reviews, authorization tests, audit-log coverage, restore-test results, incident exercise records, remediation status, and approved exceptions. Limit access to the evidence because it may contain sensitive architecture or ePHI context.

Primary regulatory and implementation sources

• HHS Office for Civil Rights: The Security Rule

• HHS Office for Civil Rights: HIPAA Security Rule proposed rule

• HHS Office for Civil Rights: Business associate contracts

• HHS: Basics of risk analysis and risk management

• HHS Office for Civil Rights: Breach Notification Rule

• HHS Office for Civil Rights: HIPAA Audit Protocol

• NIST SP 800-66 Revision 2: Implementing the HIPAA Security Rule