HIPAA Readiness Checklist for Healthcare SaaS Engineering

TL;DR

HIPAA readiness for healthcare SaaS engineering is not a compliance checkbox but an ongoing engineering discipline. Your cloud provider’s BAA covers roughly 20% of your Security Rule obligations; the rest falls on your application code, access controls, audit logging, and vendor chain. The proposed 2025 NPRM eliminates the distinction between “addressable” and “required” safeguards, making MFA, encryption, and annual pen testing mandatory for all covered entities and business associates. This guide defines every term your engineering team will encounter, maps each to specific technical controls, and provides a consolidated checklist you can assign owners to today.

Why Healthcare SaaS Engineering Teams Need a Different Kind of Checklist

Most HIPAA guides are written for compliance officers. They explain the Privacy Rule, reference a few penalty tiers, and link to a policy template. That is not what an engineering team needs when preparing to handle electronic Protected Health Information (ePHI) for the first time.

Engineering teams need to know which encryption standard to configure, how long to retain audit logs, whether their error-tracking tool requires a Business Associate Agreement, and what happens when an OCR auditor asks for penetration testing evidence targeting their tenant isolation boundaries.

This HIPAA readiness checklist for healthcare SaaS engineering covers all of that. It is organized as a glossary-first reference, so every term maps to a concrete action, a specific technical control, or a real enforcement example. The audience is CTOs, engineering leads, and technical founders building SaaS products that will touch patient data.

Two forces make this guide especially urgent. First, the average cost of a healthcare data breach hit $7.42 million in 2025, the highest of any industry for the 14th consecutive year. Second, a proposed overhaul to the HIPAA Security Rule (the NPRM published January 6, 2025) will eliminate the concept of “addressable” safeguards entirely, making controls like MFA and encryption at rest non-negotiable. The final rule is expected by May 2026 with a 240-day compliance window. Engineering teams that wait until the rule is finalized will be scrambling.

For more engineering-focused definitions and guides, browse our full engineering glossary.

Foundation Terms Every SaaS Engineer Should Know

Before touching a single line of code, your team needs shared vocabulary. These are the terms that frame every conversation with legal counsel, compliance consultants, and OCR auditors.

HIPAA

The Health Insurance Portability and Accountability Act of 1996. The original law focused on insurance portability, but its administrative simplification provisions created the privacy and security framework that governs electronic health data today. For modern SaaS, HIPAA’s reach was significantly extended by the HITECH Act (2009) and the Omnibus Rule (2013), which brought business associates (including SaaS vendors) directly under enforcement.

ePHI (Electronic Protected Health Information)

Any individually identifiable health information that is created, received, stored, or transmitted electronically. This includes obvious items like medical records and lab results, but also less obvious data: appointment times paired with patient names, billing codes, IP addresses combined with health condition data, and even device identifiers linked to treatment information.

The key test: could this data identify a specific person and relate to their health, healthcare provision, or payment for healthcare? If yes, it is ePHI.

Covered Entity vs. Business Associate

Covered entities are health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. Most SaaS companies are not covered entities. They are business associates, meaning they create, receive, maintain, or transmit ePHI on behalf of a covered entity.

This distinction matters because business associates are directly liable under HIPAA since the HITECH Act. In early 2025, business associates were responsible for breaches affecting over 93 million records. Your SaaS company is on the hook.

Subcontractor / Subprocessor

Any downstream vendor that handles ePHI on your behalf. Your cloud provider, your logging platform, your error-tracking service, your email delivery tool. Each one in the chain must be covered by a Business Associate Agreement. The critical insight: a signed BAA with AWS, GCP, or Azure covers approximately 20% of your Security Rule obligations, specifically the infrastructure layer. Everything your application code touches is your responsibility.

HITECH Act

The Health Information Technology for Economic and Clinical Health Act (2009) extended HIPAA’s enforcement directly to business associates and introduced the Breach Notification Rule. It also increased penalty amounts and gave state attorneys general authority to enforce HIPAA. For SaaS teams, this is the law that made HIPAA your problem, not just your hospital client’s problem.

The Three Rules Every Engineer Must Know

HIPAA’s regulatory framework rests on three rules. Engineers tend to focus exclusively on the Security Rule, but all three have engineering implications.

The Privacy Rule

Governs how ePHI can be used and disclosed. The engineering-critical concept here is the “minimum necessary” standard: your application should only expose the minimum amount of ePHI required for each specific function. This means role-based data filtering in your API responses, not just role-based access to endpoints. If a billing coordinator doesn’t need to see clinical notes, your application logic should exclude them from the response payload entirely.

The Security Rule

Defines administrative, physical, and technical safeguards for ePHI. This is the engineering core of HIPAA compliance. The rule references NIST SP 800-66 Revision 2 (published February 2024) as the primary implementation guide. The three safeguard domains are covered in detail below.

The Breach Notification Rule

Requires notification within 60 days of discovering a breach affecting 500 or more individuals. Breaches affecting fewer than 500 individuals must be reported annually. The engineering implications: your incident response plan must include automated detection, forensic preservation of logs, and a documented communication workflow that meets these timelines. The Change Healthcare breach of February 2024 illustrates the consequences of failure. Attackers gained access through a Citrix remote access portal that lacked MFA, eventually affecting approximately 190 million Americans. UnitedHealth Group paid a $22 million ransom, and total cyberattack impacts reached $2.457 billion through September 2024.

Administrative Safeguards: The Compliance Foundation That Engineers Own

Administrative safeguards are organizational policies and procedures. Engineers often dismiss them as “not my problem,” but in practice, engineering leaders own or co-own most of these artifacts.

Security Risk Analysis (SRA)

This is the single most cited violation in OCR enforcement actions. OCR launched a dedicated Risk Analysis Initiative in fall 2024, and in the first six months, seven enforcement actions were announced. Settlements ranged from $10,000 to $350,000. In every single case, the regulated entity failed to conduct an adequate risk analysis.

An SRA is not a one-time exercise. It must be annual, board-signed, and tied to your actual infrastructure. Enterprise compliance consultant Josef Kamara identifies the SRA as one of five technical artifacts OCR auditors verify first.

For your engineering team, this means documenting every system that stores, processes, or transmits ePHI, identifying threats to each, assessing the likelihood and impact of each threat, and implementing controls to reduce risk to an acceptable level.

Risk Management Plan

The remediation tracker that accompanies your SRA. Every identified risk gets an owner, a mitigation strategy, and a timeline. This is an engineering artifact as much as a compliance one. Track it in your project management tool alongside feature work.

Security Officer

HIPAA requires a designated security official responsible for the development and implementation of security policies. In a startup, this is often the CTO or VP of Engineering. The key requirement: the role must be formally assigned and documented, not assumed.

Workforce Training

The proposed NPRM requires training within 30 days of hire with annual refreshers. Training must be documented with timestamps proving when each employee completed it. Engineers push back on this, but it matters: a developer who doesn’t understand that copying ePHI into a Slack channel constitutes a potential breach is a liability regardless of how good your encryption is.

Incident Response Plan

Your plan should follow the standard six-phase structure: preparation, identification, containment, eradication, recovery, and lessons learned. The engineering-specific requirements include automated alerting on suspicious access patterns, forensic log preservation (immutable storage), and documented communication workflows that meet the 60-day breach notification timeline.

As Joe Gellatly, CEO of compliance platform Medcurity, wrote on DEV Community: “An untested backup is Schrödinger’s backup, it simultaneously works and doesn’t work until you try it.” The same logic applies to incident response plans. If you haven’t run a tabletop exercise, you don’t have a plan. You have a document.

Contingency Plan

Covers backup, disaster recovery, and emergency mode operation. The proposed NPRM introduces a 72-hour system restoration requirement after security incidents. Your engineering team needs documented RPO (Recovery Point Objective) and RTO (Recovery Time Objective) targets, and you need to prove you can meet them through actual restore testing.

Technical Safeguards: The Engineering Core of HIPAA Readiness

This section is the heart of any HIPAA readiness checklist for healthcare SaaS engineering. These are the controls your engineering team directly implements, configures, and maintains.

Access Control

Every user accessing ePHI must have a unique identifier. No shared accounts. This extends further than most teams realize. Gellatly’s developer checklist on DEV Community puts it bluntly: “No shared accounts. Ever. This includes service accounts, database connections, and API keys. Every action touching PHI needs to trace back to an individual.”

Implement role-based access control (RBAC) with the minimum necessary principle. Document your role definitions, map them to specific ePHI access permissions, and review them quarterly. Access termination upon employee separation should target a one-hour window under the proposed NPRM.

Multi-Factor Authentication (MFA)

The proposed NPRM makes MFA required for all ePHI access with limited exceptions. Even before the rule finalizes, MFA is effectively mandatory in practice. The Change Healthcare breach, the largest healthcare breach in US history, started with a remote access portal that lacked MFA.

The critical blind spot practitioners flag: admin panels. Josef Kamara identifies the “Admin Panel Blind Spot”, noting that Django Admin, Rails Admin, and custom backoffice tools often bypass SSO and lack MFA. OCR auditors inventory every authentication endpoint and verify MFA enforcement at each. A single exception triggers a finding.

MFA must cover: user-facing application login, admin/backoffice panels, cloud console access, CI/CD pipeline access, database access tools, and VPN/remote access connections.

Audit Controls and Immutable Audit Logs

HIPAA requires the ability to record and examine activity in systems containing ePHI. In practice, this means centralized, immutable audit logs that capture who accessed what, when, from where, and what action they took. Logs must be NTP-synced for forensic accuracy and retained for six years.

Here is where default configurations fail. AWS CloudTrail defaults to 90 days of retention. Google Cloud Logging defaults to 30 days. HIPAA mandates six years. The good news: the storage cost is trivial. A 100-employee SaaS generates roughly 18GB per year of audit logs; six-year retention on S3 Object Lock costs approximately $30 per year. The architecture decision (WORM storage, Object Lock, immutable buckets) must be made early. Retrofitting immutable logging into an existing system is significantly harder than building it from the start.

Encryption at Rest

AES-256 encryption for all ePHI data stores. This includes primary databases, backups, file storage, message queues, and cache layers if they contain ePHI. Use your cloud provider’s Key Management Service (KMS) with automatic key rotation enabled. Export your encryption configuration as an audit artifact because auditors will ask for it.

Encryption in Transit

TLS 1.2 is the minimum; TLS 1.3 is preferred. This applies not just to external-facing APIs and web interfaces, but also to internal microservice communication. If your services communicate over a private network without TLS, ePHI transmitted between them is unencrypted in transit. This is a common gap in microservice architectures, and auditors check for it.

Integrity Controls

Mechanisms to ensure ePHI has not been improperly altered or destroyed. In practice: checksums on stored data, hash verification on transmitted data, digital signatures on critical documents, and change management processes that prevent unauthorized modifications to production systems containing ePHI.

Automatic Logoff

Session timeouts on any application or system accessing ePHI. Configure inactivity timeouts appropriate to the sensitivity of the data (commonly 15 minutes for clinical systems, 30 minutes for administrative systems). Document your timeout policies and enforce them server-side, not just in frontend code.

Emergency Access Procedure (Break-Glass)

A documented procedure for obtaining necessary ePHI during an emergency when normal access controls are insufficient. This includes who can invoke it, how access is granted, how the access is logged (it must be logged even more thoroughly than normal access), and the post-incident review process. Break-glass access without logging is a serious audit finding.

Physical Safeguards for SaaS Teams

Physical safeguards get less attention in cloud-native SaaS, but they still apply.

Facility Access Controls

For cloud-hosted infrastructure, your cloud provider handles physical datacenter security (covered by their BAA). Your responsibility covers the physical spaces where employees access ePHI: offices, home offices, and co-working spaces. Visitors to office spaces containing ePHI access must be logged and escorted.

Workstation Security

Every device used to access ePHI must have full-disk encryption, screen lock with a password, and ideally mobile device management (MDM) enabling remote wipe. This applies to developer laptops, not just clinical workstations. A lost or stolen developer laptop with cached production data is a reportable breach if the disk is unencrypted.

Device and Media Controls

Documented procedures for disposal, reuse, and movement of hardware or media containing ePHI. When decommissioning a developer machine, ensure ePHI is securely wiped. Maintain records of media destruction.

Business Associate Agreements: The Vendor Chain That Breaks Most Startups

If there is one area where healthcare SaaS engineering teams underestimate the effort required, it is BAA coverage across their entire tool stack.

What a BAA Is

A Business Associate Agreement is a contract between a covered entity (or business associate) and a vendor that will handle ePHI on their behalf. It specifies permitted uses and disclosures, requires the vendor to implement safeguards, and establishes breach notification obligations. Sharing PHI with a vendor without a BAA in place is a HIPAA violation. Both parties can face enforcement action. HHS has imposed seven-figure settlements for failures to execute BAAs with vendors who handled PHI.

The Subcontractor BAA Chain

You own the chain below you. If your SaaS uses Datadog for monitoring and Datadog processes log entries containing ePHI, you need a BAA with Datadog. If Datadog uses a sub-processor, their BAA with that sub-processor covers the next link. But if you add a new tool that touches ePHI, you are responsible for ensuring BAA coverage before the tool goes live.

The BAA Registry

This should be a living engineering artifact: a spreadsheet or database that maps every tool in your stack to its BAA status, the date the BAA was signed, the renewal date, and the scope of ePHI the tool handles. The proposed NPRM introduces annual written verification from business associates confirming their technical safeguards. Your registry is where you track this.

Common SaaS Vendors Requiring BAAs

Not every tool in your stack needs a BAA, only those that create, receive, maintain, or transmit ePHI. Common categories include:

Cloud infrastructure: AWS, GCP, Azure (all offer BAAs for eligible services).

Logging and monitoring: Datadog will sign a BAA with customers that transmit ePHI through their HIPAA-eligible services. Splunk offers BAAs for enterprise tiers.

Error tracking: Sentry enterprise offers BAA coverage. For smaller teams, Honeybadger (Business plan at $80/month, includes BAA) and GlitchTip (HIPAA-compliant hosting as an add-on to the Large plan at $250/month) are common alternatives.

Analytics: PostHog and Mixpanel enterprise tiers offer BAA-eligible configurations. Free tiers of generic analytics tools typically do not.

Email delivery: SendGrid, Amazon SES.

Customer support: Zendesk and Intercom, if they handle patient inquiries.

If a vendor won’t sign a BAA, you have one option: keep ePHI out of their service entirely.

The BAA Fallacy

A common misconception: “We signed a BAA with AWS, so we’re HIPAA compliant.” This is wrong. The cloud provider’s BAA and compliance covers the infrastructure layer: physical security, hypervisor, storage encryption at the disk level. Your application code, access controls, audit logging, data isolation, and every other vendor in your stack remain your problem. The 80% of obligations that sit above the infrastructure layer are yours.

For teams building healthcare marketplaces or SaaS products and navigating these complexities, see how we built a healthcare training marketplace for Patcom Medical.

Infrastructure and Architecture Terms

These terms address the architectural decisions that determine whether your SaaS product can pass a HIPAA audit.

Multi-Tenant Isolation

If your SaaS serves multiple healthcare organizations from a shared infrastructure, you must demonstrate that one tenant cannot access another tenant’s ePHI. Common patterns include row-level security (RLS), schema-based isolation, and database-per-tenant architectures.

The critical point: OCR auditors now request penetration testing evidence specifically targeting tenant boundaries. Row-level security policies are not sufficient proof without validation through actual testing. Your annual pen test scope must explicitly include tenant isolation attack scenarios.

Shared Responsibility Model

Cloud providers publish shared responsibility models that delineate what they secure versus what you secure. In general: they secure the cloud (physical infrastructure, hypervisor, managed service internals). You secure what you put in the cloud (application code, IAM policies, network configuration, data classification, encryption key management, and access controls).

Data Flow Mapping

A documented map showing how ePHI flows through your system, from entry to storage to processing to exit. This includes third-party touchpoints where ePHI leaves your infrastructure (analytics services, email providers, support tools). Your data flow map is both an engineering artifact and an audit artifact. Without it, you cannot conduct an adequate SRA.

Tracking Pixel Violations

This is a sleeper HIPAA violation that has caught many SaaS companies off guard. A Meta Pixel, Google Analytics snippet, or Mixpanel tracker on an authenticated page that displays patient data constitutes unauthorized PHI disclosure to a third party without a BAA. OCR auditors review application source code and network traffic to verify no unauthorized data transmission occurs.

The engineering solution: remove all third-party tracking scripts from authenticated pages entirely, or migrate to server-side analytics where you control exactly which data points are transmitted and to whom. Client-side tracking pixels on pages containing ePHI are a breach notification trigger.

CI/CD Pipeline Security

Your deployment pipeline is an ePHI access path. Environment variables containing database credentials, API keys for ePHI-containing services, and deployment access to production infrastructure all constitute access to ePHI. This means your CI/CD pipeline requires MFA, access logging, and role-based access controls just like any other system touching patient data.

Credentials should never live in plain-text environment variables. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) and rotate credentials regularly. For teams scaling their DevOps maturity alongside HIPAA readiness, see how we implemented CI/CD and multi-environment automation for Arketa.

Vulnerability Management

The proposed NPRM introduces annual penetration testing and biannual vulnerability scanning as explicit requirements. Even before the rule finalizes, OCR expects evidence of regular security testing. Your pen test scope should include: external perimeter, authenticated application testing, tenant isolation boundaries, API security, and privilege escalation.

Technology Asset Inventory and Network Map

Another new requirement under the proposed NPRM: an annual technology asset inventory and network map. Document every system, service, and network segment that stores or transmits ePHI. This inventory feeds directly into your SRA and your data flow map.

Compliance and Audit Terms

Understanding how HIPAA enforcement works helps your engineering team prioritize the right controls.

OCR Risk Analysis Initiative

The Office for Civil Rights (OCR) within HHS enforces HIPAA. In 2024-2025, OCR resolved 43 violation cases with financial penalties totaling over $16 million. The Risk Analysis Initiative, launched in fall 2024, specifically targets organizations that fail to conduct adequate risk analyses. The message is clear: a half-baked SRA is the fastest path to an enforcement action.

NPRM (Notice of Proposed Rulemaking)

The proposed Security Rule overhaul published January 6, 2025. Key changes for engineering teams:

• All safeguards become mandatory (no more “addressable” vs. “required”)
• MFA required for all ePHI access
• Encryption mandated at rest (AES-256) and in transit (TLS 1.2+)
• 72-hour system restoration after security incidents
• Annual penetration testing and biannual vulnerability scans
• Business associate annual written verification of technical safeguards
• Access termination within one hour of employee separation
• Workforce training within 30 days of hire
• Annual technology asset inventory and network map

The expected final rule is May 2026 with a 240-day compliance window. Teams that start preparing now will have a smooth transition. Teams that wait will face an expensive scramble.

The “HIPAA Certification” Myth

There is no such thing as HIPAA certification. No government agency certifies organizations as HIPAA compliant. Any vendor claiming to be “HIPAA certified” is either confused or misleading you. What exists: third-party assessments (like those from A-LIGN or Coalfire) that validate your compliance posture, and frameworks like HITRUST that integrate HIPAA requirements into a certifiable standard.

HITRUST vs. HIPAA

HITRUST CSF is a voluntary certification framework that integrates over 60 standards, including HIPAA, NIST, and ISO 27001. HIPAA is federal law. Most startups begin with HIPAA compliance and add HITRUST later when enterprise clients require it for sales cycles. HITRUST is expensive and time-consuming, but it provides a recognized certification that HIPAA alone cannot offer.

SOC 2 and HIPAA Overlap

SOC 2 Type II and HIPAA share significant overlap in areas like access control, encryption, monitoring, and incident response. But they are not substitutes for each other. SOC 2 addresses general security practices; HIPAA addresses specific requirements for ePHI. Many healthcare SaaS companies pursue both, using shared controls to reduce the total effort.

Penalty Tiers (2025 Adjusted Amounts)

Current penalty tiers:

• Tier 1 (lack of knowledge): $137 to $68,928 per violation
• Tier 2 (reasonable cause): $1,379 to $68,928 per violation
• Tier 3 (willful neglect, corrected within 30 days): $14,602 to $73,011 per violation
• Tier 4 (willful neglect, not corrected): $73,011 to $2,190,294 per violation

A single breach can involve thousands of individual violations, one per affected record. The math gets severe fast.

Offshore and Distributed Team HIPAA Controls

Many SaaS startups use distributed teams across multiple countries. HIPAA does not prohibit this, but it adds requirements that engineering leaders must address head-on.

HIPAA Follows the PHI, Not Geography

There is no geographic exemption. Any person or entity that creates, receives, maintains, or transmits ePHI is subject to HIPAA requirements, regardless of their physical location. If your engineers in any country access production ePHI, HIPAA applies to that access.

Workforce vs. Business Associate Distinction

Members of your workforce (paid employees, volunteers, trainees, and temporary staff under your direct control) are not business associates. You are responsible for training them and supervising their PHI access, but they don’t sign BAAs. Independent contractors and consultants typically are business associates and should sign one.

Recommended Controls for Distributed Teams

Practitioners and compliance consultants recommend the following controls for teams with offshore or distributed ePHI access:

• Virtual Desktop Infrastructure (VDI): Engineers access ePHI through virtual workspaces. No data is stored on local machines.
• Data Loss Prevention (DLP): Block copy/paste and local downloads from production environments containing ePHI.
• Geo-fencing: Restrict ePHI access to authorized geographic regions.
• Just-in-time access: Grant production ePHI access only when needed for specific tasks, with automatic expiration.
• De-identification and tokenization: The preferred approach. Offshore teams work with de-identified or tokenized data, with re-linking only on controlled US systems.
• Device encryption and background checks: Required for all team members with potential ePHI access.
• Right-to-audit clauses: Include in all agreements with offshore operations.

Building a healthcare SaaS product with distributed teams requires engineering leadership that understands both compliance and delivery. Learn about our background-checked US and Türkiye engineering team.

Compliance Cost and Timeline

Setting realistic expectations matters. Here are practitioner-reported numbers:

• Small SaaS/startups: $5,000 to $25,000 first year for basic compliance. Ongoing: $2,000 to $10,000 per year.
• Full implementation timeline: 4 to 6 months to audit readiness.
• Internal time investment: Self-managing a rigorous program takes 550 to 600 hours of internal engineering and leadership time annually.

One critical lesson from HIPAA Vault’s application development guide: “Security requirements should be integrated during the architecture phase. Adding compliance later can require significant redesigns.” This aligns with what practitioners consistently report. Retrofitting HIPAA readiness onto an existing SaaS product costs two to five times more than building it in from day one.

The Consolidated HIPAA Readiness Checklist for Healthcare SaaS Engineering

This is the checklist your engineering team can print, assign owners to, and track against. Each item maps to the detailed explanations above.

Risk Analysis and Governance

• [ ] Annual Security Risk Analysis completed and board-signed
• [ ] Risk Management Plan with owners and timelines for each finding
• [ ] Security Officer formally designated and documented
• [ ] Technology asset inventory and network map (annual update)
• [ ] ePHI data flow map documented (entry, storage, processing, exit, third-party touchpoints)

Access Controls

• [ ] Unique user IDs for every person and service accessing ePHI
• [ ] No shared accounts (including service accounts, database connections, API keys)
• [ ] RBAC implemented with minimum necessary access
• [ ] MFA enforced on all ePHI access paths (application, admin panels, cloud console, CI/CD, database tools, VPN)
• [ ] Access termination procedure documented (one-hour target for separations)
• [ ] Emergency access (break-glass) procedure documented and logged

Encryption

• [ ] Encryption at rest (AES-256) enabled for all ePHI data stores (databases, backups, file storage, caches)
• [ ] KMS key rotation enabled
• [ ] Encryption in transit (TLS 1.2 minimum, 1.3 preferred) for all traffic including internal microservices

Audit Logging

• [ ] Centralized, immutable audit logs (WORM storage or Object Lock)
• [ ] Logs capture who, what, when, where, and action taken
• [ ] NTP synchronization across all systems
• [ ] Six-year log retention configured and verified

Vendor and BAA Management

• [ ] BAA signed with all healthcare clients
• [ ] BAA signed with all subprocessors (cloud, logging, monitoring, error tracking, analytics, email, support tools)
• [ ] BAA registry maintained as living document (tool, BAA status, date signed, renewal date, ePHI scope)
• [ ] Third-party scripts audited on all authenticated pages
• [ ] Tracking pixels removed from or migrated to server-side on authenticated pages

Testing and Vulnerability Management

• [ ] Annual penetration testing with tenant isolation in scope
• [ ] Biannual vulnerability scanning
• [ ] Backup restore testing (at least annually)
• [ ] Incident response plan tested via tabletop exercise

Workforce and Training

• [ ] Workforce training within 30 days of hire
• [ ] Annual training refresher
• [ ] Training completion timestamps documented

Physical and Device Security

• [ ] Full-disk encryption on all devices accessing ePHI
• [ ] MDM with remote wipe capability
• [ ] Screen lock and password policies enforced
• [ ] Media disposal and decommissioning procedures documented

Disaster Recovery

• [ ] Disaster recovery plan with documented RPO and RTO
• [ ] 72-hour system restoration capability demonstrated
• [ ] Backup integrity verified through actual restore

Distributed Team Controls (If Applicable)

• [ ] VDI or virtual workspaces for remote ePHI access
• [ ] DLP policies blocking copy/paste and local downloads
• [ ] Geo-fencing for ePHI access
• [ ] Just-in-time access with automatic expiration
• [ ] De-identification or tokenization for offshore data access
• [ ] Background checks for all personnel with ePHI access
• [ ] Device encryption requirements enforced
• [ ] Right-to-audit clauses in agreements

For healthcare SaaS teams looking for engineering partners with compliance sensibility, explore our strengths and capabilities or see our full client portfolio.

Building HIPAA Readiness as an Engineering Capability

HIPAA readiness for healthcare SaaS engineering is not a gate you pass through once. It is an ongoing capability that your team maintains, tests, and improves. The SRA gets updated annually. The BAA registry gets checked every time you add a tool. Audit logs get monitored continuously. Pen tests happen on a schedule.

The teams that treat compliance as an engineering discipline, integrated into their architecture, CI/CD pipeline, and sprint planning, win audits and close enterprise healthcare deals. The teams that treat it as a last-minute paperwork exercise get caught by OCR enforcement or, worse, by an actual breach.

The proposed NPRM changes make 2025 and 2026 the most important years to get your HIPAA engineering foundation right. The elimination of “addressable” safeguards means every control on this checklist is moving toward mandatory status. Preparing now gives your team a 240-day head start over competitors who wait for the final rule.

If your team is building healthcare SaaS and needs engineering support with built-in compliance awareness, get in touch for a free consultation.

Frequently Asked Questions

Is there such a thing as HIPAA certification?

No. No government agency certifies organizations as HIPAA compliant. Third-party assessors can evaluate your compliance posture, and frameworks like HITRUST offer certifiable standards that incorporate HIPAA requirements, but “HIPAA certified” is not a real designation. Any vendor using that term is either misinformed or being misleading.

Does signing a BAA with AWS or GCP make my SaaS HIPAA compliant?

Not even close. Your cloud provider’s BAA covers the infrastructure layer, roughly 20% of your total Security Rule obligations. Your application code, access controls, audit logging, data isolation, vendor chain, and administrative safeguards remain entirely your responsibility.

How long does it take to achieve HIPAA readiness for a new SaaS product?

Practitioners report 4 to 6 months for full audit readiness, assuming the team is actively working on it. Self-managing the program requires 550 to 600 hours of internal engineering and leadership time annually. First-year costs for small SaaS companies typically range from $5,000 to $25,000, depending on complexity and whether you use external assessors.

What is the most common HIPAA violation OCR enforces?

Failure to conduct an adequate Security Risk Analysis. OCR’s Risk Analysis Initiative, launched in fall 2024, resulted in seven enforcement actions in its first six months. Every single case involved an inadequate or missing risk analysis.

Do HIPAA requirements apply to offshore engineering teams?

Yes. HIPAA follows the PHI, not geography. If offshore engineers access production ePHI, all HIPAA requirements apply to that access. Recommended controls include VDI, DLP policies, geo-fencing, just-in-time access, and de-identification. The preferred approach is to ensure offshore team members only work with de-identified or tokenized data.

What are tracking pixel violations and why should engineers care?

A third-party tracking pixel (Meta Pixel, Google Analytics, Mixpanel) on an authenticated page that displays patient data transmits user identifiers to a third party without a BAA. This constitutes unauthorized PHI disclosure and triggers breach notification requirements. OCR auditors review application source code and network traffic to detect this. The fix: remove third-party scripts from authenticated pages or use server-side analytics.

What changes are coming in the proposed HIPAA Security Rule NPRM?

The biggest change is eliminating the distinction between “addressable” and “required” safeguards. MFA, encryption at rest, encryption in transit, annual pen testing, and biannual vulnerability scans all become mandatory. Other additions include 72-hour system restoration requirements, one-hour access termination for separated employees, and annual written verification from business associates. The final rule is expected by May 2026 with a 240-day compliance window.

How much does a healthcare data breach cost on average?

The average cost of a healthcare data breach was $7.42 million in 2025 according to IBM’s Cost of a Data Breach Report. Healthcare has been the most expensive industry for breaches for 14 consecutive years.