Administrative safeguards are where HIPAA enforcement actually lands. Published settlements turn overwhelmingly on a missing risk analysis, an unsigned Business Associate Agreement or absent workforce training — not on cryptographic weaknesses. They are also the category an automated assessment can say least about: 6 of 12 controls here are documentation and process obligations with no technical footprint.
Those 6 controls are marked Manual-Review and excluded from the section score rather than guessed at. That is a deliberate choice: scoring them as compliant would inflate the headline number, and scoring them as failing would be equally unfounded. They are the main reason the overall figure is presented as a range of 38–64% instead of a single value.
| # | Citation | Requirement | Status | Evidence (masked) |
|---|---|---|---|---|
| A1 | §164.308(a)(1)(ii)(A) | Risk Analysis (Required) | 🔍 Manual-Review | No documented, organization-wide risk analysis was found in the repository. This assessment is a technical gap-check and does not satisfy §164.308(a)(1)(ii)(A), which requires an accurate and thorough assessment of risks to all ePHI the organization holds. |
| A2 | §164.308(a)(1)(ii)(B) | Risk Management (Required) | 🔍 Manual-Review | Requires evidence that identified risks are tracked to closure under a documented programme. Not determinable from code or logs. |
| A3 | §164.308(a)(1)(ii)(C) | Sanction Policy (Required) | 🔍 Manual-Review | Workforce sanction policy for security-policy violations. Documentation control. |
| A4 | §164.308(a)(1)(ii)(D) | Information System Activity Review (Required) | ⚠️ Partial | Substantial telemetry exists: CloudTrail (management + S3 data events), GuardDuty enabled in both regions with 0 open findings, VPC flow logs in us-e****-2, structured request logging, and an error-alert pipeline that dispatches to Slack. But there is no closed loop: CloudTrail has no CloudWatch Logs integration (CloudWatchLogsLogGroupArn is null), therefore 0 metric-filter alarms on security events; AWS Config and Security Hub are not enabled in either region; and no evidence of a documented periodic review was found. |
| A5 | §164.308(a)(2) | Assigned Security Responsibility (Required) | 🔍 Manual-Review | A named Security Official must be designated and documented. Not determinable technically. |
| A6 | §164.308(a)(3) | Workforce Security | ⚠️ Partial | In place: individual (non-shared) IAM identities and a strong account password policy. Gaps: MFA missing on 4 of 5 console-capable users (T13); access keys never rotated — the oldest active key dates to 2020 and another to 2021, and one user holds 2 active keys concurrently. No automated joiner/mover/leaver evidence. |
| A7 | §164.308(a)(4) | Information Access Management | ⚠️ Partial | Technically supported by the rbac_* schema, per-practice tenant isolation and IAM database authentication on the Aurora cluster. Undermined by the inconsistent feature-permission enforcement described in T3, which weakens the “minimum necessary” standard in practice. |
| A8 | §164.308(a)(5) | Security Awareness and Training | 🔍 Manual-Review | Periodic workforce security training and reminders. Documentation control; no technical evidence available. |
| A9 | §164.308(a)(5)(ii)(D) | Password Management | ⚠️ Partial | The AWS account password policy is strong and exceeds common baselines: minimum length 12, upper + lower + digit + symbol all required, 90-day expiry, and reuse prevention over the last 5 passwords. The application-side Cognito policy is weaker — minimum length 8 with requireLowercase and requireUppercase both false (infra/cdk/lib/revique-api-stack.ts:2241). Cognito MFA is configured OPTIONAL (TOTP only, SMS disabled — correct choice), not required. |
| A10 | §164.308(a)(6) | Security Incident Procedures | ⚠️ Partial | Detection and routing exist: GuardDuty in both regions, a sanitized error-occurrence pipeline with a dedicated alert dispatcher and Slack delivery (src/observability/error-alert-processor.ts, slack-summary.ts). Missing: a documented incident response and breach-assessment procedure, and the security-event alarms noted in A4. Breach notification readiness (§§164.400–414) is further limited by T8 — without a PHI-access trail, determining whose records were touched during an incident may not be possible. |
| A11 | §164.308(a)(7) | Contingency Plan | ⚠️ Partial | Backup and availability substrate is real (P2, P7): Multi-AZ Aurora, 14-day backups, deletion protection, an AWS Backup plan in one region. Missing: a documented and tested disaster-recovery / emergency-mode-operation plan, defined RTO/RPO, and any evidence of restore testing. The 1-day backup retention on the legacy MySQL tier is materially below a defensible RPO for PHI. |
| A12 | §164.308(b)(1) | Business Associate Agreements (Required) | 🔍 Manual-Review | Third parties that touch or may touch PHI have been enumerated from code and configuration (see the Business Associate register on the main page). Whether a signed BAA exists for each is a contractual fact that cannot be read from code or AWS APIs — it must be confirmed against the contract file. Note that the AWS BAA is the precondition for the Physical Safeguards position in P1. |
Every control below is Manual-Review — unknown from code and logs. Producing this evidence is what moves the overall estimate from its 38% lower bound toward its 64% upper bound, and it is cheaper than most of the technical work in this report.
| # | Citation | Requirement | What has to exist |
|---|---|---|---|
| A1 | §164.308(a)(1)(ii)(A) | Risk Analysis (Required) | No documented, organization-wide risk analysis was found in the repository. This assessment is a technical gap-check and does not satisfy §164.308(a)(1)(ii)(A), which requires an accurate and thorough assessment of risks to all ePHI the organization holds. |
| A2 | §164.308(a)(1)(ii)(B) | Risk Management (Required) | Requires evidence that identified risks are tracked to closure under a documented programme. Not determinable from code or logs. |
| A3 | §164.308(a)(1)(ii)(C) | Sanction Policy (Required) | Workforce sanction policy for security-policy violations. Documentation control. |
| A5 | §164.308(a)(2) | Assigned Security Responsibility (Required) | A named Security Official must be designated and documented. Not determinable technically. |
| A8 | §164.308(a)(5) | Security Awareness and Training | Periodic workforce security training and reminders. Documentation control; no technical evidence available. |
| A12 | §164.308(b)(1) | Business Associate Agreements (Required) | Third parties that touch or may touch PHI have been enumerated from code and configuration (see the Business Associate register on the main page). Whether a signed BAA exists for each is a contractual fact that cannot be read from code or AWS APIs — it must be confirmed against the contract file. Note that the AWS BAA is the precondition for the Physical Safeguards position in P1. |
| Capability | State | Detail |
|---|---|---|
| CloudTrail management + data events | ✅ Enabled | Multi-region, log-file validation on, KMS-encrypted, actively delivering |
| GuardDuty threat detection | ✅ Enabled | Both regions, detectors active, 0 open findings |
| VPC flow logs | ⚠️ Partial | Active for the us-e****-2 platform VPC (ALL traffic → S3); absent in us-e****-1, the VPC that processes native PHI |
| CloudTrail → CloudWatch Logs | ❌ Not configured | CloudWatchLogsLogGroupArn is null — therefore 0 metric-filter alarms on security events can fire |
| AWS Config | ❌ Not enabled | No configuration recorder in either region — no continuous compliance evaluation, no resource change history |
| Security Hub | ❌ Not enabled | No aggregated findings or standards benchmarking in either region |
| Error alerting pipeline | ✅ Present | Sanitized error occurrences → dedicated enqueuer and alert-dispatcher Lambdas → Slack |
| WAF on the native ALB | ❌ Absent | Legacy WAF automations exist in us-e****-2; the native API load balancer has no regional web ACL |
The pattern here is consistent: collection is good, reaction is missing. There is ample telemetry and no automated response path from a security event to a human. Wiring CloudTrail into CloudWatch Logs and adding metric-filter alarms is the single change that converts this section's raw material into a control.
| Measure | Observed | Assessment |
|---|---|---|
| IAM users in the production account | 9 (7 human-shaped, 2 SES service identities) | ✅ Individual accounts — no shared login observed |
| Console-capable identities | 5 | — |
| Of those, with MFA registered | 1 of 5 | ❌ Critical gap — 4 identities reach production PHI with a password alone |
| Account password policy | min 12 chars · upper + lower + digit + symbol · 90-day expiry · reuse prevention 5 | ✅ Strong — exceeds common baselines |
| Cognito password policy | min 8 chars · digits and symbols required · upper/lower not required | ⚠️ Weaker than the IAM policy |
| Cognito MFA | OPTIONAL, TOTP only (SMS disabled) |
⚠️ Not enforced — disabling SMS is the correct choice; requiring MFA is the missing half |
| Access key age | Oldest active key dates to 2020; another to 2021; one user holds 2 active keys | ❌ No rotation |
| Secrets Manager rotation | 0 of 6 secrets have rotation enabled | ❌ Gap — credentials are correctly stored but never rotated |
| KMS key rotation | Customer key alias/auditlog-hipaa: rotation disabled |
⚠️ Enable annual rotation |
Secret handling is done correctly — credentials come from Secrets Manager at runtime, no hardcoded credentials, AWS
access keys or private keys were found anywhere in the codebase, and .env files are properly excluded from version control.
The weakness is lifecycle: nothing rotates.
Eleven third parties that touch or may touch PHI have been identified from code and production configuration. The full register, with the function each performs and what needs verifying, is on the overview page. Two points deserve emphasis here:
None of this is determinable from code. It is a contract-file question, and it is the most common cause of HIPAA enforcement findings in practice.
****).