The Office for Civil Rights (OCR) closed 2025 with 21 settlements and civil monetary penalties — the second highest annual total in HIPAA enforcement history. The same year, 710 large healthcare data breaches were reported to the HHS, exposing the protected health information of approximately 62 million individuals.
The enforcement posture for 2026 is tighter. 76% of 2025 OCR enforcement actions included a penalty for risk analysis failure — and the OCR Director has confirmed that 2026 enforcement will expand to include risk management as well as risk analysis. Civil monetary penalties now run from $145 to $2,190,294 per violation, depending on culpability tier.
For organisations building custom healthcare software, these numbers have a direct implication: HIPAA compliance is not a checkbox added after the system is built. It is a set of architectural decisions that determine what you can build, how you can build it, and who bears liability when it fails.
What PHI Is and Why the Stakes Are Higher Than Most Developers Assume
Protected Health Information (PHI) is any information relating to a person’s physical or mental health that could identify them. Names, dates of birth, Social Security numbers, photographs, medical record numbers, IP addresses when associated with health data, device identifiers — all PHI. HIPAA’s requirements apply to any system that creates, receives, maintains, or transmits PHI.
The common developer assumption — that PHI protections apply only to the database storing medical records — is the source of many of the most expensive violations. PHI in a URL parameter is a violation. PHI surfaced in a client-side error message is a violation. PHI transmitted over an unencrypted connection is a violation, regardless of whether the transmission was intercepted.
The scope is intentionally broad. HIPAA was written to protect patient information across the entire lifecycle of how systems handle it — not just where it is stored at rest.
What Compliant Software Architecture Requires
HIPAA does not certify software. It sets a framework of requirements that software must satisfy. For custom development, six technical areas are non-negotiable:
Access control. Unique user IDs per individual user — shared credentials are a violation. Role-based permissions scoped to the minimum necessary access. Automatic session timeouts after inactivity. Multi-factor authentication is mandatory, not optional, for any system handling PHI in a production environment.
Audit logs. Every access to PHI must be logged with sufficient detail to reconstruct who accessed what, when, and from where. Audit logs must be tamper-proof — stored separately from application logs with write protection. OCR requests audit logs as a standard document in enforcement investigations. If you cannot produce them, the investigation does not go well.
Encryption. Data in transit must use TLS 1.2 or higher — unencrypted transmission of PHI is an automatic violation regardless of network context. Data at rest must be encrypted on all storage systems. This includes backups, development environments that contain production PHI copies, and third-party services that touch the data.
Data retention and disposal. Retention policies must be explicit: how long PHI is kept, where, under what access controls, and how it is securely deleted when the retention period ends. Deletion must be verified — deletion that can be reversed or that leaves data in backup systems is not deletion.
PHI boundary controls. PHI must never appear in URLs, error messages, log files, or front-end code. These surfaces are where data leaks occur in practice — a patient ID in a query string, a record number in a browser console error, a medical condition in a JavaScript variable that gets sent to a third-party analytics service.
Infrastructure compliance. The hosting environment must support HIPAA compliance. AWS, Google Cloud, and Microsoft Azure can all meet HIPAA requirements when properly configured — but configuration is the operative word. Out-of-the-box cloud configurations are not HIPAA-compliant. Each requires specific service configuration, access controls, and a signed Business Associate Agreement.
Business Associate Agreements — What They Mean and Who Needs One
A Business Associate Agreement (BAA) is a legal contract required between a covered entity and any third party that handles PHI on its behalf. Under HIPAA, any service that “creates, receives, maintains, or transmits” PHI is a Business Associate. The BAA establishes what the Business Associate can do with the data, what security standards it must meet, and what its obligations are in the event of a breach.
Every element of your technology stack that touches PHI needs a BAA:
- Cloud hosting providers (AWS, Google Cloud, Azure all offer BAA programs, but they must be formally executed)
- OCR services for document processing if they handle medical documents
- Authentication providers (Auth0, Okta — check BAA availability; not all plans include it)
- Email delivery services if used to transmit PHI
- File storage and backup services
- Any analytics or observability tool that might capture PHI in requests or logs
The absence of a BAA with a PHI-handling vendor is itself a HIPAA violation — regardless of whether that vendor’s technical security is adequate. OCR has settled over 45 Right of Access cases and numerous BAA-related enforcement actions since 2019. It is a consistent enforcement priority.
Development companies become Business Associates the moment they touch PHI. That creates legal obligations: signing a BAA with the client, implementing internal security protocols, ensuring subcontractors meet HIPAA requirements, and providing breach notification within required timelines.
The Most Common Violations in 2025 — and What Changed for 2026
HIPAA enforcement data from 2025 shows consistent patterns across the 21 resolved enforcement actions:
Failure to conduct and document a risk analysis. This was included in 76% of 2025 enforcement actions — more than any other violation category. A risk analysis is a systematic assessment of the risks to the confidentiality, integrity, and availability of PHI across all systems. It must be current, comprehensive, and documented. OCR requests it as a first-line document in any investigation.
Insufficient access controls. Employees accessing PHI without a valid job-related reason — commonly called snooping — and inadequate technical controls that permit it. Role-based access configured at a level that is broader than the minimum necessary standard.
Missing or inadequate BAAs. Failure to maintain signed BAAs with every PHI-handling vendor. A vendor’s HIPAA marketing language does not substitute for a signed agreement.
Improper PHI disclosure. Transmission of PHI through unencrypted email, misdirected faxes, or any channel that does not meet the minimum security requirements. This includes transmitting PHI to an incorrect recipient — a category that increases with system complexity.
Denial of patient record access. HIPAA requires that patients receive their records within 30 days of a request. Failure to meet this timeline — or refusing reasonable record access requests — has been an active enforcement focus since the Right of Access Initiative launched in 2019.
For 2026, OCR has signalled that risk management — the ongoing process of implementing controls to address identified risks, not just the initial risk analysis — will be added to enforcement focus areas.
Why Custom Solutions Are Often the Right Choice for HIPAA Compliance
Off-the-shelf healthcare software frequently works around HIPAA requirements rather than building from them. Compliance modules are added to existing architectures that were not designed with PHI handling as a core constraint. The result is systems where the compliant path requires extra steps, where audit trail coverage has gaps, and where the development team frequently cannot explain which data flows are covered and which are not.
Custom development inverts this: compliance requirements are architectural inputs, not post-hoc additions.
Security built in, not added. Access control, encryption, audit logging, and PHI boundary controls are designed into the data model and API surface from the start. They are not layers applied over an architecture that did not anticipate them.
Controlled infrastructure. A custom build gives you full specification of the hosting environment, the configuration of cloud services, the selection of third-party vendors, and the BAA structure. You are not inheriting compliance decisions made by a software vendor whose business model may not be aligned with your compliance obligations.
Audit trail designed to the actual requirement. Off-the-shelf audit logs capture what the software vendor decided to capture. Custom audit logging is designed around what your compliance function actually needs to respond to an OCR investigation or an internal audit.
Simplified compliance verification. When every component of the system was built with a documented compliance rationale, demonstrating compliance to an auditor becomes a documentation and access exercise rather than a reverse-engineering exercise.
How we approach this at Insoftex
Healthcare AI is one of our core practice areas, and the compliance-as-architecture principle the article describes is what distinguishes our healthcare builds from general software development work. For our AI-Powered Personalized Healthcare Platform, HIPAA requirements were the first design input, not a compliance checklist at the end of the build. PHI boundary controls — the rule that PHI never appears in URLs, error messages, log files, or front-end code — were enforced at the API layer from the first sprint, not added in a security review before launch.
The BAA architecture question is where we most frequently find gaps when reviewing existing healthcare systems. Teams are often aware they need a BAA with their cloud provider, but miss the authentication provider, the analytics tool that captures request payloads, and the file storage service. Each is a potential PHI exposure without a signed agreement. We map the full data flow — not just the primary data path, but every side channel — before finalising vendor selection.
The audit trail design is where compliance investment pays back most clearly in enforcement contexts. OCR investigations start with a request for the audit log. A healthcare client who can produce a complete, tamper-evident audit log of every PHI access within hours of receiving that request is in a fundamentally different position than one who has to reconstruct access history from application logs that were not designed for that purpose. We design the audit trail to answer the OCR investigation, not just to satisfy a checkbox on the technical safeguards list.
Building healthcare software with AI components and HIPAA obligations? Our healthcare engineering page covers the clinical AI, EHR, and HIPAA-aware systems we build most often. Start with a Product Pilot to map your data flows, identify BAA requirements, and deliver a compliance-first architecture design — fixed scope, three weeks, senior engineers with regulated-industry experience.
Frequently Asked Questions
Does custom healthcare software need to be HIPAA certified?
There is no official HIPAA certification for software — HIPAA does not work that way. What exists is vendor certification programs (like HITRUST) that demonstrate conformance to a defined security framework, and OCR enforcement, which is retrospective. A development company cannot obtain HIPAA certification for you; it can build software that meets HIPAA's technical and administrative requirements. The covered entity — the healthcare organisation or provider — bears ultimate responsibility for the compliance of their systems. A development partner who handles PHI becomes a Business Associate with its own obligations under the law.
What is the most common reason custom healthcare software fails a HIPAA audit?
Missing or incomplete documentation of the risk analysis is the most common failure in OCR enforcement — present in 76% of 2025 enforcement actions. An undocumented risk analysis is treated the same as a missing one. The second most common failure is BAA gaps: PHI-handling vendors operating without signed agreements. Both of these are documentation and process failures, not technical architecture failures. Systems with technically sound security can still fail enforcement if the administrative documentation is not in order.
Which cloud providers support HIPAA-compliant healthcare software?
AWS, Google Cloud, and Microsoft Azure all offer HIPAA-compliant service configurations and BAA programs. However, HIPAA compliance in a cloud environment is a shared responsibility model: the provider secures the infrastructure; the customer is responsible for the configuration of services running on that infrastructure. A misconfigured S3 bucket, an unauthenticated API endpoint, or a logging configuration that captures PHI in plain text are customer-side compliance failures, not provider failures. Every cloud deployment requires a review of the specific service configurations and their PHI handling implications, not just a check that the provider offers a BAA.
How does HIPAA apply to AI and machine learning components in healthcare software?
AI and ML components that process, analyse, or generate outputs from PHI are subject to HIPAA's full requirements. This includes the training data used to build the model (if it contains PHI), the inference inputs processed by the model in production, the outputs generated and how they are stored or transmitted, and any third-party AI service used as part of the system — which requires a BAA if it handles PHI. AI introduces specific risks: training data that contains PHI must be handled under the same controls as production PHI; model outputs that surface PHI must be treated as PHI; and AI services with broad data retention policies may conflict with HIPAA's minimum necessary standard.
What should a healthcare software development contract include for HIPAA compliance?
At minimum: a signed Business Associate Agreement covering the development company's obligations, a defined scope of which systems and data flows the BAA covers, documented security requirements that map to HIPAA's technical safeguard standards (access control, audit logging, encryption, transmission security), a breach notification protocol specifying timelines and responsibilities, and a defined handoff process for production deployment including security configuration review. If the development company has subcontractors who will touch PHI, those subcontractors must also be covered by BAAs. The contract should specify who is responsible for the ongoing risk analysis documentation — this is frequently missed.