Patient data systems
ePHI in EHR systems, patient portals, and clinical apps. Cross-patient data access — where one patient's portal account can access another's records — is the healthcare equivalent of a SaaS tenant isolation failure.
pentest · healthcare
Penetration testing for healthcare and healthtech.
ePHI systems under HIPAA Security Rule §164.308(a)(8). Patient portals, EHR integrations, telehealth platforms, and FHIR APIs — each an attractive target. We sign a Business Associate Agreement before testing, scope to your ePHI environment, and deliver findings formatted for OCR audit readiness.
01. attack surface
What attackers target in healthcare.
Healthcare organizations face disproportionate breach rates. PHI sells for more than credit card data on criminal markets, and systems are often legacy.
FHIR and HL7 APIs
Insecure SMART on FHIR OAuth2 scope implementation, insufficiently isolated patient compartments in FHIR R4 endpoints, bulk data API access control gaps, and HL7 2.x injection through message parsing.
Telehealth platforms
Video session isolation failures, recording storage access controls, prescription and visit note exposure through web app vulnerabilities, and insecure file upload handling in patient intake flows.
Provider portal authentication
Weak session management, insecure password reset flows, MFA not enforced for clinical staff, and account enumeration through login error messages. Provider accounts carry full PHI access.
Third-party integrations
Billing systems, pharmacy networks, lab result delivery, and HIE connections. Each integration is an additional access path to ePHI, often with weaker security controls than the core system.
Mobile apps
Patient-facing iOS and Android apps. Insecure local storage of PHI, missing certificate pinning, offline data caching risks, and biometric authentication bypass.
02. hipaa requirements
HIPAA Security Rule requirements that apply.
The Security Rule touches penetration testing through multiple standards. OCR enforces these during investigation and audit.
- §164.308(a)(8) — EvaluationCovered entities and Business Associates must perform a periodic technical and nontechnical evaluation in response to environmental or operational changes. A penetration test is the accepted technical evaluation method. OCR expects documented results and evidence of remediation.
- §164.308(a)(1) — Risk analysisRequires identification and documentation of risks to ePHI confidentiality, integrity, and availability. Penetration test findings are direct input to the risk analysis. OCR investigators look for evidence that identified risks were tracked to remediation.
- §164.312(a)(1) — Access controlTechnical safeguards for electronic PHI access. Testing covers whether role-based access controls function under adversarial conditions: minimum necessary enforcement, audit log completeness, and privilege escalation paths.
- Business Associate AgreementA vendor accessing ePHI-adjacent systems must sign a BAA before engagement. We execute a BAA before any testing begins. Some vendors skip this step. We don't — and neither should you require less from anyone testing your systems. HIPAA pentest details →
03. scope
What we test in a healthcare pentest.
Scope is defined by your ePHI environment and agreed in writing before testing starts.
Patient portal and EHR access layer
Authentication, session management, and authorization across all patient-facing and clinical-staff-facing access paths. Cross-patient record access is the primary test objective.
FHIR and HL7 APIs
SMART on FHIR OAuth2 scope implementation, FHIR resource authorization, patient compartment isolation, bulk data API access controls, and HL7 2.x message parsing security.
Telehealth and messaging
Video session isolation, recording storage access controls, prescription and visit note exposure, and secure messaging implementation.
Billing and RCM integrations
Revenue cycle management integrations that sit alongside PHI. PCI DSS implications if payment card data is present in the same systems.
Mobile apps
Patient-facing iOS and Android apps. PHI stored locally, certificate pinning, offline cache handling, and biometric authentication bypass. OWASP MASVS aligned.
Cloud infrastructure
Storage of ePHI in S3, GCS, or Azure Blob. IAM access to ePHI datastores, logging configuration, encryption at rest and in transit. Optional add-on to the application test.
04. deliverables
What you walk away with.
Structured for OCR audit readiness and your internal HIPAA compliance record.
BAA before testing starts
Not a deliverable — a precondition. A Business Associate Agreement is executed before any testing begins. Required by HIPAA before a vendor can access ePHI-adjacent systems.
HIPAA-aligned findings report
Each finding mapped to the Security Rule standard it implicates. Risk level stated in terms of likelihood and impact to ePHI confidentiality, integrity, and availability — the three-part HIPAA risk framework.
Risk analysis input
Structured findings output ready to feed your HIPAA risk analysis and risk management plan. Findings are formatted so your compliance team can reference them directly in §164.308(a)(1) documentation.
Retest within 30 days
Post-fix re-validation from the same engineer. Each finding marked resolved, partially resolved, or accepted with documented rationale. Required for the OCR audit trail.
Attestation letter
Signed by the named engineer. States methodology, ePHI scope reference, dates, and retest outcome. For your internal HIPAA compliance record and any OCR investigation response.
Working PoCs
Every finding with reproducible exploit or step-by-step walkthrough. Your engineering team verifies before triage. No vague "sensitive data exposure" findings without proof.
05. faq
Questions before the call.
Do you sign a BAA before testing?
Yes, always. A Business Associate Agreement is executed before any testing begins. This is a non-negotiable HIPAA requirement. Some testing vendors skip it. We don't.
What's the difference between a HIPAA risk analysis and a penetration test?
A risk analysis (§164.308(a)(1)) assesses all risks to ePHI across administrative, physical, and technical safeguards. A penetration test is the technical validation: does the control actually work against an active adversary? Pentest findings feed the risk analysis. They're complementary, not interchangeable.
Can you test our FHIR API?
Yes. We test SMART on FHIR OAuth2 scope implementation, FHIR resource authorization, patient compartment isolation, bulk data API access controls, and HL7 FHIR R4 endpoint security.
We're a health SaaS — do we need HIPAA or SOC 2 pentest coverage?
Both, typically. HIPAA requires technical safeguard evaluation (satisfies §164.308(a)(8)). Enterprise health system customers also require SOC 2. One well-scoped engagement produces a report that satisfies both evidence requirements.
What happens if you find PHI exposed during testing?
We document it as a finding and notify you immediately. We do not exfiltrate, store, or analyze PHI beyond what is necessary to demonstrate the vulnerability. All access is documented in the engagement log for your BAA audit trail.
Ready to scope a healthcare pentest?
30-minute scoping call covers your ePHI environment, your compliance deadlines, and the BAA. Free.