HIPAA compliance for SaaS: a practical implementation guide

HIPAA regulates two groups. Covered entities are health plans, health care clearinghouses and health care providers that transmit standard transactions (claims, eligibility checks) electronically. Business associates are anyone who creates, receives, maintains or transmits protected health information (PHI) on a covered entity's behalf, plus any subcontractor that does the same for a business associate (45 CFR 160.103). A SaaS platform used by a clinic, a payer or a digital-health company to hold patient data is a business associate. Since the 2013 Omnibus Rule, business associates are directly liable to HHS for Security Rule compliance, for the Privacy Rule obligations in their contract and for breach notification; the contract chain does not shield you.

Two points catch engineering teams out. First, HHS's cloud computing guidance says a cloud provider that only stores encrypted ePHI and never holds the key is still a business associate. Storing ciphertext does not take you out of scope. Second, HIPAA covers electronic PHI wherever it lands: logs, support tickets, analytics events and backups included.

The commercial trigger is usually a business associate agreement (BAA). A hospital or health plan will not send PHI without one, and their procurement team will follow it with a security questionnaire that asks for your risk analysis, policies and often a SOC 2 report. The legal trigger is the law itself: once PHI is on your systems, the Security Rule and the Breach Notification Rule apply whether or not you have signed anything.

Ignoring it has three consequences. OCR investigates complaints and reviews every breach affecting 500 or more people, and settles with a resolution agreement plus a corrective action plan it monitors for two or three years. Civil money penalties are tiered by culpability; the January 2026 inflation adjustment sets the per-violation range at 145 to 2,190,294 US dollars and the calendar-year cap at 2,190,294 per identical provision (91 FR 3665). Under a 2019 notice of enforcement discretion, HHS applies lower annual caps for the three lower tiers (25,000, 100,000 and 250,000 US dollars, inflation-adjusted) and keeps the 1.5 million cap, likewise adjusted, only for uncorrected wilful neglect (84 FR 18151). The third consequence is commercial: a public breach listing or a lost BAA negotiation costs more than most penalties.

The statute is the Health Insurance Portability and Accountability Act of 1996, strengthened by the HITECH Act of 2009. The rules you implement are in 45 CFR Part 160 (definitions and enforcement) and Part 164: Subpart C is the Security Rule (164.302 to 164.318), Subpart D the Breach Notification Rule (164.400 to 164.414) and Subpart E the Privacy Rule (164.500 to 164.534).

The Security Rule

It applies to electronic PHI only and is organised into nine administrative standards (164.308), four physical standards (164.310), five technical standards (164.312), organisational requirements for BAAs (164.314) and documentation requirements (164.316). Each standard has implementation specifications that are either required or addressable. Addressable does not mean optional: under 164.306(d) you must assess whether the specification is reasonable and appropriate in your environment, implement it if so, and otherwise document why not and implement an equivalent alternative. Encryption, automatic logoff and integrity mechanisms are all addressable today; MFA is not named at all. The rule is deliberately technology-neutral (flexibility of approach), which is why the written risk analysis carries so much weight.

The Privacy Rule for a business associate

A SaaS business associate does not issue notices of privacy practices, but it is bound by its BAA to use PHI only as permitted, apply the minimum necessary standard, flow the same terms down to subcontractors, and support the customer's duties to give individuals access, amendments and an accounting of disclosures (164.504(e)). Covered entities must act on access requests within 30 days, with one 30-day extension (164.524(b)(2)), so your export features matter.

The Breach Notification Rule

An impermissible use or disclosure of unsecured PHI is presumed to be a breach unless a documented four-factor risk assessment shows a low probability of compromise (164.402). Individuals, HHS and (above 500 residents of a state) the media must be notified without unreasonable delay and no later than 60 calendar days after discovery; a business associate has the same 60-day outer limit to notify its covered entity (Subpart D).

What has changed

• 2021 HITECH amendment. Public Law 116-321 requires HHS to consider whether you had recognised security practices (the NIST Cybersecurity Framework or the 405(d) programme) in place for the previous 12 months when setting fines, audit length and settlement terms (text). It can only mitigate, never increase.
• Security Rule NPRM, January 2025. HHS proposed the first Security Rule rewrite since 2013 (90 FR 898): remove the required/addressable distinction; keep a written technology asset inventory and network map; deploy MFA on all technology assets, with limited exceptions; encrypt all ePHI at rest and in transit with narrow exceptions; vulnerability scans at least every six months and penetration testing; restore critical systems and data within 72 hours; review the risk analysis at least every 12 months; notify other regulated entities within 24 hours when a workforce member's access ends; and a documented compliance audit every 12 months. Comments closed 7 March 2025. As of October 2026 it is pending, not final and not withdrawn. HHS's NPRM page states the current Security Rule remains in effect, and the 2026 Unified Agenda moved RIN 0945-AA22 to long-term actions with final action projected for July 2027 (reginfo.gov). If finalised as proposed, compliance would be due 240 days after publication.
• Reproductive health privacy rule. Most of the April 2024 Privacy Rule amendment was vacated by a federal court on 18 June 2025; only some notice-of-privacy-practices changes survive (HHS). Little of this touches a SaaS business associate.

Scope is defined by data, not by org chart. Start with a written inventory of every place ePHI is created, received, stored or transmitted, and the systems that can affect its confidentiality, integrity or availability. For a cloud SaaS that means production databases and object stores, caches, queues, search indexes, log pipelines, backups, data warehouses, the support desk, email, chat tools, CI artefacts, and every laptop that can reach any of them. The proposed rule would make this inventory and a network map explicit standards; OCR already expects it as the foundation of the risk analysis.

Then draw the boundary and shrink it deliberately:

• Segregate. Put PHI workloads in dedicated cloud accounts, subscriptions or projects. Everything else becomes out of scope, and your BAA-eligible-services rule becomes enforceable with an allow-list.
• De-identify where you can. Data stripped of the 18 Safe Harbor identifiers, or certified by an expert, is not PHI (164.514(b)). Analytics and ML pipelines usually only need de-identified or limited data sets.
• Map the business associate chain. Upstream: which customers are covered entities or business associates, and which BAA terms you signed. Downstream: every subprocessor that touches PHI (cloud provider, email, monitoring, error tracking, support desk, LLM APIs) needs its own BAA (164.314(a)(2)(iii)). If a vendor will not sign one, PHI cannot go there.
• Decide who is a workforce member. Contractors whose work you directly control are workforce under 160.103 and need the same training, sanctions and termination procedures.

The scoping mistakes that cost the most: assuming PHI never reaches logs or error trackers (it does, through request bodies and stack traces); copying production data to staging without the same controls; treating the cloud provider's BAA as covering services it excludes; and leaving backups and snapshots out of the inventory, which is where most "we didn't know it was there" findings come from.

The order matters. OCR's enforcement actions almost always cite a missing or inadequate risk analysis first, so the risk analysis comes before the control build, not after it.

Weeks 0 to 2: ownership, inventory, contracts

• Name a security official in writing. For a small SaaS this is usually the CTO or head of engineering; what matters is that one person owns the programme.
• Complete the ePHI inventory and data-flow diagram described under scoping. Store it where it will be maintained (the repo, not a slide).
• Execute the cloud BAAs: AWS through AWS Artifact, Microsoft through the Product Terms and Data Protection Addendum (no separate signature), Google Cloud through the console. Record the BAA-eligible service list you will enforce.
• Inventory customer BAAs and subprocessor BAAs; close gaps or remove PHI from the gap.

Weeks 2 to 6: risk analysis and policy set

• Perform the risk analysis against the inventory: threats, vulnerabilities, likelihood, impact, existing controls, residual risk. Follow HHS's risk analysis guidance and NIST SP 800-66 Rev. 2; the free HHS SRA Tool is adequate for a first pass. The output is a dated document plus a risk register with owners.
• Write the risk management plan: which risks you will treat, by whom, by when. This becomes the backlog for the next phase.
• Issue the policy set required by 164.316: security management, workforce security and termination, access authorisation, awareness and training, incident response, contingency planning, device and media controls, sanctions, BAA management. Each policy needs an owner and a review date.
• Run the first workforce training and keep the attendance record.

Weeks 6 to 12: control build

• Identity: SSO, unique IDs, MFA everywhere, least-privilege roles, break-glass procedure, automated deprovisioning.
• Data protection: encryption at rest with customer-managed keys, TLS 1.2 or higher everywhere, PHI scrubbing in logs and error trackers.
• Audit: centralised immutable logs, application-level access logs for PHI records, a written review cadence with tickets as evidence.
• Resilience: backups with immutability, a tested restore, a criticality analysis and documented RTO/RPO.
• Incident response and breach playbook: triage, four-factor breach risk assessment template, notification templates, the 60-day clock, HHS portal submission steps.
• Endpoints: MDM with disk encryption, screen lock and remote wipe for every laptop that can reach PHI (164.310(d)).

Ongoing

• Quarterly access reviews; annual risk analysis refresh and on any material change; annual contingency test; annual training; annual evaluation of the whole programme.
• Keep the under-500 breach log and file it with HHS within 60 days of the end of each calendar year.
• Retain every policy, record and assessment for six years and track the Security Rule NPRM so that MFA, 72-hour restoration and annual audits are already in place if it is finalised.

These are the requirements that consume engineering time and that OCR cites most often. "Done" means configured, evidenced and written into the risk analysis.

1. Risk analysis and risk management

164.308(a)(1)(ii)(A) and (B). A vendor questionnaire or a cloud posture score is not a risk analysis. Done looks like: a written, enterprise-wide document that lists every ePHI asset, the threats and vulnerabilities to each, likelihood and impact, and a risk register with owners and dates, reviewed at least annually. Cloud posture tools feed it: AWS Security Hub CSPM and AWS Config conformance packs; Microsoft Defender for Cloud with the Azure Policy HIPAA/HITRUST initiative; Google Security Command Center. Export their findings into the register rather than treating the dashboard as the deliverable.

2. Unique user identification, authentication and least privilege

164.312(a)(1), (a)(2)(i), 164.312(d) and 164.308(a)(4)(ii)(B). MFA is not yet mandated by the rule, but the proposed rule would require it on every technology asset, with limited exceptions, and OCR already expects it. AWS: IAM Identity Center with your IdP, no IAM users with long-lived keys, root account locked with hardware MFA, MFA enforced by policy condition. Azure: Entra ID Conditional Access requiring phishing-resistant MFA, Privileged Identity Management for just-in-time admin roles. GCP: Cloud Identity with enforced 2-Step Verification, IAM bindings on groups only, the organisation policy that disables service-account key creation. Done: zero shared accounts, every human and service identity traceable in logs, documented approval for each PHI access role.

3. Encryption at rest and in transit

164.312(a)(2)(iv) and 164.312(e)(2)(ii). Both are addressable, but encryption also decides whether an incident is a reportable breach: ePHI encrypted per NIST SP 800-111 (at rest) or SP 800-52 (in transit) with uncompromised keys is not "unsecured PHI" under HHS guidance. AWS: KMS customer-managed keys with rotation, S3 default encryption plus bucket policies denying unencrypted puts, RDS and EBS encryption enabled at creation (it cannot be switched on in place later), TLS 1.2 or higher security policies on load balancers. Azure: storage encryption with customer-managed keys in Key Vault, "secure transfer required" on storage accounts, Transparent Data Encryption on SQL. GCP: encryption at rest is default; use Cloud KMS CMEK where customers require key control, and organisation policies to restrict TLS. Done: a key inventory, separation of keys from data, and no PHI store without encryption enforced by policy.

4. Audit controls and information system activity review

164.312(b) and 164.308(a)(1)(ii)(D). Infrastructure logs are necessary but not sufficient: you also need application-level records of who viewed or changed which patient record. AWS: an organisation CloudTrail trail to an S3 bucket with Object Lock, CloudWatch Logs for applications, GuardDuty for detection. Azure: Activity Log and diagnostic settings streamed to a Log Analytics workspace, with an archive copy in a storage account under an immutability policy, and Microsoft Sentinel for review. GCP: Cloud Audit Logs with Data Access logs enabled for PHI services, sinks to Cloud Storage with retention lock and BigQuery for analysis. The rule sets no log retention period; choose one in the risk analysis and defend it. Done: a written review cadence (weekly for alerts, monthly for access reports) with tickets showing it happened.

5. Automatic logoff and session control

164.312(a)(2)(iii). Your application needs an idle timeout and absolute session lifetime for PHI views, and so do the consoles. AWS: session duration on IAM Identity Center permission sets. Azure: Conditional Access sign-in frequency and persistent-browser controls. GCP: Google session length controls for Cloud Console and gcloud. Pair with MDM screen-lock policies on laptops. Done: timeouts documented per system and tested.

6. Contingency plan: backup, disaster recovery and testing

164.308(a)(7)(ii)(A), (B) and (D). OCR says hacking and ransomware are the most frequent type of large breach reported to it, so this is where restoration speed is judged. AWS: AWS Backup with vault lock, cross-region copies, point-in-time recovery on RDS and DynamoDB. Azure: Azure Backup with immutable vaults and Site Recovery for compute. GCP: the Backup and DR service, multi-region buckets, Cloud SQL point-in-time recovery. Done: documented RTO/RPO per system from the criticality analysis, a restore test at least annually with results filed, and an emergency-mode runbook. Design to the proposed 72-hour restoration target now.

7. Business associate chain and workforce termination

Two controls that are more process than product but fail audits constantly. 164.308(b) requires a compliant BAA with every subcontractor before PHI flows; keep a register with dates and the services covered. 164.308(a)(3)(ii)(C) requires access to end when employment does: SCIM deprovisioning from the IdP into AWS, Entra ID and Google Workspace, with a ticket per leaver showing same-day removal.

OCR data requests and customer due diligence overlap heavily. Keep the following organised by control, dated, and retained for six years from creation or from when the document was last in effect, whichever is later (164.316(b)(2)(i)).

Policies and plans

• Security policy set with owners, approval dates and review history; sanction policy; incident response and breach notification procedure; contingency plan with criticality analysis; BAA template and subcontractor policy; device and media policy.

Records

• Risk analysis reports (every version), risk register and risk management plan with closure evidence.
• Training records with dates and attendees; signed acknowledgements.
• Access authorisation records, quarterly access reviews, leaver tickets.
• Incident log, four-factor breach risk assessments, notification letters and HHS portal receipts, the under-500 annual log.
• Contingency test results, restore test reports, evaluation reports.

Technical exports

• Identity reports: user list with MFA status, role assignments, service accounts and key age.
• Encryption configuration: key inventory, storage and database encryption settings, TLS policies.
• Logging configuration and samples of reviewed alerts; backup job reports and retention settings; vulnerability scan and patch reports.

Contracts

• BAAs with every covered-entity and business-associate customer, and with every subcontractor; the cloud BAAs and the eligible-services list you enforce.

The practical test: can you produce the risk analysis in force on any given date in the past six years, and the evidence that its findings were acted on? That question opens most OCR investigations.

There is no HIPAA certificate. HHS approves no certification scheme, and AWS, Microsoft and Google all describe HIPAA on their platforms as a shared responsibility in which the customer's own configuration and compliance programme remain the customer's job. Your compliance is tested in four ways.

1. Customer due diligence

This is the assessment most SaaS companies face first and most often. Expect BAA negotiation (notification windows shorter than 60 days are common), a security questionnaire and a request for an independent report. A SOC 2 Type II or a HITRUST assessment is accepted as a proxy because no HIPAA-specific attestation exists. Readiness for a cloud-native company with a SOC 2 typically takes three to six months; without one, the identity, logging and policy work adds time.

2. OCR investigations

OCR opens investigations from complaints and from breach reports. Breaches affecting 500 or more individuals go to HHS within 60 days and are listed publicly; smaller ones are filed annually. An investigation starts with a data request for the risk analysis, policies and evidence above. Outcomes range from technical assistance to a resolution agreement with a payment and a corrective action plan monitored for two or three years, or a civil money penalty. Through 2025 and 2026 the published actions lean heavily on two initiatives: the Risk Analysis Initiative (13 completed investigations by April 2026, per HHS) and ransomware investigations (OCR announced its 21st ransomware enforcement action in July 2026), alongside the long-running Right of Access initiative. Business associates are named in these actions, including a software company settling in March 2026 for failing to notify affected covered entities of a breach and failing to conduct an accurate and thorough risk analysis.

3. OCR audits

HITECH requires periodic audits. The 2016 to 2017 round covered 166 covered entities and 41 business associates; the 2024 to 2025 round reviews 50 entities against the Security Rule provisions most relevant to hacking and ransomware. Audits use a published protocol, which is a useful self-assessment checklist.

4. Mitigation credit

Since 2021, evidence that recognised security practices were in place for the prior 12 months must be considered when OCR sets penalties and audit scope. Aligning your programme to the NIST Cybersecurity Framework and documenting it is cheap insurance.

Cost drivers are scope breadth (how many systems hold PHI), the number of subprocessors needing BAAs, legacy components that cannot be encrypted or logged, and whether an existing SOC 2 or ISO 27001 programme already produces the evidence.

1. A checklist instead of a risk analysis. Entities present a vendor questionnaire or a cloud posture score. Fix: a written analysis of threats and vulnerabilities to each ePHI asset, with likelihood and impact, and a register of what you decided to do.
2. Treating "addressable" as optional. No encryption on a legacy database "because it's addressable". Fix: either implement it or write the documented justification and compensating control that 164.306(d) requires. For encryption the justification almost never holds.
3. PHI in logs, error trackers and support tools. Fix: scrub request bodies and identifiers at the logging library, route errors only to vendors under BAA, and block PHI uploads in the help desk.
4. Subprocessors without BAAs. Monitoring, transactional email and LLM APIs are the usual gaps. Fix: a subprocessor register tied to the data-flow diagram; no PHI until the BAA is signed.
5. Misreading the breach clock. 60 days is the outer limit, measured from discovery by anyone in your workforce, and "without unreasonable delay" is the actual standard. Fix: an incident procedure with the four-factor assessment template and the business associate notification step on day one, not day 50. Remember that the burden of proof is on you (164.414(b)).
6. Forgetting the under-500 annual report. Small breaches must be logged and reported to HHS within 60 days of the calendar year end (164.408(c)). Fix: a standing calendar entry and a log template.
7. Leavers who keep access. OCR has settled cases that began with a former employee's live credentials. Fix: IdP-driven deprovisioning to every cloud and SaaS tool, verified by a leaver ticket.
8. Backups that were never restored. Fix: an annual restore test with a written result, and immutability so ransomware cannot encrypt the backup too.
9. Stale documentation. Policies written once, risk analysis from three years ago, no evidence of review. Fix: owners and review dates on every document, and a change trigger ("new system holding PHI") that forces a risk analysis update.
10. "We're HIPAA compliant because we're on AWS." The provider's BAA covers its infrastructure, not your configuration or your application. Fix: enforce the eligible-services list and own the shared-responsibility line in writing.

iCompaas maps its technical control checks to the HIPAA Security Rule: access logging, encryption at rest and in transit, unique user identification, automatic logoff and integrity controls are checked continuously across your connected cloud accounts on AWS, Azure, GCP and other providers, so the evidence for 164.312(b) or 164.312(a)(2)(iv) is collected as configuration changes rather than reconstructed before a customer review.

Templated Privacy and Security Rule policies come with owners and review cadences, which keeps the 164.316 documentation set current. A BAA tracker records which customers and subprocessors are under agreement and when those agreements were signed. The breach notification workflow walks responders through the 60-day clock, the HHS portal entry and the individual-notice template. Collected evidence can be exported as a pack for a customer questionnaire or an OCR data request, and the individual Security, Privacy and Breach Notification Rule provisions are explained in the control library on this site.