ANONYMIZED · REDACTED · PUBLISHED WITH CONSENT

What HIPAA Shield finds in real healthcare systems.

Every finding shown below is a real finding from a real engagement, with the client and any identifying architecture details redacted. Every CFR citation maps to the live section in our HIPAA coverage map.

Digital health platform (non-profit sector)

Case study CS-001

Client profile

B2B2C digital health platform operating in the non-profit and community-health segment. Web application plus iOS and Android mobile apps. Annual transaction volume in the low eight figures.

Engagement scope

External + authenticated assessment of web app, iOS/Android apps, and Firebase backend. Assessment was triggered by partner procurement diligence ahead of an enterprise contract.

Findings summary

CRITICALHS-001-01

Cross-tenant read access to all organization records via mobile app Firebase backend

§ 164.312(a)(1)§ 164.312(c)(1)§ 164.404

CRITICALHS-001-02

Payout and donation ledger ($19,832 visible) readable by any authenticated mobile app user

§ 164.308(a)(1)(ii)(A)§ 164.312(a)(1)

HIGHHS-001-03

Firestore write rules permit unauthenticated organization document creation

§ 164.312(c)(1)

MEDIUMHS-001-04

Audit log coverage absent on write-side Firestore operations

§ 164.312(b)

What we found

The web application correctly hid sensitive tenant data behind authentication. The mobile app backend did not. An attacker extracted the embedded Firebase config from the Android APK using standard decompilation (apktool + jadx), registered an anonymous account, and read 152 organization records and 1,930 payout entries. They could also write new organization documents to the production database.

Breach Notification Rule exposure

Organization tax identifiers, payout amounts, and donor records were readable across all 152 tenants. Under the Breach Notification Rule, this would have triggered individual and HHS notification if ePHI had been part of the accessible dataset. The writable Firestore rules created integrity-violation exposure under 164.312(c)(1).

Remediation

Firestore security rules rewritten with strict tenant-scoping (organizations patched within 24 hours)
Firebase project API keys rotated
Write-side audit logging added to all PHI-adjacent collections
BAA executed with Firebase covering the covered-entity partner relationship
Full re-test 24 hours post-remediation confirmed all critical findings resolved

Outcome

Client patched critical findings within 24 hours of the report. Partner procurement accepted the remediation evidence pack. Enterprise contract closed within 60 days.

Telehealth platform (behavioral health)

Case study CS-002

Client profile

Series A telehealth platform focused on outpatient behavioral health. Built on Next.js + Supabase + Twilio Video. ~40,000 monthly active patients across 19 states.

Engagement scope

Annual HIPAA Pentest. External + authenticated testing across five roles: patient, clinician, clinic admin, billing, and super-admin.

Findings summary

CRITICALHS-002-01

Telehealth session recordings in unindexed S3 bucket retrievable by URL guessing

§ 164.312(a)(1)§ 164.312(e)(1)§ 164.404

HIGHHS-002-02

Patient portal IDOR — encounter notes for any patient readable by altering patient_id parameter

§ 164.308(a)(4)§ 164.312(a)(1)

HIGHHS-002-03

Supabase Row-Level-Security policy bypass via service-role key in client bundle

§ 164.312(a)(1)§ 164.312(c)(1)

MEDIUMHS-002-04

Clinician role could modify billing codes for completed encounters with no audit trail

§ 164.312(b)§ 164.312(c)(1)

What we found

Three independent PHI exposure paths. The most serious was an S3 bucket where telehealth session recordings were stored with predictable UUIDs accessible to any logged-in user who could guess the URL pattern. The patient portal had a classic IDOR on the encounter endpoint. The Supabase service-role key was embedded in the client-side JavaScript bundle, giving any user full database access.

Breach Notification Rule exposure

Approximately 40,000 active patients across 19 states. Breach Notification Rule impact would have required individual notification in every state, plus HHS notification given the >500 individual threshold. Multi-state breach notification would have triggered coverage in at least seven state AGs with active healthcare privacy enforcement (CA, TX, NY, MA, IL, WA, OR).

Remediation

S3 bucket ACL rewritten with per-user presigned URLs (72-hour TTL)
Patient portal endpoint patched to verify ownership via authenticated user ID
Service-role key rotated and moved server-side behind RLS-aware API
Billing code mutation endpoint now requires auditor role, audit log immutable via S3 object-lock
Full Supabase RLS policy audit conducted against all 47 tables

Outcome

All critical findings remediated in 6 business days. Attestation letter delivered to the health plan BAA counterparty. SOC 2 Type II auditor accepted the report as evidence for CC7.1 through CC7.5 controls.

Digital therapeutic (FDA-cleared Class II)

Case study CS-003

Client profile

FDA-cleared digital therapeutic for a chronic condition. Class II medical device software (SaMD). Patient-facing mobile app plus clinician dashboard. Regulated under 21 CFR Part 820 in addition to HIPAA.

Engagement scope

BAA-Ready Assessment. Full pentest + policy evidence review + sub-processor BAA mapping, triggered by a pending contract with a national payer.

Findings summary

HIGHHS-003-01

FHIR R4 /Patient endpoint accepted SMART on FHIR tokens with excessive scope

§ 164.312(a)(1)§ 164.312(e)(1)

HIGHHS-003-02

Analytics pixel (Segment + Mixpanel) transmitted patient behavioral events without executed BAA

§ 164.308(b)(1)§ 164.314(a)

MEDIUMHS-003-03

LLM-based clinical note assistant sent ePHI to OpenAI without BAA coverage

§ 164.308(b)(1)§ 164.502(b)

MEDIUMHS-003-04

Device lockout policy inconsistent between iOS and Android builds

§ 164.312(a)(2)(iii)

What we found

The most notable findings were on the periphery, not the core. The FHIR API was correctly scoped at the authorization server, but the resource server accepted tokens with scopes it should have rejected. More importantly, the BAA map revealed three sub-processors receiving ePHI without executed BAAs — the classic enforcement pattern OCR targets. The LLM integration was added by the engineering team ahead of a product demo and never reviewed by compliance.

Breach Notification Rule exposure

The un-BAA'd sub-processor findings were the highest regulatory risk. OCR's enforcement record shows BAA failures are the single most common cause of settlement agreements. Financial exposure would have been in the $1M-$5M range based on comparable OCR resolutions.

Remediation

FHIR resource server scope enforcement patched per SMART on FHIR v2 spec
Analytics pipeline restructured to exclude PHI and tag only de-identified metrics
LLM integration moved to an enterprise-tier vendor with executed BAA
Device lockout policy unified and enforced via MDM
Sub-processor inventory added to quarterly compliance review cadence

Outcome

BAA-ready attestation letter delivered to the payer. Contract closed at $4.2M annual contract value. HITRUST readiness add-on completed the following quarter, leading to HITRUST e1 certification.

What would we find in yours?

Schedule a scoping call. Most of the findings above were surfaced in the first 72 hours of testing.

Schedule a scoping call