Audit Report

Evidence: Examined the risk register and remediation tracking; open cloud findings (public RDS, unencrypted PHI exposure) had no consistent severity scoring, owner, or SLA, and were not fed into a standardized prioritization method.

Why it fails: There is no consistently applied risk-scoring methodology tying discovered technical exposures to prioritized remediation, so critical PHI risks sit un-triaged.

Remediation: Adopt a standardized scoring model (e.g., CVSS + PHI-impact weighting), assign owners and SLAs to each finding, and integrate connector findings into the risk register automatically.

Evidence: The S3 bucket nbrh-clinical-exports holding PHI exports and the EHR RDS instance were not tagged with data-classification or criticality tags, and were treated with the same controls as non-sensitive resources.

Why it fails: PHI-bearing assets are not consistently classified or prioritized, which directly enabled the public-exposure findings on the clinical export bucket and EHR database.

Remediation: Apply mandatory data-classification and criticality tags to all resources, enforce tagging via SCP/Config rules, and drive tighter controls (encryption, access) from the classification.

Evidence: Okta user report showed multiple accounts belonging to terminated staff still in ACTIVE state with valid sessions, indicating the leaver process does not enforce timely deprovisioning.

Why it fails: Roles and access authorities are not enforced through offboarding — dormant accounts for terminated employees remain active, expanding the attack surface into PHI systems.

Remediation: Integrate Okta with the HR system for automated deprovisioning on termination, run a monthly dormant-account review, and disable accounts with no login in 30+ days.

Evidence: Although vulnerabilities are recorded, critical exposures (any-authenticated-principal read on the PHI export bucket, root without MFA) had not been escalated or prioritized based on likelihood/impact at the time of assessment.

Why it fails: Recorded vulnerabilities are not consistently translated into prioritized risk response, leaving critical PHI-affecting issues unremediated.

Remediation: Feed scan findings into the standardized risk-scoring model, auto-escalate critical PHI-impacting items, and enforce remediation SLAs by severity.

Evidence: IAM credential report showed multiple active access keys older than 400 days with no rotation, including keys attached to privileged users.

Why it fails: Credential lifecycle management is not enforced — long-lived access keys are a standing credential-theft risk against PHI infrastructure.

Remediation: Enforce 90-day key rotation via IAM policy/Config, deactivate keys unused for 90+ days, and migrate workloads to short-lived roles (IAM Roles Anywhere / STS).

Evidence: AWS root account and several IAM admin users had no MFA device registered; Google Workspace tenant did not enforce 2-Step Verification for all users; Okta password policy allowed short/rotating passwords below NIST SP 800-63B guidance.

Why it fails: Strong authentication is not universally enforced — root/admin access to PHI systems and workforce identities can be reached with single-factor credentials.

Remediation: Enforce hardware/virtual MFA on root and all IAM admins, mandate Google 2SV org-wide, and align the Okta password policy with SP 800-63B (length over rotation, breached-password checks).

Evidence: IAM policy review found policies granting wildcard actions (e.g., s3:*, iam:*) on '*' resources attached to service and human principals, and Okta admin roles assigned without any step-up MFA requirement.

Why it fails: Least privilege and separation of duties are not enforced — wildcard IAM grants and un-gated admin roles allow broad, unchallenged access to sensitive systems.

Remediation: Replace wildcard policies with scoped least-privilege permissions, run IAM Access Analyzer, and require step-up MFA for all Okta admin role activation.

Evidence: Okta admin (Super Administrator / App Admin) roles were granted without a step-up / re-authentication MFA policy on privileged actions.

Why it fails: Privileged logical access is not commensurately protected — high-impact admin operations execute without step-up authentication, so a compromised admin session yields unchecked control.

Remediation: Create an Okta authentication policy requiring phishing-resistant step-up MFA (FIDO2) for admin console and privileged app access; enforce short admin session lifetimes.

Evidence: S3 bucket nbrh-clinical-exports bucket policy granted read to Principal 'arn:aws:iam::*:root' (any authenticated AWS principal); separately, several Google Drive files containing patient identifiers were shared with 'Anyone with the link'.

Why it fails: PHI data-at-rest is exposed beyond authorized users across two stores, a direct confidentiality failure and likely HIPAA breach condition.

Remediation: Remove the wildcard principal, enable S3 Block Public Access and account-level SCP deny, enforce SSE-KMS with a dedicated key; run a Google Workspace DLP scan and revoke link-sharing on files containing PHI.

Evidence: The RDS instance hosting EHR data was configured with PubliclyAccessible=true and reachable from the internet, exposing the database endpoint outside the VPC boundary.

Why it fails: EHR data crosses untrusted network paths because the database is internet-exposed rather than confined to private subnets, undermining in-transit protection and the network trust boundary.

Remediation: Set PubliclyAccessible=false, move RDS to private subnets, restrict security-group ingress to app-tier CIDRs, and require TLS (rds.force_ssl) for all connections.

Evidence: A plaintext API secret was found committed to an internal GitHub repository history, meaning a live credential is exposed to everyone with repo access and persists in git history.

Why it fails: Secrets embedded in source code are a data-in-use exposure — the credential can be extracted and replayed against connected systems, some of which touch PHI.

Remediation: Rotate the exposed secret immediately, purge it from git history (BFG/filter-repo), enable GitHub secret scanning and push protection, and move secrets to AWS Secrets Manager.

Evidence: AWS security groups were found allowing 0.0.0.0/0 ingress on ports 22 (SSH) and 3389 (RDP); S3 backup buckets lacked versioning and MFA-delete; no baseline config guardrails prevented these drifts.

Why it fails: Secure configuration baselines are not enforced, allowing internet-exposed management ports and unprotected backups that weaken both perimeter and recoverability.

Remediation: Deploy AWS Config conformance packs / SCPs to deny 0.0.0.0/0 on 22/3389, require bastion/SSM Session Manager, and enable versioning + MFA-delete on all backup buckets.

Evidence: The GitHub organization lacked branch protection and required pull-request reviews on primary repositories, allowing direct pushes to main without peer review or status checks.

Why it fails: Without enforced review and branch protection, insecure or malicious code (including committed secrets) can reach production unreviewed, weakening the SDLC.

Remediation: Enable branch protection on default branches org-wide: required reviews (2+), status checks, signed commits, and secret-scanning push protection.

Evidence: CloudTrail was disabled in two active AWS regions where workloads are running, creating blind spots with no API-activity capture for those regions.

Why it fails: Detection coverage is incomplete — activity in two live regions is unmonitored, so malicious API actions against PHI resources there would go undetected and un-investigable.

Remediation: Enable an organization-wide multi-region CloudTrail with log-file validation to a locked, KMS-encrypted S3 bucket, and alert on trail configuration changes.

Evidence: No documented, tested incident response runbook was produced for cloud/PHI incidents; there was no evidence of a tabletop exercise or defined coordination with AWS/cyber-insurer/OCR notification workflow.

Why it fails: Incident response cannot be executed reliably without a documented, tested runbook — a critical gap given HIPAA's 60-day breach-notification obligations.

Remediation: Author cloud/PHI IR runbooks with roles, escalation, and OCR/state breach-notification steps; run at least annual tabletop exercises and capture lessons learned.

Evidence: S3 backup buckets used for recovery lacked versioning and MFA-delete, meaning backups could be overwritten or deleted (including by an attacker or ransomware) without protection or point-in-time recovery.

Why it fails: Recovery reliability is undermined — unversioned, non-MFA-delete backups cannot guarantee restoration of PHI systems after tampering or ransomware.

Remediation: Enable S3 versioning and MFA-delete on all backup buckets, apply Object Lock (compliance mode) for immutability, and periodically test restores.

Evidence: Assessed AWS CloudTrail organizational trail coverage; management/data events were not delivered in us-west-2 and us-east-2 despite active EHR and analytics workloads running there.

Why it fails: Control activity depends on complete, quality audit information, but logging gaps in two active regions mean security-relevant information is not being generated for those environments.

Remediation: Enable an organization-wide multi-region CloudTrail (management + data events) delivering to a centralized, restricted S3 bucket with log-file validation, and add a config rule to alert on trail disablement.

Evidence: Reviewed continuous-monitoring tooling coverage; AWS Config and posture scanning were not deployed in all regions, and IAM access-key age was not being evaluated — keys older than 400 days remained active.

Why it fails: Ongoing evaluation of control operation is incomplete; stale credentials and unmonitored regions persisted because no automated evaluation caught them.

Remediation: Deploy AWS Config with credential-age and CIS conformance packs across all regions, enforce a 90-day access-key rotation via SCP/automation, and disable keys exceeding the threshold.

Evidence: Reviewed IAM policy documents attached to service and human roles; multiple policies granted wildcard actions (e.g., "Action": "*") and "Resource": "*" beyond least-privilege need.

Why it fails: General technology control activities do not enforce least privilege, weakening the design of access-based control activities.

Remediation: Refactor wildcard IAM policies to scoped actions/resources, run IAM Access Analyzer to right-size permissions, and adopt permission boundaries for delegated roles.

Evidence: Assessed the S3 bucket policy/ACL for the PHI export bucket; it granted read access to the AuthenticatedUsers group (any authenticated AWS principal, not just the org), exposing clinical export objects.

Why it fails: Logical access architecture fails to restrict PHI to authorized principals, directly contradicting the criterion and creating a HIPAA breach exposure.

Remediation: Remove the AuthenticatedUsers grant, enable S3 Block Public Access at account and bucket level, apply a restrictive bucket policy scoped to specific roles, enforce SSE-KMS, and review CloudTrail/S3 access logs for prior exposure.

Evidence: Cross-referenced the Okta user directory against HR termination records; multiple accounts for terminated clinical and admin staff remained in Active status with valid sessions/entitlements.

Why it fails: Deprovisioning is not reliably executed, leaving dormant accounts that violate the timely access-removal requirement.

Remediation: Integrate HR (Workday/BambooHR) with Okta lifecycle management for automated offboarding, run a full access recertification, and disable the identified dormant accounts immediately.

Evidence: Reviewed Okta admin role assignments and their governing sign-on policy; Super Admin / App Admin grants were not gated by a step-up (assurance) MFA policy for privileged actions.

Why it fails: Privileged access is granted without commensurate step-up authentication, weakening least-privilege enforcement for the highest-impact roles.

Remediation: Create an Okta authentication policy requiring phishing-resistant step-up MFA (FIDO2/WebAuthn) for all admin roles and privileged app access, and reduce standing admin membership via just-in-time elevation.

Evidence: Analyzed VPC security group rules; groups permitted 0.0.0.0/0 ingress on ports 22 (SSH) and 3389 (RDP), and an RDS instance hosting EHR data was configured as publicly accessible with a public endpoint.

Why it fails: The system boundary is not protected from external threats: internet-facing management ports and a publicly reachable EHR database expose the environment to direct attack.

Remediation: Set the EHR RDS instance PubliclyAccessible=false and place it in private subnets; restrict SSH/RDP to bastion/VPN CIDRs or replace with SSM Session Manager; add security-group drift detection.

Evidence: Reviewed Google Drive external-sharing report; multiple files containing patient information were shared via 'Anyone with the link' link-sharing, exposing PHI outside the tenant.

Why it fails: Information movement is not restricted to authorized users; publicly linked PHI files fail the transmission/removal protection requirement and constitute a HIPAA disclosure risk.

Remediation: Disable link-sharing to 'Anyone' at the OU/domain level, enable Google Workspace DLP to detect and quarantine PHI, revoke the exposed links, and audit access history on affected files.

Evidence: Reviewed GitHub org settings; branch protection and required pull-request reviews were not enabled on default branches, allowing unreviewed code (and its dependencies) to reach deployment pipelines.

Why it fails: Without required reviews and branch protection, unauthorized or malicious code changes can be introduced without detection, failing the change-integrity aspect of this criterion.

Remediation: Enable branch protection with required reviews, status checks, and signed commits on all production repos; enforce CODEOWNERS and block force-pushes.

Evidence: Inspected AWS IAM for the root account and administrative IAM users; MFA was not enabled on the root user or several admin accounts. Separately, Google Workspace did not enforce 2-Step Verification for all users.

Why it fails: MFA is not enforced on the most privileged AWS identities nor across the Google tenant, leaving high-value access protected by passwords alone.

Remediation: Enable hardware MFA on the AWS root account, enforce MFA for all IAM admins via SCP/conditional policy, and turn on enforced 2SV for all Google Workspace users with phishing-resistant methods for admins.

Evidence: Reviewed detective controls for storage integrity; production and backup S3 buckets lacked Object Versioning and MFA-Delete, so unauthorized or accidental deletion/overwrite would go undetected and be irrecoverable.

Why it fails: Configuration/integrity monitoring for backup data is insufficient; absence of versioning and MFA-delete means tampering or deletion cannot be detected or reversed.

Remediation: Enable versioning and MFA-Delete on backup buckets, apply Object Lock (compliance mode) for immutable retention, and alert on lifecycle/policy changes via EventBridge.

Evidence: Assessed detective monitoring across the AWS estate; with CloudTrail disabled in two active regions (AEG-0003) and no GuardDuty/alerting in those regions, anomalous activity in EHR/analytics workloads would not be detected.

Why it fails: Anomaly detection cannot function where log sources are absent, so the monitoring criterion is not met for the affected regions.

Remediation: Extend CloudTrail, GuardDuty, and Security Hub to all regions, centralize findings, and define alerting for high-severity detections with defined response SLAs.

Evidence: Requested the incident response runbook and evidence of a tabletop/test during the period; no documented, tested IR runbook with defined roles, escalation, and HIPAA breach-notification steps was available.

Why it fails: The entity cannot demonstrate a defined and tested incident response program, so this criterion fails; breach-notification timing obligations may not be met in a real event.

Remediation: Develop a documented IR runbook covering detection-through-recovery and HIPAA §164.410 breach notification, assign roles, and conduct at least one tabletop exercise per year with recorded results.

Evidence: Reviewed secret-management practices in source control; a hardcoded API secret was committed to an internal GitHub repository and present in history, indicating change controls did not prevent secret exposure.

Why it fails: The change process did not detect or prevent a committed credential, and combined with missing branch protection (AEG-0012) the change-authorization/review discipline is deficient.

Remediation: Rotate the exposed secret immediately, purge it from git history, enable GitHub secret scanning + push protection, and move secrets to AWS Secrets Manager / a vault referenced at runtime.

Evidence: Reviewed the Okta password policy; minimum length, complexity, and breached-password screening were configured below NIST SP 800-63B guidance (e.g., short minimum length, forced periodic rotation without compromise checks).

Why it fails: The authentication policy does not meet current NIST guidance, weakening baseline identity assurance across the workforce.

Remediation: Update the Okta password policy to a 12+ character minimum, enable breached-password detection, remove arbitrary periodic rotation, and prioritize passwordless/FIDO2 factors.

Evidence: IAM credential report shows the root account and three break-glass admin users (admin-ops, admin-ehr, admin-cloud) have console passwords set but no MFA device registered.

Why it fails: PHI-bearing AWS environment permits privileged access with a single authentication factor, so a stolen credential grants unfettered access to ePHI systems.

Remediation: Enable a hardware/virtual MFA device on the root account, lock away root credentials, and enforce MFA for all IAM admin users via an SCP/IAM condition (aws:MultiFactorAuthPresent).

Evidence: Okta admin console shows 7 users holding Super Administrator / Org Administrator roles with no step-up (assurance) authentication policy binding admin actions to a phishing-resistant factor.

Why it fails: Administrators of the identity plane that fronts ePHI apps can authenticate and perform privileged changes without re-verifying identity, weakening authentication assurance for the most sensitive accounts.

Remediation: Create an Okta authentication policy requiring step-up MFA (WebAuthn/FIDO2) for the Admin Console and all admin-role app access; deny password-only sessions for privileged roles.

Evidence: Cross-referencing HR termination dates against Okta user status found 14 accounts belonging to separated staff (last termination 3+ months prior) still in ACTIVE state with app assignments to clinical systems.

Why it fails: Access for terminated workforce members was not revoked, leaving standing credentials into ePHI applications and violating the required termination workflow.

Remediation: Integrate Workday/HRIS with Okta lifecycle (SCIM deprovisioning), auto-suspend on termination event, and run a monthly HR-to-IdP reconciliation.

Evidence: IAM policy analysis identified customer-managed policies attached to operator roles granting Action: "*" or service-wildcard actions (e.g., s3:*, rds:*) on Resource: "*".

Why it fails: Wildcard grants exceed the minimum necessary standard, allowing operators broader access to ePHI resources than their job function requires.

Remediation: Replace wildcard actions with scoped, resource-constrained policies; use IAM Access Analyzer to right-size permissions based on observed access.

Evidence: Security group ingress rules permit TCP 22 (SSH) and 3389 (RDP) from 0.0.0.0/0 on subnets hosting application and management hosts adjacent to the EHR tier.

Why it fails: Unrestricted internet-facing administrative ports expose ePHI-adjacent hosts to brute-force and exploitation, breaching access-restriction requirements.

Remediation: Remove 0.0.0.0/0 rules for 22/3389; require access via SSM Session Manager or a bastion behind the VPN, scoped to corporate CIDRs.

Evidence: RDS PostgreSQL instance hosting EHR data has PubliclyAccessible=true with an EIP and a security group allowing 5432 from the internet.

Why it fails: The database carrying ePHI is reachable from public networks, exposing patient data in transit and at the connection boundary to interception and unauthorized access.

Remediation: Set PubliclyAccessible=false, move the instance to private subnets, restrict 5432 to app security groups, and enforce TLS (rds.force_ssl=1).

Evidence: Bucket policy / ACL evaluation shows the clinical-exports bucket grants s3:GetObject to the AuthenticatedUsers group (any AWS principal), and objects are the primary PHI export store.

Why it fails: PHI export objects are readable by any authenticated AWS account, negating the confidentiality that encryption-at-rest is meant to protect and constituting an impermissible disclosure exposure.

Remediation: Remove AuthenticatedUsers grant, enable S3 Block Public Access at account+bucket level, enforce SSE-KMS with a restricted key policy, and scope access to named roles only.

Evidence: A hardcoded API secret (integration bearer token) was found committed to an internal GitHub repository; the credential was live and had not surfaced in any risk register or scan.

Why it fails: Exposed secrets in source control indicate ePHI-integration risks are not being systematically identified and evaluated, a gap in the required risk-analysis process (and an active exposure).

Remediation: Rotate the leaked secret, purge it from git history, enable GitHub secret scanning + push protection org-wide, and add secrets exposure to the recurring risk analysis.

Evidence: CloudTrail configuration shows management-event trails disabled (not logging) in two active regions that host workloads with ePHI access, leaving a gap in the API audit record.

Why it fails: Without CloudTrail in active regions there is no reliable record of access to and activity on ePHI systems, defeating the required audit mechanism.

Remediation: Deploy an organization-wide multi-region CloudTrail with log-file validation, deliver to a locked central S3 bucket, and alert on trail-disable events.

Evidence: EHR backup buckets have S3 Versioning=Suspended and MFA-Delete not enabled; lifecycle allows permanent object deletion without a second factor.

Why it fails: Backups of ePHI can be silently overwritten or deleted, undermining protection against improper alteration or destruction (and ransomware resilience).

Remediation: Enable Versioning + MFA-Delete (or S3 Object Lock in compliance mode) on backup buckets and restrict delete permissions to a dedicated break-glass role.

Evidence: Org repositories (including clinical integration services) have no branch protection: no required pull-request reviews, no status checks, direct pushes to main permitted.

Why it fails: Code affecting ePHI-processing systems can be changed without review or verification, so there is no mechanism to corroborate integrity of changes reaching production.

Remediation: Enforce branch protection on default branches: require PR + minimum 1-2 reviewers, passing CI checks, and signed commits for ePHI-related repos.

Evidence: Drive sharing report identified files and folders containing patient information set to "Anyone with the link" / published to the web, including scanned intake forms.

Why it fails: Patient information is disclosed to the public via link-sharing with no access control, an impermissible disclosure well beyond the minimum-necessary standard.

Remediation: Revoke public link-sharing, set org policy to restrict external sharing to allow-listed domains, apply DLP rules that block sharing of PHI patterns, and audit historical shares.

Evidence: Okta password policy enforces a 6-character minimum with periodic forced expiration and no breached-password check, below NIST SP 800-63B guidance.

Why it fails: Weak length requirements and expiration-driven rotation without compromised-credential screening produce guessable, reused passwords protecting ePHI access.

Remediation: Raise minimum length to 12+, remove mandatory periodic expiration, enable Okta's common/breached password detection, and require MFA to compensate.

Evidence: Admin console shows 2-Step Verification is set to "allowed" but not "enforced"; a material share of accounts (including clinical staff) authenticate with password only.

Why it fails: Without enforced 2SV, compromised passwords lead directly to account takeover of Workspace mailboxes and Drive holding ePHI, weakening log-in protection.

Remediation: Enforce 2SV for all users (grace period for enrollment), require security keys for admins, and monitor login-challenge failures in the security dashboard.

Evidence: No documented, tested incident-response runbook exists for cloud/ePHI incidents; there is no defined breach-triage, evidence-preservation, or OCR notification workflow, and no tabletop record.

Why it fails: The organization cannot demonstrate a repeatable process to detect, contain, document, and report ePHI incidents, undermining the required response-and-reporting safeguard.

Remediation: Author IR runbooks (detection, containment, forensics, HIPAA breach-notification decision tree), assign roles, and validate with at least an annual tabletop exercise.

Evidence: IAM credential report lists multiple active access keys older than 400 days (several tied to service and human users with EHR-adjacent permissions) with no rotation.

Why it fails: Long-lived, un-rotated credentials are a known, unmitigated risk to ePHI systems, indicating risk-management measures are not being applied to a reasonable level.

Remediation: Rotate/retire keys older than 90 days, enforce a max-key-age policy, migrate to IAM roles / short-lived credentials, and alert on stale keys.

Evidence: IAM credential report field mfa_active=false for the root user of the management account; account summary AccountMFAEnabled=0.

Why it fails: The root user has no MFA device registered, leaving the highest-privilege account protected only by a password (AEG-0002). For an org processing PHI this is an unacceptable single point of compromise.

Remediation: Register a hardware or virtual MFA device on the root user immediately, store the root credentials in a break-glass vault, and enable MFA on all IAM admin principals.

Evidence: No virtual or hardware MFA device is attached to root (ListVirtualMFADevices empty; ListMFADevices empty for root).

Why it fails: Beyond the general MFA gap, CIS recommends hardware MFA for root specifically; none is present (AEG-0002).

Remediation: Provision a dedicated hardware MFA token (e.g., FIDO2 key or YubiKey) exclusively for root and physically secure it.

Evidence: Credential report shows 2 of 9 console-enabled IAM users (ehr-admin, backup-admin) with password_enabled=true and mfa_active=false; both carry AdministratorAccess.

Why it fails: Privileged admin IAM users can authenticate to the console with a password alone (AEG-0002). These accounts can reach EHR and PHI export resources.

Remediation: Enforce MFA via an IAM policy that denies actions when aws:MultiFactorAuthPresent is false, and register MFA for all console users; prefer federated SSO with step-up MFA.

Evidence: Credential report shows access keys with last_used dates >90 days on legacy service accounts still marked Active.

Why it fails: Stale, unused credentials remain enabled, expanding the attack surface and overlapping with the long-lived key issue in AEG-0004.

Remediation: Disable console access and access keys unused for 45+ days; adopt an automated credential-lifecycle job.

Evidence: Credential report shows active access keys with access_key_1_last_rotated exceeding 400 days on the HL7 integration and reporting service accounts.

Why it fails: Access keys older than 400 days are still active (AEG-0004), far beyond the 90-day CIS threshold. Long-lived keys touching HL7/EHR integration are high-value and hard to revoke cleanly if leaked.

Remediation: Rotate all access keys older than 90 days, migrate service integrations to IAM roles where possible, and enable a rotation-enforcement rule in AWS Config.

Evidence: ListUserPolicies/ListAttachedUserPolicies show inline and directly-attached policies on individual users rather than group-based assignment.

Why it fails: Permissions attached directly to users bypass group-based governance and correlate with the wildcard-policy sprawl in AEG-0015.

Remediation: Refactor permissions into IAM groups/permission sets managed via IAM Identity Center; remove inline user policies.

Evidence: A customer-managed policy contains a statement with Effect=Allow, Action='*', Resource='*' and is attached to two roles.

Why it fails: Overly permissive wildcard policies grant unbounded action/resource scope (AEG-0015), violating least privilege in an environment holding PHI.

Remediation: Replace wildcard policies with scoped, resource-constrained permissions; use IAM Access Analyzer to right-size based on CloudTrail usage.

Evidence: ListAnalyzers returns an active analyzer only in us-east-1; us-west-2 and two other active regions have no analyzer.

Why it fails: Access Analyzer is not enabled across all active regions, so external-access findings (like the PHI bucket in AEG-0001) are not continuously surfaced everywhere.

Remediation: Enable an organization-level IAM Access Analyzer covering all active regions and route findings to Security Hub.

Evidence: The PHI export bucket policy lacks a Deny statement on aws:SecureTransport=false; GetBucketPolicy shows no TLS-enforcement condition.

Why it fails: The clinical export bucket does not enforce encryption-in-transit, compounding the broad access exposure in AEG-0001 for a bucket holding PHI.

Remediation: Add a bucket policy statement denying requests where aws:SecureTransport is false across all PHI buckets.

Evidence: GetBucketVersioning shows Status=Suspended and MFADelete=Disabled on both backup buckets.

Why it fails: Backup buckets lack versioning and MFA-delete (AEG-0010), so backups can be silently overwritten or deleted — undermining ransomware recovery for a healthcare provider.

Remediation: Enable versioning and MFA-delete on all backup buckets and apply Object Lock (compliance mode) for immutable retention.

Evidence: The bucket ACL/policy grants access to the AuthenticatedUsers group (any AWS principal); account-level and bucket-level Block Public Access is not fully enabled for this bucket.

Why it fails: The PHI export bucket is readable by any authenticated AWS account (AEG-0001), effectively exposing patient data beyond the organization — a HIPAA breach condition.

Remediation: Enable Block Public Access at the account and bucket level, remove the AuthenticatedUsers grant, restrict access to a specific role, and enable default SSE-KMS.

Evidence: DescribeDBInstances shows PubliclyAccessible=true and the instance resolves to a public IP; the DB subnet group maps to public subnets.

Why it fails: The RDS instance hosting EHR data is internet-reachable (AEG-0005), exposing the clinical database to network-level attack even though it is encrypted at rest.

Remediation: Set PubliclyAccessible=false, move the instance to private subnets, restrict the security group to app-tier CIDRs, and require access via bastion/VPN.

Evidence: DescribeTrails/GetTrailStatus show the org trail with IsMultiRegionTrail=false and no active trail in us-west-2 and eu-west-1, both of which have running resources.

Why it fails: CloudTrail is disabled in two active regions (AEG-0003), creating audit blind spots where API activity against PHI resources is not recorded.

Remediation: Convert to a multi-region organization trail delivered to a locked, centralized S3 bucket with log-file validation enabled.

Evidence: GetTrail shows LogFileValidationEnabled=false on the primary trail.

Why it fails: Without log-file validation, CloudTrail logs cannot be proven tamper-free (related to AEG-0003), weakening forensic integrity.

Remediation: Enable log file validation and restrict delete permissions on the log bucket.

Evidence: DescribeConfigurationRecorderStatus shows recording=true only in us-east-1; other active regions have no recorder.

Why it fails: AWS Config is not recording in all active regions, so configuration drift (public buckets, public RDS) is not continuously detected everywhere.

Remediation: Deploy AWS Config recorders in all active regions via an organization aggregator with conformance packs mapped to CIS.

Evidence: DescribeMetricFilters shows no filter/alarm for UnauthorizedOperation/AccessDenied events; no SNS alarm target configured.

Why it fails: No detective alerting exists for unauthorized API activity, and there is no tested IR runbook to act on such alerts (AEG-0014).

Remediation: Create CloudWatch metric filters and alarms per CIS section 4, wire them to an SNS topic, and document a tested incident-response runbook.

Evidence: No metric filter matching userIdentity.type=Root exists; no alarm notifies on root sign-in or root API use.

Why it fails: Root-account usage is not alerted on, so a compromise of the un-MFA'd root user (AEG-0002) would go undetected; ties to the absent IR process (AEG-0014).

Remediation: Add a root-usage metric filter and alarm, and define the escalation path in the incident-response runbook.

Evidence: DescribeSecurityGroups shows inbound rules permitting tcp/22 and tcp/3389 from 0.0.0.0/0 on two security groups attached to running instances.

Why it fails: Security groups allow unrestricted SSH/RDP from the internet (AEG-0011), exposing administrative access to brute-force and exploit traffic.

Remediation: Remove 0.0.0.0/0 rules for 22/3389; require SSM Session Manager or VPN/bastion with source-restricted CIDRs.