HIPAA Compliance Audit

No. We use a read-only IAM Role (AWS), App Registration (Azure), or Service Account (GCP) scoped strictly to compliance-relevant configuration APIs - IAM, KMS, CloudTrail, Config, Security Hub, Macie findings, Azure Defender, GCP Security Command Center, and similar. The role explicitly cannot read S3 / Blob / GCS object contents, database rows, FHIR resources, or any payload that may contain ePHI. We work entirely from configuration metadata.

Yes. Every finding is mapped to the relevant control in the HHS OCR Audit Protocol and to HITRUST CSF (e1 and r2 where in scope), plus NIST 800-66 (the HIPAA Security Rule implementation guide) and SOC 2 CC controls. The report is designed so your compliance team or auditor can drop it directly into an evidence pack.

We strongly recommend it. A signed BAA with AWS, Azure, or GCP is required before any ePHI is processed in the cloud at all - and the audit is most useful once you have one in place because the report includes a BAA coverage matrix showing which controls the cloud provider takes responsibility for under their BAA versus which you must implement yourself. If you do not yet have a BAA, we can still run the audit and the report will explicitly flag the BAA gap.

AWS, Azure, and Google Cloud - including HIPAA-specific services such as Amazon HealthLake and HealthLake Imaging, Azure Health Data Services and DICOM Service, and the Google Cloud Healthcare API. The audit covers compute, storage, databases, networking, identity, logging, and backup posture across all three providers.

Those tools produce raw findings. This audit interprets them. A senior compliance engineer triages every finding for actual ePHI exposure and OCR audit risk, removes false positives, combines results across Audit Manager, Config, Security Hub, GuardDuty, Macie, Azure Policy, Defender for Cloud, Microsoft Purview, GCP Security Command Center, and DLP with manual review of architecture, BAA coverage, and breach-notification readiness - into a prioritised remediation plan rather than a 4,000-line raw finding list.

Yes. The technical audit focuses on the Security Rule, but the report also reviews configuration evidence relevant to the Privacy Rule (audit logs to support accounting of disclosures, access minimisation, retention) and the Breach Notification Rule (encryption safe harbour status per ePHI store, log immutability, SIEM detection coverage, and incident-response readiness). Policy and workforce-training elements remain your responsibility but the report tells you exactly what additional evidence is required.

No. The audit is fully read-only and runs against configuration APIs at a controlled rate. Nothing we do can modify resources, change IAM, restart workloads, or affect ePHI availability. You can run the audit during normal business hours with zero risk to delivery.

Typical turnaround is 1-2 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your compliance and engineering leads. Larger multi-account or multi-cloud estates can take a little longer; we confirm the timeline as soon as we see the scope.