What Your Cloud Provider Isn't Telling You About HIPAA
The gap between HIPAA-eligible and HIPAA-compliant is where companies get fined
AWS will sign a BAA. So will Azure. So will GCP.
That BAA covers their infrastructure -- not your application.
HIPAA-eligible vs HIPAA-compliant
When AWS says a service is "HIPAA-eligible," they mean you can use it in a HIPAA-compliant architecture. They don't mean your architecture is compliant. They mean the bricks are safe. Whether the building meets code is your problem.
S3 encrypts data at rest. That's AWS's responsibility. Whether your application checks for a signed BAA before writing PHI to S3 -- that's yours. Whether your API prevents unauthorized access to patient records -- yours. Whether your outbound emails strip PHI before sending -- yours.
The cloud provider handles infrastructure security. Application-layer compliance is entirely on you.
Where companies get fined
The fines don't come from unencrypted S3 buckets. The fines come from:
An employee accessing records they shouldn't. An email containing patient data sent to the wrong address. A business associate receiving PHI without a signed agreement. An audit trail that doesn't exist because nobody configured logging.
All of these are application-layer problems. The cloud provider's BAA doesn't touch them.
What application-layer compliance looks like
Every API request checked against a signed BAA. Every data field screened for PHI identifiers. Every outbound communication moderated for protected information. Every access logged with timestamps and user identity. Every published report blocked if it contains unmasked PHI.
This is what Chaprola does. Not because it's optional. Because an AI agent processing healthcare data will make every mistake a human would make, faster, at scale, without anyone noticing until the breach report is due.
The cloud provider gives you HIPAA-eligible bricks. Someone still has to build the walls, install the locks, and check who walks through the door.