Why HIPAA Compliance Starts at the Application Layer – Not the Cloud

A Series B digital health company came to us after failing a compliance assessment. They had done everything “right”: HIPAA-eligible AWS services, signed Business Associate Agreement (BAA), encrypted databases, SOC 2-certified infrastructure. Yet the assessor’s report listed 23 critical findings – none of them related to their hosting.

The gaps were all in their application code: no audit logging for protected health information (PHI) access, shared admin credentials across the engineering team, session tokens that never expired, and API endpoints transmitting patient data without encryption verification. Their cloud infrastructure was compliant. Their application was not.

This pattern repeats across healthcare technology. The assumption that “we use AWS with a BAA, so we’re HIPAA compliant” is the most expensive misconception in health tech – and it’s costing organisations millions in breach remediation, regulatory penalties, and lost enterprise contracts.

Healthcare data breaches now cost an average of $9.77 million per incident (IBM/Ponemon, 2024) – the highest of any industry for 14 consecutive years. The majority stem from application-layer failures, not infrastructure compromises. HHS Office for Civil Rights (OCR) enforcement data confirms it: risk analysis failure – the absence of documented application-level security assessments – is cited in nearly every major penalty.

This guide explains exactly where compliance responsibility lies, what controls your development team must implement, and how to evaluate whether your healthcare applications are truly compliant – not just hosted on compliant infrastructure.

Last updated: February 2026
By: Kevin Yamazaki, Partner, CEO at Sidebench

What does a cloud BAA actually cover – and what doesn’t it cover?

A Business Associate Agreement with AWS, Azure, or GCP covers their physical infrastructure and foundational services – not your application’s handling of protected health information (PHI). The BAA makes your cloud provider contractually liable for their data centres and hardware. Everything above that layer is your responsibility.

Microsoft’s own Azure HIPAA documentation is explicit: “By offering a BAA, Microsoft helps support your HIPAA compliance, but using Microsoft services does not on its own achieve it. Your organization is responsible for ensuring that you have an adequate compliance program and internal processes in place.”

The Cloud Security Alliance reinforces this: “No cloud platform is inherently HIPAA compliant. Large public clouds may support HIPAA compliance, but they cannot offer or guarantee it because compliance comes not from having a certain kind of technology or platform, but rather from configuring the platform in the appropriate ways.”

BAA coverage: What’s included vs. what’s not

How does the shared responsibility model apply to HIPAA?

The shared responsibility model divides HIPAA compliance into distinct layers: your cloud provider secures “the cloud” (infrastructure), while you secure everything “in the cloud” (platform configuration, applications, data, and identity). Healthcare organisations own four of the five compliance layers outright.

Azure’s healthcare guidance states: “Healthcare organizations control and are responsible for everything above the infrastructure layer.” This includes your application architecture, data handling procedures, access control implementation, and audit logging – regardless of how compliant your underlying infrastructure might be.

The five layers of HIPAA compliance responsibility

What application-layer controls does HIPAA require?

The HIPAA Security Rule (45 CFR Section 164.312) mandates four categories of technical safeguards at the application layer: access controls, audit controls, integrity controls, and transmission security. These apply to any system creating, receiving, maintaining, or transmitting electronic protected health information (ePHI) – and OCR expects all four to be implemented or documented.

Your cloud provider cannot implement these for you. They must be built into your application code, tested, documented, and regularly reviewed. Here’s what each category requires:

1. Access Controls (45 CFR Section 164.312(a))

Every healthcare application must implement technical policies allowing only authorised persons to access ePHI:

2. Audit Controls (45 CFR Section 164.312(b))

This is where most applications fail. HIPAA requires “hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” Cloud provider logs capture infrastructure events – not who accessed which patient record at what time.

3. Integrity Controls (45 CFR Section 164.312(c))

Mechanisms to authenticate ePHI and corroborate that data hasn’t been altered or destroyed without authorisation. In practice: checksums, digital signatures, version control, and data validation at API boundaries.

4. Transmission Security (45 CFR Section 164.312(e))

Guard against unauthorised access during electronic transmission. Minimum standard: TLS 1.2 or higher for all data in transit. This includes internal API calls, not just external-facing endpoints. We’ve seen applications with perfect front-end encryption but unencrypted service-to-service communication within their own VPC.

What are the most expensive application-layer compliance failures?

OCR enforcement data reveals five consistent patterns in major HIPAA penalties. All five occur at the application layer – failures that signing a cloud BAA does nothing to prevent. The most commonly cited violation across all enforcement actions is risk analysis failure: organisations either lack documented security assessments or have assessments that ignore application-layer risks.

Failure 1: Assuming BAA = compliance

Organisations sign a BAA, then assume compliance is handled. When OCR investigates after a breach, they find no application-level controls, inadequate logging, and missing risk assessments. The BAA is irrelevant – the application was never compliant.

Failure 2: No application-level audit logging

When a breach occurs, the organisation cannot demonstrate who accessed what PHI, when, or what changes were made. Cloud provider logs show infrastructure events (“EC2 instance started”) but not application events (“User 4521 viewed patient record 8834”). Without application logs, breach scope assessment becomes guesswork – and penalties multiply.

Failure 3: Inadequate access controls

Memorial Healthcare System paid $5.5 million for insufficient ePHI access controls. Common issues: shared login credentials, missing RBAC, failure to revoke access on termination, no unique user identification, missing MFA. These are all application-layer controls – infrastructure can’t implement them for you.

Failure 4: Using non-HIPAA-eligible services

Not all services within AWS/Azure/GCP are covered by the BAA. Azure OpenAI only covers production-level text-based interactions (as of February 2026). Azure Computer Vision and Face API are not HIPAA-eligible by default. Preview features are generally excluded. You must verify each service against the provider’s current HIPAA-eligible services list before processing PHI.

Failure 5: Third-party SDK and analytics leakage

HHS clarified in March 2024 that tracking technologies transmitting PHI to third parties (Google Analytics, Meta Pixel, TikTok) violate HIPAA. Advocate Aurora Health exposed 3 million individuals; Cerebral exposed 3.1 million. These weren’t infrastructure breaches – they were JavaScript snippets in application code sending patient data to advertising networks.

Recent OCR enforcement: Application-layer penalties

How should we evaluate if a vendor is truly HIPAA compliant?

Evaluate vendors by probing their application-layer controls, not their hosting certifications. Ask specific questions about access controls, audit logging, encryption implementation, and risk assessment methodology. Vendors who understand compliance will answer with architectural detail. Vendors who don’t will deflect to “we use AWS” or “we’re SOC 2 certified.”

Questions that reveal true compliance posture

What’s the compliance decision framework for build vs. buy?

The build vs. buy decision for healthcare applications isn’t just about features and cost – it’s about compliance ownership. Building custom means you own every control; buying transfers some responsibility (with a BAA) but not all. The right choice depends on your compliance maturity, technical capacity, and risk tolerance.

Compliance ownership by approach

Decision logic

• If you have unique clinical workflows that no existing platform supports then Build custom (but budget 6+ months for compliance architecture)
• If you need standard functionality (scheduling, patient portal, EHR integration) then Buy (but audit vendor’s application-layer controls, not just their certifications)
• If you need differentiated patient experience with commodity back-end then Hybrid (custom front-end, compliant platform for PHI processing)
• If you’re evaluating an acquisition or partnership then Audit first (compliance gaps discovered post-deal are expensive)

Frequently Asked Questions

Does our cloud BAA cover our custom application code?

No. Your BAA with AWS, Azure, or GCP covers their infrastructure services – not your application’s handling of PHI. You’re responsible for implementing access controls, audit logging, encryption, and authentication within your application code. The cloud provider’s compliance does not transfer to your software. When OCR investigates a breach, they examine your application controls, not Amazon’s data centres.

What audit logs does HIPAA require us to keep?

HIPAA requires application-level audit logs tracking PHI access: who accessed what data, when, what actions were performed (create, read, update, delete), and from what device or location. These logs must be retained for six years minimum. Infrastructure logs alone are typically insufficient to demonstrate user-to-record access patterns required for HIPAA audit controls.

What’s the most common reason OCR imposes HIPAA penalties?

Risk analysis failure is cited in nearly every major enforcement action. Organisations either have no documented risk assessment or have assessments that don’t address application-layer risks. OCR’s Risk Analysis Initiative specifically targets this gap, with increased enforcement activity in 2024-2025. A breach investigation typically starts with the incident but results in penalties for pre-existing compliance gaps – especially missing risk assessments.

How long does application-layer compliance remediation take?

Timeline depends on current state and application complexity. Adding comprehensive audit logging typically requires 4-8 weeks. Implementing proper RBAC takes 6-12 weeks. A full compliance architecture review and remediation for a complex application may require 3-6 months. Organisations that designed for compliance from the start (as we did with Cortica’s AXON platform) avoid this remediation entirely.

Are all AWS/Azure/GCP services HIPAA-eligible?

No. Each cloud provider maintains a specific list of HIPAA-eligible services, and it changes. Preview features, some AI services, and certain configurations are excluded from BAA coverage. Azure OpenAI only covers production-level text interactions. You must verify each service against the provider’s current HIPAA-eligible services list before processing PHI – and re-verify when adding new services or upgrading existing ones.

What happens if our vendor has a breach – who’s liable?

Both parties may face liability. As the covered entity, you’re responsible for conducting due diligence and ensuring your business associates are compliant. If you failed to verify their compliance or didn’t have an adequate BAA, you face penalties regardless of where the breach originated. This is why vendor evaluation should focus on application-layer controls, not just certifications – you’re liable for their failures if you didn’t verify properly.

How do we handle third-party SDKs and analytics in healthcare apps?

HHS March 2024 guidance clarified that tracking technologies transmitting PHI to third parties violate HIPAA. Review every third-party SDK for PHI exposure. Many healthcare organisations have removed Google Analytics, Meta Pixel, and similar tools from PHI-handling applications entirely. If you need analytics, use HIPAA-compliant alternatives or implement server-side tracking that strips PHI before any data leaves your controlled environment.

What access controls are required vs. optional under HIPAA?

Unique user identification and emergency access procedures are required. Automatic logoff and encryption are “addressable” – meaning you must implement them or document why an equivalent alternative is appropriate. In practice, all four controls are expected for any modern healthcare application, and “addressable” is not a loophole. OCR interprets addressable specifications as required unless you can demonstrate an equivalent level of protection.

How do we know if our development team is building HIPAA-compliant software?

Review their implementation of the four technical safeguard categories: access controls, audit controls, integrity controls, and transmission security. Ask them to demonstrate application-level audit logs, explain their RBAC implementation, and show encryption configuration. If they can’t produce this documentation or haven’t thought about these requirements, compliance gaps exist. Consider a compliance architecture review before your next release.

How do we conduct a risk analysis for our applications?

Follow the NIST Cybersecurity Framework or HHS guidance. Identify all systems that create, receive, maintain, or transmit ePHI. Document threats and vulnerabilities specific to each system – including application-layer risks, not just infrastructure. Assess likelihood and impact for each risk. Implement controls proportionate to risk level. Document everything. Repeat annually or when significant changes occur. This documentation is what OCR requests first in any investigation.

Key Takeaways

1. Your cloud BAA covers infrastructure, not your code – The majority of HIPAA violations occur at the application layer. Signing a BAA with AWS doesn’t make your application compliant.
2. Application-level audit logging is non-negotiable – cloud provider logs don’t capture PHI access. You need logs showing who accessed what patient data, when, and from where.
3. Risk analysis failure is the #1 enforcement trigger – OCR’s Risk Analysis Initiative is actively pursuing organisations with missing or inadequate application-layer assessments.
4. Not all cloud services are HIPAA-eligible – verify each service against your provider’s current list before processing PHI. Preview features are almost never covered.
5. Vendor due diligence must probe application controls – ask about RBAC, audit logs, and risk assessments. Vendors who deflect to certifications likely have gaps.
6. Healthcare breaches cost $9.77M on average – the highest of any industry for 14 consecutive years (IBM/Ponemon, 2024). Application-layer compliance isn’t optional.
7. Behavioral health organizations face additional complexity – 42 CFR Part 2 requirements add consent management layers on top of standard HIPAA controls.

Need to Assess Your Application’s Compliance Posture?

Our team has architected HIPAA-compliant platforms for 50+ healthcare organisations – from compliance tooling for PCIHIPAA to patient platforms handling millions of transactions.

Talk to Our Team →

Cited Data Sources

1. NIST Cybersecurity Framework – Cybersecurity Framework | NIST
2. HHS OCR Enforcement Data – Enforcement Data | HHS.gov
3. OCR 2018 Enforcement Record – OCR Concludes 2018 with All-Time Record Year for HIPAA Enforcement
4. Premera Blue Cross Settlement – Health Insurer Pays $6.85 Million to Settle Data Breach
5. Memorial Healthcare Systems – Memorial Healthcare Systems to pay $5.5M over potential HIPAA violations
6. HIPAA Security Rule Technical Safeguards – eCFR :: 45 CFR 164.312 — Technical safeguards
7. 42 CFR Part 2 Final Rule – Fact Sheet 42 CFR Part 2 Final Rule