Physical safeguards are largely discharged by AWS under the Shared Responsibility Model. AWS is responsible for the security of the cloud — data-centre access, environmental controls, hardware lifecycle and media destruction. The covered entity remains responsible for security in the cloud, and for the workstation and device controls that sit outside AWS entirely.
This delegation is only valid with a signed AWS Business Associate Addendum. Without it, AWS is not a business associate, the shared-responsibility argument does not apply, and every control on this page reverts to the covered entity. Confirming that addendum is the highest-value action for this section — see control A12.
| # | Citation | Requirement | Status | Evidence (masked) |
|---|---|---|---|---|
| P1 | §164.310(a)(1) | Facility Access Controls | ☁️ AWS-Managed | All compute and storage in scope run in AWS regions us-e****-1 and us-e****-2. Physical and environmental controls are AWS’s responsibility under the Shared Responsibility Model and are evidenced by AWS SOC 2 / ISO 27001 reports via AWS Artifact. Conditional: this only discharges the obligation if a signed AWS Business Associate Addendum is on file — see A12. |
| P2 | §164.310(a)(2)(i) | Contingency Operations | ⚠️ Partial | Native Aurora cluster: Multi-AZ, 14-day automated backup retention, deletion protection on, plus a reader instance. An AWS Backup vault (HP-BACKUP-VAULT, KMS-encrypted, 3 recovery points) and HP-PRIMARY-BACKUP-PLAN exist in us-e****-2 only. Gaps: no AWS Backup vault or plan in us-e****-1 where the native PHI database lives, and the legacy MySQL instances retain only 1 day of backups. |
| P3 | §164.310(b) | Workstation Use | 🔍 Manual-Review | Policy control governing acceptable workstation use for systems that access ePHI. Not determinable from code or AWS configuration. |
| P4 | §164.310(c) | Workstation Security | 🔍 Manual-Review | Not determinable from code or AWS configuration. Relevant observation for the reviewer: the legacy database security group admits MySQL/3306 from four static public /32 addresses (values withheld from this report), i.e. named workstations reach the production PHI database directly across the internet. Physical and endpoint security of those four machines becomes an in-scope control. |
| P5 | §164.310(d)(1) | Device and Media Controls — disposal | ❌ Gap | No data-retention or disposal mechanism was found. Record removal is soft-delete only (deleted_at columns); no purge job, retention window, or documented media-sanitization procedure exists in the codebase. S3 lifecycle expiration is not configured on the PHI buckets. |
| P6 | §164.310(d)(2)(ii) | Media Re-use / sanitization | ⚠️ Partial | EBS default encryption is enabled account-wide in both regions and 100% of volumes are encrypted, so block-storage re-use is covered by cryptographic erasure. The unencrypted legacy MySQL secondary (T6) is the exception: its underlying media cannot be cryptographically sanitized. |
| P7 | §164.310(d)(2)(iv) | Data Backup and Storage | ✅ Compliant | Aurora automated backups (14 days) with Multi-AZ and a KMS-encrypted AWS Backup vault holding recovery points; S3 versioning enabled on the native patient-files bucket; snapshot tagging enabled. Backups inherit KMS encryption from their source. |
| Concern | Owner | Position |
|---|---|---|
| Data-centre physical access, CCTV, guards, biometrics | AWS | ☁️ AWS-Managed — evidenced via AWS Artifact (SOC 2 Type II, ISO 27001) |
| Environmental controls, power, fire suppression | AWS | ☁️ AWS-Managed |
| Hardware decommissioning and media destruction | AWS | ☁️ AWS-Managed — NIST 800-88 media sanitization |
| Cryptographic erasure of stored data | Covered entity | ⚠️ Partial — effective for all EBS and the native database; not possible for the unencrypted legacy instance |
| Retention windows and record disposal | Covered entity | ❌ Gap — soft-delete only; no purge path, no S3 lifecycle expiry |
| Backup, restore and recovery capability | Covered entity | ✅ Compliant for the native tier; weak on the legacy tier (1-day retention) |
| Workstation configuration, disk encryption, screen lock | Covered entity | 🔍 Manual-Review — outside AWS; requires endpoint-management evidence |
| Asset | Mechanism | Retention | Assessment |
|---|---|---|---|
| Aurora cluster (native PHI) | RDS automated backups, Multi-AZ, reader instance, deletion protection | 14 days | ✅ Adequate |
| Legacy MySQL × 2 | RDS automated backups | 1 day | ❌ Below a defensible RPO |
AWS Backup vault HP-BACKUP-VAULT | KMS-encrypted vault, HP-PRIMARY-BACKUP-PLAN, 3 recovery points | Per plan | ⚠️ us-e****-2 only — no vault or plan in the region holding the native PHI database |
| Native patient-files bucket | S3 versioning + SSE | Indefinite | ✅ Adequate |
| Legacy patient-documents bucket | SSE only | — | ❌ No versioning — overwrite or delete is unrecoverable |
| DR plan, RTO/RPO, restore testing | — | — | 🔍 Manual-Review — no documented or tested plan found |
Backups exist and are encrypted; what is missing is the plan around them. §164.308(a)(7) asks for a documented, tested contingency plan with defined recovery objectives — having snapshots is necessary but not sufficient.
One finding sits awkwardly between physical and technical safeguards and is worth calling out here. The legacy database security group permits MySQL on port 3306 from four static public /32 addresses (values deliberately withheld from this report). Those are almost certainly developer or office machines. The consequence is that four specific workstations, outside AWS, have direct network reach to a production database holding PHI — which pulls their disk encryption, screen-lock policy, patch level and physical security into HIPAA scope under §164.310(c). Moving that access behind a VPN or SSM Session Manager removes those endpoints from scope entirely and is the cleaner fix.
****).