Here’s the first thing to know about HIPAA in April 2026: the Security Rule is about to change for the first time since 2013. The final rule is on the HHS Office for Civil Rights regulatory agenda for May 2026, the proposed version eliminates most of the “required vs addressable” flexibility that has defined the existing rule, and the expected compliance window after finalisation is 180 to 240 days. For a healthcare SaaS company implementing HIPAA now, this matters. The controls you’re building in 2026 need to be forward-compatible with the rule that’s coming, not just compliant with the rule that’s ending.
Here’s the second thing. Most HIPAA content online falls into one of two buckets. Law firms write long, cautious, timeline-free essays full of words like “may” and “generally.” Vendors write short, confident, timeline-filled posts that all end in “book a demo of our HIPAA compliance platform.” Neither is what a healthtech CTO or head of security actually needs.
This article is the project plan. Nine months, phased, written for the technical leader at a healthcare-adjacent SaaS company who needs to achieve a HIPAA-compliant posture to sign BAAs with covered entity customers.
HIPAA for SaaS: what you’re actually complying with
HIPAA is a statute from 1996 that generated several rules over the following fifteen years. The three that matter for a SaaS business associate are:
The Privacy Rule (2003) governs how Protected Health Information (PHI) is used and disclosed. It applies primarily to covered entities (healthcare providers, health plans, clearinghouses) and flows through to their business associates via contract. As a SaaS business associate, you’re bound by the Privacy Rule largely through your BAA with the covered entity, which will specify permitted uses and disclosures.
The Security Rule (2005, being revised in 2026) governs the protection of electronic Protected Health Information (ePHI). It specifies administrative, physical, and technical safeguards. This is where most of your actual engineering and process work goes. Current rule uses “required” and “addressable” implementation specifications; the final rule expected May 2026 is proposed to make most specifications required outright.
The Breach Notification Rule (2009) governs what happens when a breach occurs. As a business associate you have obligations to notify the covered entity of breaches of unsecured PHI within 60 days, and the covered entity then has obligations to notify affected individuals and HHS.
One thing to state clearly because vendors routinely muddy the water: there is no such thing as HIPAA certification. No private organisation can certify your company as “HIPAA compliant” in a way that carries legal weight with HHS. Third-party attestations (SOC 2 with HIPAA criteria, HITRUST, and similar) are credible evidence of your security posture and are often accepted by covered entities as evidence of business associate readiness. They are not certifications. Anyone selling you a HIPAA certification is selling you a logo.
What you’re actually aiming for is a position where you can honestly attest, in a BAA with a covered entity, that you have the administrative, technical, and physical safeguards the Security Rule requires, and where you can produce evidence of those safeguards if audited by HHS OCR or asked for it by a customer’s procurement team.
The 9-month timeline at a glance
Nine months is realistic for a healthtech SaaS company of 20–200 people implementing HIPAA-compliant posture for the first time, assuming moderate baseline security maturity. A team coming out of a SOC 2 Type II can compress meaningfully. A team with no prior compliance work should budget closer to twelve.
Phase 1: Scoping and risk analysis Months 1–2
Phase 2: Technical safeguards Months 2–5
Phase 3: Administrative safeguards & training Months 4–6
Phase 4: Physical safeguards & vendor mgmt Months 5–7
Phase 5: Documentation & readiness review Months 7–9
BAA negotiation Ongoing from Month 3Phases overlap. HIPAA isn’t a waterfall; work in one cluster unblocks work in another. The timeline shape also reflects the reality that BAA negotiation with your first covered entity customer usually runs in parallel with the back half of implementation, because the deadline driving the whole programme is usually a specific customer contract.
Phase 1: Scoping and risk analysis (months 1–2)
Two months to define what ePHI your product actually touches, where it flows, and what threats exist to it.
Data flow mapping. Identify every place ePHI enters, lives, or leaves your systems. APIs that receive it, databases that store it, backup systems that replicate it, logs that might contain it, support tools that might expose it, analytics platforms that might aggregate it, third parties that process it on your behalf. Most SaaS teams discover during this exercise that ePHI is flowing to at least two places they didn’t expect — usually an analytics pipeline or a customer support tool where PHI has leaked into ticket bodies.
Scoping decision. What’s inside the HIPAA boundary of your product and what isn’t? Clear architectural separation between HIPAA-scoped systems and non-HIPAA-scoped systems simplifies everything downstream. Companies that try to make the entire product HIPAA-compliant usually find they’re paying for controls on systems that never touch PHI. Companies that try to keep HIPAA to a narrow “enclave” find later that data flows don’t respect the boundary. The honest middle path is a clearly-defined scope with a documented data flow that crosses it only via controlled interfaces.
Risk analysis. The Security Rule requires a documented risk analysis that identifies threats and vulnerabilities to ePHI, assesses their likelihood and impact, and determines the controls needed to reduce residual risk to an acceptable level. NIST Special Publication 800-66 Revision 2 is the current reference for conducting HIPAA risk analysis and is worth reading before you start. The output is a risk register and a risk management plan, and both are auditable artefacts OCR specifically asks about in investigations.
The position worth taking: the risk analysis is the single most-cited deficiency in OCR enforcement actions. If the only thing you spend real time on in Phase 1 is the risk analysis, you’ll be ahead of a large fraction of the industry.
Phase 2: Technical safeguards (months 2–5)
Three months for the technical work. This is where engineering time concentrates, and for most SaaS teams it’s the phase with the highest perceived cost and the lowest actual risk of surprise — because it’s the work engineers naturally understand.
The Security Rule groups technical safeguards into five categories: access control, audit controls, integrity, person or entity authentication, and transmission security. The proposed 2026 revisions tighten or make mandatory several items that are currently addressable. Plan for the proposed state, not the current state.
Access control. Unique user identification for everyone who accesses ePHI. Automatic logoff for workstations. Encryption and decryption of ePHI at rest — in the proposed rule, explicitly required with limited exceptions. Role-based access with least-privilege enforcement. For SaaS teams the hardest part is usually the principle of least privilege applied to internal tools — engineering and support staff who can query production databases containing ePHI need justified, audited access, not blanket grants.
Audit controls. Logging of access to ePHI. This sounds simple and is, in practice, the cluster that catches teams flat-footed during breach response. The logs need to answer questions like “which employees accessed this patient’s record in the last six months, from what IP addresses, for what documented purpose?” If your logging can’t answer that question today, it needs to be able to by the end of Phase 2.
Integrity. Controls to ensure ePHI isn’t improperly altered or destroyed. Cryptographic hashing of stored records, checksum validation, immutable audit trails for medical record changes. This cluster is tighter in the proposed 2026 rule.
Authentication. Multi-factor authentication for all ePHI access — addressable in the current rule, explicitly required in the proposed rule. If you don’t have MFA on every path to ePHI today, prioritise it.
Transmission security. Encryption of ePHI in motion. TLS 1.2 or higher for all connections that carry ePHI. The proposed rule is explicit about this, and the days of “addressable” encryption are effectively over.
Expect this phase to run slightly longer than planned. The single most common overrun is the access control work — discovering during implementation that the way your engineering and support teams actually work requires more access than a strict least-privilege model would grant, and that the tooling to do just-in-time access provisioning didn’t exist until someone built it.
Phase 3: Administrative safeguards and training (months 4–6)
Two months overlapping with the back half of technical work. Administrative safeguards are the policies, procedures, and human processes around ePHI.
Key deliverables: designated security officer (a named person with documented responsibility), workforce security procedures (hiring, sanctions for violations, termination), workforce training (on a documented cadence, usually annual), information access management (how access is authorised and reviewed), security awareness and training programmes, contingency planning (backup, disaster recovery, emergency operations), and evaluation procedures (how the ISMS is periodically assessed).
Three things reliably trip first-time programmes here.
First, the workforce training requirement isn’t “HR sends an email with a PDF attachment.” It’s a documented programme with content, delivery mechanism, attendance records, and periodic refreshers. OCR has cited training deficiencies in multiple enforcement actions.
Second, the contingency plan isn’t a Google Doc titled “Disaster Recovery” that someone wrote in 2023. It’s a tested plan with documented evidence that testing occurred, that findings were addressed, and that the plan gets reviewed on a documented cadence.
Third, the sanctions policy has to exist and has to be enforced visibly at least once. If you never sanction an employee for violating HIPAA-related policies, how do you demonstrate that the sanction policy is real? At a minimum, document that the policy exists, that employees have acknowledged it, and that management has discussed its application.
Phase 4: Physical safeguards and vendor management (months 5–7)
Two months, often the lightest-weight phase for a cloud-native SaaS company but not skippable.
Physical safeguards. For a fully cloud-hosted SaaS business, the physical safeguards on ePHI reduce largely to office security (if you have offices that process or display ePHI) and to the cloud provider’s physical security (which you inherit through the BAA with AWS, Google Cloud, or Azure). Document the split: what physical security responsibilities are yours, what are your cloud provider’s, and how that’s allocated.
Workstation security. Employees accessing ePHI need documented workstation-use policies, secure workstation configurations (MDM-managed devices, disk encryption, screen lock, approved operating system versions), and processes for secure workstation disposal.
Business associate / vendor management. Every third party that processes ePHI on your behalf is your business associate and needs a BAA with you downstream. This includes your cloud infrastructure, your database-as-a-service providers if they touch ePHI, your log aggregation services if ePHI might appear in logs, your analytics platforms if they might see ePHI, your customer support tools if ticket bodies might contain ePHI. Inventory every such vendor in Phase 4 and, if a BAA isn’t in place, get one in place. A vendor that won’t sign a BAA needs to be either architected out of the ePHI path or replaced.
Phase 5: Documentation and readiness review (months 7–9)
Two months to consolidate everything into a state where you can honestly sign a BAA with a covered entity customer and respond to an OCR audit.
Policy suite consolidation. All policies written in earlier phases pulled into a single, coherent document set with consistent versioning, approval dates, and review cadences. This is the artefact set OCR asks for if they investigate.
Risk analysis update. The Phase 1 risk analysis was a point-in-time exercise. Update it now that controls are in place — residual risks will have changed, and the documented update is evidence of the risk management cycle functioning.
Third-party attestation decision. Many healthcare SaaS companies achieve a SOC 2 Type II report with HIPAA criteria, or pursue HITRUST, as a commercial asset alongside HIPAA compliance itself. The decision of whether and when to layer a third-party attestation on top of HIPAA implementation is a customer-driven one, not a regulatory one. Start the conversation with your largest potential covered entity customers in Phase 5 to understand what they actually want to see.
Readiness review. Internal review — or external review by a consulting firm or assessor — to identify gaps before a customer’s procurement team finds them. This is cheap relative to the cost of a BAA negotiation that stalls because your documentation can’t answer their security questionnaire.
BAA negotiation and signing milestones
The BAA is the commercial artefact that unlocks the customer deal. It’s also the document through which most of your downstream HIPAA obligations actually attach to you. Treat it as a real negotiation, not a form.
A realistic BAA timeline, run in parallel with Phases 3–5:
- Month 3: Initial BAA draft from your side (don’t sign the covered entity’s template blindly; have your own).
- Month 4–5: Legal review with counsel familiar with healthcare data, redlines exchanged with the covered entity.
- Month 5–6: Security questionnaire responses, often the actual gate — covered entities’ InfoSec teams typically ask 100–300 questions about safeguards.
- Month 6–7: Technical review calls, evidence exchanges (architecture diagrams, SOC 2 report, policy excerpts).
- Month 7–8: Final negotiation of liability caps, breach notification timelines, indemnification.
- Month 8–9: Execution.
Six months of BAA negotiation sounds long. It isn’t. Enterprise healthcare customers will not move faster than this for first-time vendors, and attempting to compress the timeline typically means the customer finds gaps you didn’t find yourselves.
What’s often missed in SaaS HIPAA programmes
Four things reliably get missed by engineering-led SaaS teams implementing HIPAA for the first time.
PHI in logs. Teams spend months architecting clean ePHI boundaries in the application layer and then discover that application logs contain full request payloads including ePHI, that those logs ship to a third party, and that the third party isn’t under BAA. Log scrubbing at the application boundary is a control worth building early.
PHI in support tooling. Customer support tickets routinely contain ePHI because customers paste it in when describing issues. Support tools — help desks, screen-share recordings, chat logs — then become ePHI processors. Either they’re under BAA or they can’t touch ePHI tickets, and most SaaS teams haven’t thought about this.
Analytics platforms. Product analytics, session replay, error reporting. If any of these services can observe ePHI, they’re business associates. Many off-the-shelf analytics platforms will not sign a BAA.
Sanctions policies that nobody believes in. Policies that say employees will be sanctioned for HIPAA violations but that have no documented examples of being applied. This is a common finding in OCR enforcement actions and a common weakness in third-party assessments. The policy needs teeth — at minimum, documented acknowledgements that employees understand the policy and its consequences.
The underlying pattern across all four: HIPAA obligations flow wherever ePHI flows, and SaaS architectures make ePHI flow further than the team realises.
FAQ
How long does HIPAA implementation take?
Nine months is realistic for a mid-sized healthtech SaaS with moderate baseline security. Twelve is typical for teams starting from scratch. Shorter is possible for teams coming out of SOC 2 Type II with good architectural boundaries.
Can I be HIPAA certified?
No. No private organisation can issue a certification that carries legal weight with HHS. What exists are third-party attestations (SOC 2 with HIPAA criteria, HITRUST) that serve as evidence of compliance, commonly accepted by covered entity customers.
What’s the difference between the Privacy Rule and the Security Rule?
The Privacy Rule governs uses and disclosures of all PHI (regardless of form). The Security Rule governs the protection of electronic PHI specifically, through administrative, physical, and technical safeguards.
What’s changing in the Security Rule in 2026?
The HHS OCR has a final rule on its regulatory agenda for May 2026 that, as proposed, would make most implementation specifications mandatory rather than addressable, require encryption of ePHI at rest and in transit, require MFA, require annual penetration testing, require biannual vulnerability scanning, and introduce a 72-hour incident response requirement. The final form may differ from the proposed rule. Plan for the proposed state.
Do I need a BAA with my cloud provider?
Yes, if your cloud provider processes or stores ePHI on your behalf. Major providers (AWS, Google Cloud, Azure) offer BAAs as standard for HIPAA-eligible services. Confirm which specific services are covered — not every service in a provider’s catalogue is HIPAA-eligible even where the provider offers a BAA.
What triggers breach notification?
Impermissible use or disclosure of unsecured PHI. Encrypted PHI disclosed accidentally may not trigger notification depending on circumstances. Document your assessment process; a clear documented decision not to notify is defensible, and no documented assessment is not.
Do I need HITRUST?
Depends on your customers. Some large health systems require HITRUST. Many accept SOC 2 Type II with HIPAA criteria. Talk to your three largest potential covered entity customers before investing in HITRUST specifically.
What’s the penalty for HIPAA violations?
Civil monetary penalties range from $141 to over $2.1 million per violation (as of 2025, adjusted annually for inflation), with the tier depending on culpability. Criminal penalties also exist for knowing violations. Enforcement is by HHS OCR and state attorneys general.
Does HIPAA apply to my SaaS if I only handle de-identified data?
Properly de-identified data (either through the Safe Harbor method or Expert Determination, as defined in the Privacy Rule) is not PHI and is out of HIPAA scope. The word “properly” carries weight — if your de-identification doesn’t meet one of the two specified methods, the data is still PHI.