- “Is my software HIPAA compliant?” is not a yes/no question — compliance depends on your implementation, policies, infrastructure, and operational controls, not a vendor label.
- There is no official HIPAA certification for software; HHS and OCR explicitly state they do not certify any product as “HIPAA compliant”.
- Healthcare data breaches cost an average of $9.77 million per incident in 2024, more than twice the cross-industry average — making non-compliance a serious financial liability (IBM Cost of a Data Breach Report 2024).
- A signed Business Associate Agreement (BAA) is a non-negotiable legal requirement for any vendor that stores, processes, or transmits Protected Health Information (PHI) on your behalf.
- Technical safeguards alone, including encryption, are necessary but not sufficient. Administrative and physical safeguards, annual risk assessments, and documented policies are equally required under the HIPAA Security Rule.
Is your software HIPAA compliant, or does it just claim to be? With 742 large healthcare data breaches reported to the HHS Office for Civil Rights (OCR) in 2024 alone (HIPAA Journal, 2025), the stakes for getting this wrong have never been higher.
For SaaS founders, CTOs, and healthcare startups entering the US market, HIPAA compliance is not a checkbox; it’s a continuous operational commitment with serious legal and financial consequences.
This guide breaks down exactly what HIPAA compliance means for software, how to evaluate whether your application meets the standard, and what commonly overlooked gaps expose healthcare organizations and their vendors to regulatory penalties.
Intigate Technologies helps SaaS founders and healthcare startups architect HIPAA-ready software from the ground up — before a compliance gap becomes a breach headline.
Book a Free Compliance Architecture Review →What Does HIPAA Compliance Mean for Software?
What Is HIPAA?
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a US federal law that sets national standards for protecting sensitive patient health information.
It applies to two primary groups: covered entities (hospitals, clinics, health plans, healthcare clearinghouses) and business associates — any third-party vendor, SaaS platform, or service provider that handles Protected Health Information (PHI) on behalf of a covered entity.
If your software touches patient data in any way, your organization almost certainly qualifies as a business associate.
What Counts as PHI and ePHI?
Protected Health Information (PHI): Any individually identifiable health information, including medical records, diagnoses, treatment history, billing data, insurance details, and 18 specific patient identifiers such as name, address, date of birth, Social Security number, and IP address — when linked to health data.
ePHI refers to PHI stored, transmitted, or processed electronically. This includes data in cloud databases, mobile apps, APIs, EHR systems, telehealth platforms, and AI diagnostic tools.
Can Software Actually Be “HIPAA Certified”?
No. This is one of the most dangerous misconceptions in healthcare technology.
The HHS Office for Civil Rights (OCR) explicitly states: HHS and OCR do not endorse any private consultants’ or education providers’ seminars, materials, or systems, and do not certify any persons or products as “HIPAA compliant.” (HHS.gov)
When vendors claim their software is “100% HIPAA certified,” that language is misleading at best, and potentially fraudulent. The correct framing is:
- HIPAA-ready: The platform has built-in controls that support compliance.
- HIPAA-capable: The infrastructure can be configured for compliance.
- Fully compliant operational environment: Your entire implementation — including policies, training, BAAs, and infrastructure — meets all HIPAA rule requirements.
Compliance is an operational state, not a product feature.
How to Know If Your Software Is HIPAA Compliant
Does the Software Store, Process, or Transmit PHI?
The first question is scope. If your application collects, stores, transmits, or processes any ePHI, including through APIs, AI models, cloud storage, or mobile interfaces, it falls under HIPAA’s Security Rule and must implement corresponding safeguards.
This includes SaaS platforms, telemedicine apps, patient portals, medical billing tools, and healthcare AI assistants.
When building or evaluating such software, consider reviewing complementary regulatory requirements. Our GDPR Compliant App Development Guide covers overlapping data privacy obligations for healthcare platforms serving EU patients.
Does the Vendor Sign a Business Associate Agreement (BAA)?
A Business Associate Agreement (BAA) is a legally binding contract between a covered entity and any vendor that handles ePHI on its behalf.
It obligates the vendor to implement appropriate safeguards, report breaches, and restrict the use of PHI to permitted purposes.
No BAA = No HIPAA compliance. Period. If a SaaS vendor, cloud provider, or analytics tool refuses to sign a BAA, you cannot legally use that platform with PHI.
Even though AWS, Google Cloud, and Microsoft Azure are not automatically HIPAA compliant, each offers BAAs, but compliance depends entirely on how you configure and use their services.
Is Data Encrypted at Rest and in Transit?
Encryption is one of the most critical technical safeguards under the HIPAA Security Rule. Best-practice standards include:
- AES-256 encryption for data at rest
- TLS 1.2 or 1.3 for data in transit
- Secure key management with access-controlled key storage (e.g., AWS KMS, Azure Key Vault)
Note: Encryption alone does not make software HIPAA compliant. It is one of the required controls among many.
Are Access Controls Implemented?
The HIPAA Security Rule requires software to enforce strict access control policies. This includes Role-Based Access Control (RBAC) to limit PHI access by job function, the principle of least privilege (users access only what they need), unique user IDs for every individual, and Multi-Factor Authentication (MFA) for systems accessing ePHI. Shared login credentials are a direct HIPAA violation.
Does the System Maintain Audit Logs?
Audit logs are a mandatory technical safeguard under 45 CFR § 164.312(b). Compliant software must record all access to and modifications of ePHI, including who accessed data, when, from which device, and what actions were taken. Logs must be tamper-resistant, retained for a minimum of six years, and regularly reviewed for suspicious activity.
Is There a Breach Response Process?
HIPAA’s Breach Notification Rule requires covered entities to notify affected individuals within 60 days of discovering a breach. Software supporting this must include documented incident response workflows, automated breach detection, and data backup and disaster recovery capabilities with defined Recovery Time Objectives (RTOs).
HIPAA Compliance Checklist for Software Applications
Use this checklist to audit your software environment against HIPAA’s core safeguard categories.
Technical Safeguards
| Control | Requirement | Status |
| Data encryption at rest | AES-256 minimum | ☐ |
| Data encryption in transit | TLS 1.2 / 1.3 | ☐ |
| Multi-factor authentication | All PHI-access accounts | ☐ |
| Role-based access control | Least privilege enforced | ☐ |
| Unique user IDs | No shared credentials | ☐ |
| Automatic session timeout | After period of inactivity | ☐ |
| Audit logs | Tamper-resistant, 6-year retention | ☐ |
| Secure API endpoints | Authenticated, rate-limited | ☐ |
| Data backup | Regular, encrypted, tested | ☐ |
Administrative Safeguards
| Control | Requirement | Status |
| Annual risk assessment | Documented, reviewed | ☐ |
| Security policies | Written, accessible | ☐ |
| Employee HIPAA training | Role-appropriate, logged | ☐ |
| Access review procedures | Periodic user audits | ☐ |
| Designated Security Officer | Named individual responsible | ☐ |
Physical Safeguards
| Control | Requirement | Status |
| Secure server facilities | Physical access controls | ☐ |
| Workstation controls | Locked screens, clean-desk policy | ☐ |
| Device management | Mobile device management (MDM) policy | ☐ |
Organizational Requirements
| Control | Requirement | Status |
| BAA with all vendors | Written, signed, current | ☐ |
| Third-party risk assessment | Vendors handling ePHI reviewed | ☐ |
| Vendor management program | Ongoing oversight documented | ☐ |
Common Signs Your Software Is NOT HIPAA Compliant
These are high-risk indicators that your platform may expose you to OCR enforcement action or breach liability:
- Shared user accounts: Multiple staff members using one login
- No audit logging: No record of who accessed or modified PHI
- Missing or unsigned BAA: Vendor handles PHI without a legal agreement
- Unencrypted data storage: PHI stored in plaintext databases or S3 buckets
- PHI transmitted via standard email: Unencrypted email is not a HIPAA-compliant channel
- No documented security policies: Verbal policies don’t satisfy HIPAA requirements
- No annual risk analysis: OCR imposed 10+ financial penalties in 2024 specifically for risk analysis failures
- PHI appearing in application logs: System logs containing patient identifiers violate minimum-necessary standards
HIPAA Compliance Requirements for Different Types of Software
HIPAA Compliance for SaaS Platforms
SaaS platforms that serve healthcare clients must implement BAAs, enforce tenant-level data isolation, and ensure no cross-contamination of PHI between customer accounts.
Choosing the right development partner matters enormously; see our guide on what to look for when hiring a software development company before engaging a vendor to build your healthcare SaaS.
HIPAA Compliance for Mobile Apps
Mobile applications accessing ePHI must enforce MFA, implement certificate pinning to prevent man-in-the-middle attacks, avoid caching PHI on device storage, and use encrypted communication channels for all API calls.
HIPAA Compliance for AI Healthcare Applications
AI tools that ingest, process, or generate output based on ePHI are subject to HIPAA’s full Security Rule.
This includes models trained on patient data, diagnostic assistants, and AI-powered clinical documentation tools.
Training data pipelines, model inference environments, and output logs must all be secured and auditable.
HIPAA Compliance for Cloud Infrastructure
AWS, Azure, and Google Cloud all offer HIPAA-eligible service tiers and will sign BAAs. However, operating on these platforms does not automatically confer compliance.
Your team is responsible for the correct configuration — including VPC isolation, IAM policies, encryption key management, and CloudTrail / audit logging setup.
HIPAA Compliance Mistakes Software Companies Make
- Assuming AWS makes them compliant: Cloud infrastructure eligibility ≠ compliance. Configuration is your responsibility.
- Treating encryption as the finish line: Encryption is necessary but not sufficient. Administrative and physical safeguards are equally required.
- No log retention policy: Audit logs must be retained for 6 years under HIPAA.
- Missing annual risk analysis: OCR’s active 2024–2025 audit initiative specifically targets risk analysis failures.
- Weak or untested employee training: Since most HIPAA breaches involve human error, training is a front-line control, not an HR formality.
- No vendor inventory: Every third-party tool handling ePHI needs a current, signed BAA.
HIPAA Compliance vs. SOC 2 vs. HITRUST
| Framework | Who Requires It | What It Covers | Certification? |
| HIPAA | US law, all covered entities and BAs | PHI privacy, security, breach notification | US law, all covered entities, and BAs |
| SOC 2 Type II | Enterprise customers, investors | Security, availability, and confidentiality controls | Yes, third-party audit report |
| HITRUST CSF | Health insurers, large health systems | Combines HIPAA, NIST, and ISO 27001 | Yes, tiered certification levels |
Healthcare SaaS companies selling to enterprise health systems increasingly need all three: HIPAA compliance as the legal baseline, SOC 2 for general security credibility, and HITRUST for enterprise procurement requirements.
If you’re scoping the build timeline for meeting these standards, our guide on how long it takes to build a custom app walks through realistic development and compliance timelines.
Intigate Technologies builds HIPAA-compliant healthcare software from architecture design to BAA-ready deployments for SaaS companies targeting US healthcare buyers.
Talk to a Healthcare Software Expert →Conclusion
Answering the question “Is my software HIPAA compliant?” requires more than reviewing a vendor checklist.
True compliance is a continuous program, one that spans technical safeguards, administrative policies, physical controls, and legally binding agreements with every vendor that touches ePHI.
With healthcare data breaches costing an average of $9.77 million per incident in 2024 (IBM Cost of a Data Breach Report 2024) and OCR actively conducting enforcement audits through 2025, the cost of non-compliance now substantially exceeds the cost of getting it right the first time.
For software companies building in or entering the US healthcare market, partnering with a development team that understands both the technical and regulatory dimensions of HIPAA is not optional; it is a strategic necessity.
Frequently Asked Questions
Is there an official HIPAA certification for software?
No. The HHS Office for Civil Rights (OCR) explicitly states it does not certify any product, consultant, or training program as “HIPAA compliant.” Vendors using this language are being misleading. Compliance is determined by how software is implemented, operated, and governed, not by any certification body.
Do I need a BAA with every vendor that touches PHI?
Yes. Any cloud provider, SaaS tool, analytics platform, or subprocessor that stores, accesses, or transmits ePHI on your behalf must sign a HIPAA-compliant Business Associate Agreement (BAA) before you can use their services with patient data. Operating without a BAA is a direct HIPAA violation.
Does encryption alone make software HIPAA compliant?
No. Encryption is one required technical safeguard under HIPAA’s Security Rule, but compliance also requires access controls, audit logging, breach notification procedures, documented security policies, employee training, and annual risk assessments. Encryption without the full compliance framework does not satisfy HIPAA requirements.
Can AI healthcare software be HIPAA compliant?
Yes, provided the entire lifecycle, training data handling, inference environments, API security, and output logging, meet HIPAA Security Rule requirements, and a BAA is in place with any AI vendor processing ePHI. As of 2026, AI tools processing patient data are subject to the same HIPAA obligations as any other software handling ePHI.
Is my software HIPAA compliant if it runs on AWS, Azure, or Google Cloud?
Not automatically. AWS, Azure, and Google Cloud offer HIPAA-eligible infrastructure tiers and will sign BAAs, but that does not make your application compliant. Your team remains responsible for secure configuration, IAM policies, encryption key management, audit logging, and all other Security Rule controls. The platform provides the foundation; compliance is built on top of it.
What happens if software violates HIPAA?
Violations can result in civil monetary penalties ranging from $100 to $50,000 per violation category per year (up to $1.9 million annually per violation type), plus mandatory corrective action plans. OCR collected $12.8 million in penalties in 2024 alone. In cases of willful neglect, criminal charges and prosecution are also possible.
