HIPAA Security Rule (45 CFR §164.312 Technical Safeguards, 2013 Final Rule) Pre-Audit Gap Report

Generated: 2026-06-24T23:07:45.339Z

Cover: Scope Attestation

Report ID
aws_20260624_160745
Generated at
2026-06-24T23:07:45.339Z
Assessment type
Point-in-time (Type-I-friendly). NOT a Type-II operating-effectiveness assertion.
Scanner
NSAuditor AI EE v0.31.3 (CE v0.2.15)
Scan window
(not provided) → (not provided)
Targets in scope
aws
Targets explicitly excluded
None
Framework
HIPAA Security Rule (45 CFR §164.312 Technical Safeguards, 2013 Final Rule) (version 2013-final)
Report integrity
SHA-256 in companion .sha256 sidecar — verify: shasum -a 256 -c <file>.sha256
Trusted timestamp (RFC 3161)
Not configured. SHA-256 provides integrity only. For non-repudiation, configure complianceTsaUrl.
TSA policy OID
N/A — TSA itself is not configured.
TSA cert chain bundling
N/A — TSA itself is not configured.
Clock advisory
ℹ️ local_clock (Active NTP-drift probing deferred to EE-SOC2.8 (v0.3.1). Local-clock advisory only.)

This attestation page is required by SOC 2 auditors as proof-of-scope. Without it, reports are routinely rejected for ambiguous coverage.

Executive Summary

Failing Controls

164.312(a)(1) — Access Control FAIL

Category: Technical Safeguards · Access Control · Violations: 15
SHADOW ADMIN: User has full wildcard (*) permissions
Source: aws-iam-deep-auditor
§164.312(a)(1) cross-references §164.308(a)(4) for access-rights assignment; shadow admins bypass intended access restrictions to ePHI-bearing resources by aggregating effective-admin permissions across attached/inline policies.
Privilege escalation paths detected: iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:AttachUserPolicy, iam:AttachGroupPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutGroupPolicy, iam:PutRolePolicy, iam:CreateUser, iam:CreateRole, iam:CreateLoginProfile, iam:UpdateLoginProfile, iam:CreateAccessKey, iam:AddUserToGroup, iam:UpdateAssumeRolePolicy, iam:PutRolePermissionsBoundary, iam:DeleteRolePermissionsBoundary, iam:PutUserPermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:PassRole, sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity, sts:GetFederationToken, lambda:CreateFunction, lambda:InvokeFunction, lambda:UpdateFunctionCode, ec2:RunInstances, cloudformation:CreateStack, datapipeline:CreatePipeline, glue:CreateDevEndpoint, glue:UpdateDevEndpoint, kms:CreateGrant, kms:PutKeyPolicy, kms:ScheduleKeyDeletion
Source: aws-iam-deep-auditor
§164.312(a)(1) requires that access rights be granted as specified in §164.308(a)(4) (Information Access Management); privesc paths grant rights NOT specified in the access-management plan by allowing self-elevation.
Shadow admin path: northwind-deploy → northwind-ci-role (role) [inline: northwind-ci-policy]
Source: aws-iam-deep-auditor
§164.312(a)(1) cross-references §164.308(a)(4) for access-rights assignment; shadow admins bypass intended access restrictions to ePHI-bearing resources by aggregating effective-admin permissions across attached/inline policies.
SHADOW ADMIN: User has full wildcard (*) permissions
Source: aws-iam-deep-auditor
§164.312(a)(1) cross-references §164.308(a)(4) for access-rights assignment; shadow admins bypass intended access restrictions to ePHI-bearing resources by aggregating effective-admin permissions across attached/inline policies.
Privilege escalation paths detected: iam:CreatePolicyVersion, iam:SetDefaultPolicyVersion, iam:AttachUserPolicy, iam:AttachGroupPolicy, iam:AttachRolePolicy, iam:PutUserPolicy, iam:PutGroupPolicy, iam:PutRolePolicy, iam:CreateUser, iam:CreateRole, iam:CreateLoginProfile, iam:UpdateLoginProfile, iam:CreateAccessKey, iam:AddUserToGroup, iam:UpdateAssumeRolePolicy, iam:PutRolePermissionsBoundary, iam:DeleteRolePermissionsBoundary, iam:PutUserPermissionsBoundary, iam:DeleteUserPermissionsBoundary, iam:PassRole, sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity, sts:GetFederationToken, lambda:CreateFunction, lambda:InvokeFunction, lambda:UpdateFunctionCode, ec2:RunInstances, cloudformation:CreateStack, datapipeline:CreatePipeline, glue:CreateDevEndpoint, glue:UpdateDevEndpoint, kms:CreateGrant, kms:PutKeyPolicy, kms:ScheduleKeyDeletion
Source: aws-iam-deep-auditor
§164.312(a)(1) requires that access rights be granted as specified in §164.308(a)(4) (Information Access Management); privesc paths grant rights NOT specified in the access-management plan by allowing self-elevation.
Shadow admin path: northwind-root → northwind-ci-role (role) [via policy: arn:aws:iam::aws:policy/AdministratorAccess, arn:aws:iam::aws:policy/AdministratorAccess-Amplify]
Source: aws-iam-deep-auditor
§164.312(a)(1) cross-references §164.308(a)(4) for access-rights assignment; shadow admins bypass intended access restrictions to ePHI-bearing resources by aggregating effective-admin permissions across attached/inline policies.
DynamoDB table 'northwind-inventory' has no resource policy attached (access control via IAM identity policies only). For audit-store tables, an explicit resource-policy boundary is the institutional defense-in-depth pattern: a resource policy can encode 'only the audit-writer role can PutItem' independently of IAM-policy drift. Consider attaching a resource policy with explicit Deny on DeleteTable/DeleteItem/UpdateItem for non-audit-writer principals (CC6.6).
Source: aws-dynamodb-auditor
§164.312(a)(1) cross-account access-control gap. DynamoDB tables without a resource policy rely solely on IAM identity-based policies; defense-in-depth via resource-policy boundary is absent on ePHI-bearing tables.
DynamoDB table 'northwind-sessions' has no resource policy attached (access control via IAM identity policies only). For audit-store tables, an explicit resource-policy boundary is the institutional defense-in-depth pattern: a resource policy can encode 'only the audit-writer role can PutItem' independently of IAM-policy drift. Consider attaching a resource policy with explicit Deny on DeleteTable/DeleteItem/UpdateItem for non-audit-writer principals (CC6.6).
Source: aws-dynamodb-auditor
§164.312(a)(1) cross-account access-control gap. DynamoDB tables without a resource policy rely solely on IAM identity-based policies; defense-in-depth via resource-policy boundary is absent on ePHI-bearing tables.
Lambda function 'nw-checkout-fn' has a public Function URL with AuthType: NONE — exposes the function to public internet without authentication. CC6.1 violation; SOC 2 institutional CRITICAL (parallel to API Gateway NONE-authorizer class). Set AuthType to AWS_IAM (uses SigV4) or front with API Gateway authorizer.
Source: aws-lambda-auditor
§164.312(a)(1) requires authenticated logical access on every entry point to ePHI. Lambda Function URLs configured with `AuthType: NONE` expose the underlying function directly to unauthenticated callers — parallel to the API Gateway NONE-authorizer §164.312(a)(1) violation class.
IAM principal 'northwind-deploy' (user) has effective kms:Decrypt on Resource:* via policy inline-user:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(1) least-privilege boundary on cryptographic-access (cross-mapped from §164.312(a)(2)(iv)). IAM principals with effective kms:Decrypt on Resource:* can decrypt EVERY KMS key whose key policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
IAM principal 'northwind-root' (user) has effective kms:Decrypt on Resource:* via policy attached-managed:AdministratorAccess (arn:aws:iam::aws:policy/AdministratorAccess) (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(1) least-privilege boundary on cryptographic-access (cross-mapped from §164.312(a)(2)(iv)). IAM principals with effective kms:Decrypt on Resource:* can decrypt EVERY KMS key whose key policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
IAM principal 'northwind-ci-role' (role) has effective kms:Decrypt on Resource:* via policy inline-role:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(1) least-privilege boundary on cryptographic-access (cross-mapped from §164.312(a)(2)(iv)). IAM principals with effective kms:Decrypt on Resource:* can decrypt EVERY KMS key whose key policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [5432 PostgreSQL]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.
Source: aws-ec2-sg-perimeter-auditor
§164.312(a)(1) network-segmentation gap. Security Group permits public ingress to restricted ports (databases, management protocols) on ePHI-bearing ENIs.
Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [22 SSH]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.
Source: aws-ec2-sg-perimeter-auditor
§164.312(a)(1) network-segmentation gap. Security Group permits public ingress to restricted ports (databases, management protocols) on ePHI-bearing ENIs.
Security Group 'sg-0abcdef0100000012' (name='nw-web-sg', vpc='vpc-0abcdef0100000010') permits tcp ingress from 0.0.0.0/0 to restricted port(s) [6379 Redis]. CC6.6 perimeter CRITICAL: management/data-tier ports MUST NOT be reachable from the public internet. Remediate by restricting the CIDR source to the operator's bastion / VPN / VPC CIDR.
Source: aws-ec2-sg-perimeter-auditor
§164.312(a)(1) network-segmentation gap. Security Group permits public ingress to restricted ports (databases, management protocols) on ePHI-bearing ENIs.

164.312(a)(2)(iv) — Encryption and Decryption FAIL

Category: Technical Safeguards · Access Control · Implementation Specification · Violations: 41
Server-side encryption uses AES256 (not KMS-CMK)
Source: aws-s3-auditor
§164.312(a)(2)(iv) addressed at the AES256 level but with reduced key-control granularity. AWS-managed AES256 provides encryption but no customer-managed-key (CMK) audit/rotation/revocation control on ePHI key material — preferred for high-sensitivity ePHI is SSE-KMS with customer-managed CMK.
Server-side encryption uses AES256 (not KMS-CMK)
Source: aws-s3-auditor
§164.312(a)(2)(iv) addressed at the AES256 level but with reduced key-control granularity. AWS-managed AES256 provides encryption but no customer-managed-key (CMK) audit/rotation/revocation control on ePHI key material — preferred for high-sensitivity ePHI is SSE-KMS with customer-managed CMK.
Server-side encryption uses AES256 (not KMS-CMK)
Source: aws-s3-auditor
§164.312(a)(2)(iv) addressed at the AES256 level but with reduced key-control granularity. AWS-managed AES256 provides encryption but no customer-managed-key (CMK) audit/rotation/revocation control on ePHI key material — preferred for high-sensitivity ePHI is SSE-KMS with customer-managed CMK.
Bucket policy grants public access
Source: aws-s3-auditor
§164.312(a)(2)(iv) cross-references §164.312(a)(1) — bucket policy granting public access provides decrypted ePHI to anonymous callers regardless of at-rest encryption configuration.
Object ACL grants public access (AllUsers) on 2 of 7 sampled objects – objects publicly accessible
Source: aws-s3-auditor
§164.312(a)(2)(iv) encryption is moot if access boundary is breached. Publicly-accessible S3 buckets defeat the entire encryption-and-decryption mechanism since the public can request decrypted objects.
Object ACL grants public access (AllUsers) on 1 of 1 sampled non-current versions – objects publicly accessible
Source: aws-s3-auditor
§164.312(a)(2)(iv) encryption is moot if access boundary is breached. Publicly-accessible S3 buckets defeat the entire encryption-and-decryption mechanism since the public can request decrypted objects.
Server-side encryption uses AES256 (not KMS-CMK)
Source: aws-s3-auditor
§164.312(a)(2)(iv) addressed at the AES256 level but with reduced key-control granularity. AWS-managed AES256 provides encryption but no customer-managed-key (CMK) audit/rotation/revocation control on ePHI key material — preferred for high-sensitivity ePHI is SSE-KMS with customer-managed CMK.
DynamoDB table 'northwind-inventory' uses KMS encryption but the returned KMSMasterKeyArn is a :key/UUID form, not an alias — cannot determine AWS-managed vs customer-managed from the SSE response alone. Verify via 'aws kms describe-key --key-id arn:aws:kms:us-east-1:123456789012:key/0a1b2c3d-4e5f-4a1b-8c2d-000000000007' and check KeyManager (AWS = AWS-managed; CUSTOMER = customer-managed-CMK / PASS). EE-RT.3 v1 added automated kms:DescribeKey cross-reference; if this finding still emits, KMS SDK was unavailable OR caller did not provide kmsClient OR kms:DescribeKey returned AccessDenied / NotFoundException.
Source: aws-dynamodb-auditor
§164.312(a)(2)(iv) (Encryption and Decryption, Addressable) class-O evidence-gap — DynamoDB at-rest key-custody UNVERIFIED (KMSMasterKeyArn unclassifiable); fails-close == the AWS-owned-default-encryption positive rather than the prior silent clean. Plugin 1060.
DynamoDB table 'northwind-sessions' uses AWS-owned default encryption (no SSEDescription or SSEType=AES256). Customer has no key custody; AWS-owned keys cannot be disabled, audited, or rotated by the customer. Auditors require KMS-CMK (customer-managed key) for audit-store tables (C1.1 key-custody requirement).
Source: aws-dynamodb-auditor
§164.312(a)(2)(iv) — DynamoDB AWS-owned encryption is automatic but uses an AWS-managed key with no customer key-policy control. Acceptable for low-sensitivity ePHI; high-sensitivity ePHI should use SSE-KMS with customer-managed CMK for breach-revocation capability.
Customer-managed KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000003' has automatic key rotation DISABLED. CC6.3 expects cryptographic credential rotation cadence; AWS recommends enabling annual automatic rotation for customer-managed symmetric encryption keys. Enable via kms:EnableKeyRotation, or document the manual rotation procedure for auditor walkthrough.
Source: aws-kms-auditor
§164.312(a)(2)(iv) — KMS key rotation is part of the encryption-mechanism lifecycle. Disabled rotation on a customer-managed CMK protecting ePHI means the key bytes never rotate; a compromised key remains valid indefinitely.
KMS key '0a1b2c3d-4e5f-4a1b-8c2d-000000000003' policy grants Principal: AWS: "*" on 1 sensitive action(s) [kms:Decrypt] WITHOUT Condition (any authenticated AWS principal can perform these confidentiality-boundary-crossing actions). C1.1 confidentiality-boundary risk.
Source: aws-kms-auditor
§164.312(a)(2)(iv) encryption-mechanism gap. KMS key policy grants wildcard Principal on sensitive actions (kms:Decrypt, kms:GenerateDataKey, kms:DescribeKey) — any AWS principal can decrypt ePHI protected by this key.
Lambda function 'nw-checkout-fn' has 3 environment variable(s) with secret-suggestive name(s) [API_KEY, DB_PASSWORD, SECRET_TOKEN]. C1.1 confidentiality risk: hardcoded secrets in environment variables are visible to anyone with lambda:GetFunctionConfiguration permission. Migrate to AWS Secrets Manager or Parameter Store (with KMS-CMK encryption + IAM-restricted access). Scanner inspects only env-var NAMES (ZDE-safe — values never read).
Source: aws-lambda-auditor
§164.312(a)(2)(iv) — Lambda env-vars are stored encrypted at-rest by Lambda but visible to anyone with lambda:GetFunctionConfiguration. Secret-suggestive names indicate credentials should be in SSM Parameter Store (SecureString) or Secrets Manager, not env-vars.
SSM Parameter '/northwind/prod/legacy-api-key' is Type: String (plaintext) but the parameter NAME suggests it stores a secret. C1.1 confidentiality-boundary violation: any principal with ssm:GetParameter / ssm:GetParameters / ssm:GetParametersByPath can read the value in cleartext, without KMS decryption authorization. Migrate to Type: SecureString with a customer-managed KMS key. Scanner inspects only parameter NAMES (ZDE-safe — VALUES never read).
Source: aws-secrets-auditor
§164.312(a)(2)(iv) encryption-mechanism gap. SSM Parameter of Type:String stores values in cleartext; a name suggesting secret/credential storage indicates ePHI-adjacent material (credentials to ePHI-bearing systems) is unencrypted at-rest.
RDS DB instance 'northwind-analytics-cluster' uses AWS-managed KMS key (arn:aws:kms:us-east-1:123456789012:key/0a1b2c3d-4e5f-4a1b-8c2d-000000000002) — promoted from UNVERIFIABLE LOW via kms:DescribeKey cross-reference (KeyManager=AWS). C1.1 confidentiality is in effect but key custody lives in the AWS-managed key pool rather than the customer's KMS keyring — not customer-rotatable / not customer-revocable. Prefer customer-managed CMK via snapshot-restore-with-KmsKeyId for production-tier databases.
Source: aws-rds-auditor
§164.312(a)(2)(iv) (Encryption and Decryption, Addressable) — P2 key-custody doctrine 2026-06-22: RDS (AWS-managed KMS, promoted) ePHI IS encrypted at rest but under a provider-managed key (no customer rotation/revocation/crypto-shred). Floor + iso A.8.24; the encryption-presence controls are SATISFIED. Severity unchanged.
RDS DB instance 'northwind-orders-db' has storage encryption DISABLED (StorageEncrypted=false). C1.1 confidentiality gap: underlying EBS volume, automated snapshots, and read-replicas all unencrypted; no crypto-shred capability. Storage encryption cannot be enabled in-place — requires snapshot + restore-to-new-instance with KmsKeyId set.
Source: aws-rds-auditor
§164.312(a)(2)(iv) direct gap. RDS DB instance with StorageEncrypted=false stores ePHI in cleartext on EBS volumes — direct absence of the encryption-and-decryption mechanism for at-rest ePHI.
SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' has encryption-at-rest DISABLED (SqsManagedSseEnabled=false AND no KmsMasterKeyId set). C1.1 confidentiality gap: queue message bodies are stored on Amazon's SQS service infrastructure in cleartext (subject to Amazon employee operational access per the AWS shared-responsibility model). Enable SqsManagedSseEnabled=true (AWS-managed) OR set KmsMasterKeyId to a customer-managed CMK alias (customer key custody).
Source: aws-sqs-sns-auditor
§164.312(a)(2)(iv) direct gap on message-queue payloads. SQS queue with encryption-at-rest disabled stores messages (potentially containing ePHI in transit between systems) in cleartext at the SQS storage layer.
SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' uses AWS-managed KMS key (alias/aws/sqs). C1.1 confidentiality is in effect but key custody lives in the AWS-managed key pool — not customer-rotatable / not customer-revocable. For production-tier confidential workloads, prefer customer-managed CMK.
Source: aws-sqs-sns-auditor
§164.312(a)(2)(iv) (Encryption and Decryption, Addressable) — P2 key-custody doctrine 2026-06-22: SQS (AWS-managed KMS) ePHI IS encrypted at rest but under a provider-managed key (no customer rotation/revocation/crypto-shred). Floor + iso A.8.24; the encryption-presence controls are SATISFIED. Severity unchanged.
SNS topic 'arn:aws:sns:us-east-1:123456789012:nw-notifications' has encryption-at-rest DISABLED (no KmsMasterKeyId set). C1.1 confidentiality gap: published messages are stored on Amazon's SNS service infrastructure in cleartext until delivery. SNS has no SQS-managed-SSE equivalent — the ONLY at-rest encryption mechanism is a customer-set KmsMasterKeyId. Enable via SetTopicAttributes KmsMasterKeyId=<alias/aws/sns or CMK alias>.
Source: aws-sqs-sns-auditor
§164.312(a)(2)(iv) direct gap on notification payloads. SNS topic with encryption-at-rest disabled stores notification messages in cleartext.
SNS topic 'arn:aws:sns:us-east-1:123456789012:sns-encrypted-topic' uses AWS-managed KMS key (alias/aws/sns). C1.1 confidentiality is in effect but key custody is AWS-managed — not customer-rotatable / not customer-revocable. For production-tier confidential topics, prefer customer-managed CMK.
Source: aws-sqs-sns-auditor
§164.312(a)(2)(iv) (Encryption and Decryption, Addressable) — P2 key-custody doctrine 2026-06-22: SNS (AWS-managed KMS) ePHI IS encrypted at rest but under a provider-managed key (no customer rotation/revocation/crypto-shred). Floor + iso A.8.24; the encryption-presence controls are SATISFIED. Severity unchanged.
IAM principal 'northwind-deploy' (user) has effective kms:Decrypt on Resource:* via policy inline-user:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(2)(iv) encryption-boundary scope gap. IAM principal with effective kms:Decrypt on Resource:* can decrypt every KMS key whose policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
IAM principal 'northwind-root' (user) has effective kms:Decrypt on Resource:* via policy attached-managed:AdministratorAccess (arn:aws:iam::aws:policy/AdministratorAccess) (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(2)(iv) encryption-boundary scope gap. IAM principal with effective kms:Decrypt on Resource:* can decrypt every KMS key whose policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
IAM principal 'northwind-ci-role' (role) has effective kms:Decrypt on Resource:* via policy inline-role:northwind-ci-policy (statement 0). Action(s): [*]; Resource(s): [*]. CC6.1 / C1.1 / CC6.3 risk: principal can decrypt EVERY KMS key whose key policy permits the principal — confidentiality blast-radius is account-wide for any wildcard-permissive key policy. Replace Resource:* with specific key ARN(s) bound to least-privilege. Evidence layer note (EE 0.9.1 B-CRIT-1/2 closure): this finding reflects the identity-policy GRANT — one of the layers required for effective decrypt; the others (KMS key policy + KMS grants) are now cross-referenced per the run-level kms-grant-decrypt-no-identity-grant emission and the HIGH→INFO downgrade contract when no key in the account trusts this principal. SCP / Permissions Boundary / Deny statements remain plugin 1030's domain and the scope-deferred block.
Source: aws-iam-effective-decrypt-auditor
§164.312(a)(2)(iv) encryption-boundary scope gap. IAM principal with effective kms:Decrypt on Resource:* can decrypt every KMS key whose policy admits them — the ePHI confidentiality blast-radius is account-wide for any wildcard-permissive key policy.
EC2 account default EBS encryption is DISABLED in ap-south-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in eu-north-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in eu-west-3 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in eu-west-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in eu-west-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ap-northeast-3 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ap-northeast-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ap-northeast-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ca-central-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in sa-east-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ap-southeast-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in ap-southeast-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in eu-central-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EBS volume 'vol-0abcdef0100000014' attached to instance 'i-0a1b2c3d4e5f60718' has encryption DISABLED (Encrypted=false). C1.1 confidentiality gap: volume data at rest is stored unencrypted; without encryption there is no crypto-shred capability on decommission. Remediate by recreating the volume from an encrypted snapshot (default EBS encryption recommended account-wide).
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — an EBS volume with Encrypted=false stores ePHI in cleartext at the block-storage layer. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in us-east-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in us-east-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in us-west-1 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
EC2 account default EBS encryption is DISABLED in us-west-2 (GetEbsEncryptionByDefault=false). C1.1 preventive gap: volumes/instances launched without an explicit Encrypted=true are created UNENCRYPTED, even if all current volumes are encrypted. Enable account-wide default EBS encryption (ec2:EnableEbsEncryptionByDefault) per region.
Source: aws-ec2-instance-auditor
§164.312(a)(2)(iv) — account-default EBS encryption DISABLED means new volumes are created unencrypted; a forward-looking at-rest gap. At-rest fleet-sweep parity 2026-06-22. Plugin 1210.
ElastiCache Redis cache-cluster 'nw-session-cache' has at-rest encryption DISABLED (AtRestEncryptionEnabled=false). C1.1 confidentiality gap: cache data persisted to EBS snapshots + cross-region replication backups stored unencrypted; no crypto-shred capability. At-rest encryption cannot be enabled in-place — requires snapshot-restore-to-new-cluster with KmsKeyId set + DR window for data migration.
Source: aws-elasticache-redis-auditor
§164.312(a)(2)(iv) direct gap on cache layer. ElastiCache Redis with at-rest encryption disabled stores cached ePHI in cleartext.

164.312(b) — Audit Controls FAIL

Category: Technical Safeguards · Audit Controls · Violations: 68
Access logging not enabled – audit trail gap
Source: aws-s3-auditor
§164.312(b) S3-layer audit gap. S3 server access logging records per-request bucket access — required to evidence WHO accessed ePHI-bearing objects WHEN.
Access logging not enabled – audit trail gap
Source: aws-s3-auditor
§164.312(b) S3-layer audit gap. S3 server access logging records per-request bucket access — required to evidence WHO accessed ePHI-bearing objects WHEN.
Access logging not enabled – audit trail gap
Source: aws-s3-auditor
§164.312(b) S3-layer audit gap. S3 server access logging records per-request bucket access — required to evidence WHO accessed ePHI-bearing objects WHEN.
Access logging not enabled – audit trail gap
Source: aws-s3-auditor
§164.312(b) S3-layer audit gap. S3 server access logging records per-request bucket access — required to evidence WHO accessed ePHI-bearing objects WHEN.
Access logging not enabled – audit trail gap
Source: aws-s3-auditor
§164.312(b) S3-layer audit gap. S3 server access logging records per-request bucket access — required to evidence WHO accessed ePHI-bearing objects WHEN.
EE-RT.1.2 multi-region-enumeration-incomplete: cloudtrail:DescribeTrails errored in 2 region(s) (me-south-1: TimeoutError, me-central-1: TimeoutError). Single-region trails homed in those regions are UNAUDITED — CloudTrail-derived evidence is PARTIAL. Re-run for full multi-region evidence; persistent errors warrant a network/endpoint/region-enablement check. This is an evidence gap, NOT a control pass.
Source: aws-cloudtrail-auditor
164.312(b) -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.
Trail destination bucket northwind-orgtrail-logs has Object Lock enabled but NO DefaultRetention rule — the bucket is "Object-Lock-able" but no retention is auto-applied. Auditors expect a default retention rule on trail buckets.
Source: aws-cloudtrail-auditor
§164.312(b) audit-log preservation gap. CloudTrail destination bucket misconfiguration (deletion, missing lifecycle, missing encryption) breaks the audit-log evidence chain.
Trail destination bucket northwind-orgtrail-logs has MFA Delete NOT enabled. Without MFA Delete, any IAM principal with s3:DeleteBucket / s3:DeleteObject can permanently delete trail logs via delete-marker → permanent-delete bypass. For trail buckets (institutional-grade evidence storage), MFA Delete is mandatory.
Source: aws-cloudtrail-auditor
§164.312(b) audit-log preservation gap. CloudTrail destination bucket misconfiguration (deletion, missing lifecycle, missing encryption) breaks the audit-log evidence chain.
Trail northwind-orgtrail log files not encrypted with a KMS-CMK (KmsKeyId not set)
Source: aws-cloudtrail-auditor
§164.312(b) cross-references §164.312(a)(2)(iv). Audit logs themselves contain ePHI-access metadata; KMS-CMK encryption of trail destination ensures the audit record is also encrypted at-rest.
Trail destination bucket northwind-trail-logs has NO Object Lock configuration. SEC Rule 17a-4 / FINRA 4511 require WORM storage for audit logs. Enable Object Lock + COMPLIANCE mode + retention.
Source: aws-cloudtrail-auditor
§164.312(b) audit-log preservation gap. CloudTrail destination bucket misconfiguration (deletion, missing lifecycle, missing encryption) breaks the audit-log evidence chain.
Trail destination bucket northwind-trail-logs has Versioning Disabled — Object Lock REQUIRES Versioning. Without it, retention rules cannot be enforced.
Source: aws-cloudtrail-auditor
§164.312(b) audit-log preservation gap. CloudTrail destination bucket misconfiguration (deletion, missing lifecycle, missing encryption) breaks the audit-log evidence chain.
Trail northwind-trail is not multi-region (IsMultiRegionTrail=false)
Source: aws-cloudtrail-auditor
§164.312(b) coverage gap. Single-region CloudTrail trail misses API activity in other regions; HHS audit guidance expects complete activity record across all regions where ePHI-bearing resources may exist.
Trail northwind-trail has log file validation disabled (LogFileValidationEnabled=false)
Source: aws-cloudtrail-auditor
§164.312(b) cross-references §164.312(c)(1) integrity. Log-file-validation produces a digest file enabling tamper-detection on the audit log itself; disabled validation means audit-log integrity cannot be verified.
Trail northwind-trail log files not encrypted with a KMS-CMK (KmsKeyId not set)
Source: aws-cloudtrail-auditor
§164.312(b) cross-references §164.312(a)(2)(iv). Audit logs themselves contain ePHI-access metadata; KMS-CMK encryption of trail destination ensures the audit record is also encrypted at-rest.
Trail northwind-trail does not log data events (S3 object-level / Lambda invocation)
Source: aws-cloudtrail-auditor
§164.312(b) granularity gap. Management-event-only CloudTrail logs API control-plane (CreateBucket, DeleteTable) but not data-plane (GetObject, GetItem) — data-event logging is required to record actual ePHI access activity.
CloudWatch alarm missing: Unauthorized API calls (CIS AWS Foundations Benchmark cis-3.1). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Management Console sign-in without MFA (CIS AWS Foundations Benchmark cis-3.2). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Root account usage (CIS AWS Foundations Benchmark cis-3.3). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: IAM policy changes (CIS AWS Foundations Benchmark cis-3.4). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Management Console authentication failures (CIS AWS Foundations Benchmark cis-3.6). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Disabling or scheduled deletion of customer-created CMKs (CIS AWS Foundations Benchmark cis-3.7). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: S3 bucket policy changes (CIS AWS Foundations Benchmark cis-3.8). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: AWS Config configuration changes (CIS AWS Foundations Benchmark cis-3.9). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Security group changes (CIS AWS Foundations Benchmark cis-3.10). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Network ACL changes (CIS AWS Foundations Benchmark cis-3.11). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Network gateway changes (CIS AWS Foundations Benchmark cis-3.12). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: Route table changes (CIS AWS Foundations Benchmark cis-3.13). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
CloudWatch alarm missing: VPC changes (CIS AWS Foundations Benchmark cis-3.14). SOC 2 CC7.2 expects active monitoring for this event class; CC7.3 expects routing to incident response. Evidence method: metric-filter-pattern-v2 (auditor-canonical — direct logs:DescribeMetricFilters per CloudTrail LogGroup).
Source: aws-cloudtrail-auditor
§164.312(b) audit-monitoring gap. CloudWatch alarms on CloudTrail metrics (RootUsage, IAMChanges, UnauthorizedAPI) enable real-time detection of audit-relevant events; absence means audit anomalies go unflagged.
RDS DB instance 'northwind-orders-db' (postgres) has pgAudit DISABLED (pgaudit.log parameter is '<empty>'). CC7.2 + CC7.3 monitoring gap: no database-level activity log is captured — DDL changes, privileged role changes, and DML on sensitive tables go unaudited. Configure via DescribeDBParameterGroup + ModifyDBParameterGroup: set pgaudit.log to a comma-separated subset of 'ddl,role,write' (read can be added selectively for compliance tables) and add 'pgaudit' to shared_preload_libraries.
Source: aws-rds-auditor
§164.312(b) database-layer audit gap. pgAudit (PostgreSQL) provides session + object-level audit logging — required to record WHICH SQL queries touched ePHI-bearing tables.
RDS DB instance 'northwind-orders-db' (postgres) has NO CloudWatch Logs exports configured (EnabledCloudwatchLogsExports=[]). CC7.2 monitoring gap: no database activity logs reach CloudWatch for centralized anomaly detection / alerting / long-term retention. Expected for this engine: essential=[postgresql] + optional=[upgrade]. Configure via ModifyDBInstance --cloudwatch-logs-export-configuration.
Source: aws-rds-auditor
§164.312(b) audit-log preservation gap. RDS without CloudWatch Logs export means database audit logs remain on the local instance only — survive instance termination only via snapshot; should export to CloudWatch for long-term audit retention.
SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/nw-order-events' (queueName='nw-order-events') has NO CloudWatch MetricAlarm on AWS/SQS:ApproximateAgeOfOldestMessage with QueueName='nw-order-events'. CC7.2 system-monitoring + A1.2 availability gap: consumer backlog growth (failed processing, slow consumers, downstream outages) produces no operator paging — silent service-degradation class. Configure a MetricAlarm with Namespace=AWS/SQS, MetricName=ApproximateAgeOfOldestMessage, Dimensions=[{Name:QueueName,Value:'nw-order-events'}], a Threshold matching your SLO, ActionsEnabled=true, and an AlarmActions ARN routing to SNS / PagerDuty / etc.
Source: aws-sqs-sns-auditor
§164.312(b) audit-monitoring gap on message-bus health. Stuck SQS queues (oldest message age unbounded) indicate consumer failure — for ePHI-bearing pipelines, this signals stalled processing that auditors expect to be flagged.
SQS queue 'https://sqs.us-east-1.amazonaws.com/123456789012/sqs-encrypted-queue' (queueName='sqs-encrypted-queue') has NO CloudWatch MetricAlarm on AWS/SQS:ApproximateAgeOfOldestMessage with QueueName='sqs-encrypted-queue'. CC7.2 system-monitoring + A1.2 availability gap: consumer backlog growth (failed processing, slow consumers, downstream outages) produces no operator paging — silent service-degradation class. Configure a MetricAlarm with Namespace=AWS/SQS, MetricName=ApproximateAgeOfOldestMessage, Dimensions=[{Name:QueueName,Value:'sqs-encrypted-queue'}], a Threshold matching your SLO, ActionsEnabled=true, and an AlarmActions ARN routing to SNS / PagerDuty / etc.
Source: aws-sqs-sns-auditor
§164.312(b) audit-monitoring gap on message-bus health. Stuck SQS queues (oldest message age unbounded) indicate consumer failure — for ePHI-bearing pipelines, this signals stalled processing that auditors expect to be flagged.
SNS topic 'arn:aws:sns:us-east-1:123456789012:nw-notifications' (topicName='nw-notifications') has NO CloudWatch MetricAlarm on AWS/SNS:NumberOfNotificationsFailed with TopicName='nw-notifications'. CC7.2 + A1.2 gap: subscription delivery failures (HTTPS endpoint timeouts, Lambda invocation errors, SQS DLQ exhaustion on SNS→SQS fan-out, mobile push errors) produce NO operator paging — silent message-loss class for downstream subscribers. Configure a MetricAlarm with Namespace=AWS/SNS, MetricName=NumberOfNotificationsFailed, Dimensions=[{Name:TopicName,Value:'nw-notifications'}], a Threshold matching your error-rate SLO, ActionsEnabled=true, and routed AlarmActions.
Source: aws-sqs-sns-auditor
§164.312(b) audit-monitoring gap on notification health. Notification-delivery failures on ePHI-related alerting topics must be flagged — silent SNS failures defeat the audit-alerting purpose.
SNS topic 'arn:aws:sns:us-east-1:123456789012:sns-encrypted-topic' (topicName='sns-encrypted-topic') has NO CloudWatch MetricAlarm on AWS/SNS:NumberOfNotificationsFailed with TopicName='sns-encrypted-topic'. CC7.2 + A1.2 gap: subscription delivery failures (HTTPS endpoint timeouts, Lambda invocation errors, SQS DLQ exhaustion on SNS→SQS fan-out, mobile push errors) produce NO operator paging — silent message-loss class for downstream subscribers. Configure a MetricAlarm with Namespace=AWS/SNS, MetricName=NumberOfNotificationsFailed, Dimensions=[{Name:TopicName,Value:'sns-encrypted-topic'}], a Threshold matching your error-rate SLO, ActionsEnabled=true, and routed AlarmActions.
Source: aws-sqs-sns-auditor
§164.312(b) audit-monitoring gap on notification health. Notification-delivery failures on ePHI-related alerting topics must be flagged — silent SNS failures defeat the audit-alerting purpose.
AWS GuardDuty is NOT ENABLED in region 'ap-south-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-south-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'eu-north-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-north-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'eu-west-3' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-3') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'eu-west-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'eu-west-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-west-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ap-northeast-3' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-3') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ap-northeast-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ap-northeast-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-northeast-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ca-central-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ca-central-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'sa-east-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'sa-east-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ap-southeast-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-southeast-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'ap-southeast-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'ap-southeast-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'eu-central-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'eu-central-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'us-east-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-east-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'us-east-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-east-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'us-west-1' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-west-1') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.
AWS GuardDuty is NOT ENABLED in region 'us-west-2' (zero detectors returned by guardduty:ListDetectors). CC7.1 anomaly-detection substrate gap — the auditor has NO AWS-native threat-detection evidence stream for this region. GuardDuty would detect: account reconnaissance (suspicious console/API patterns), credential exfiltration (anomalous AssumeRole / GetSessionToken), cryptocurrency mining (anomalous CPU + outbound traffic patterns), malicious-IP communication (threat-intel CIDR matches), known-bad domain resolution, etc. Enable via guardduty:CreateDetector.
Source: aws-inspector-guardduty-auditor
§164.312(b) cross-references §164.308(a)(1)(ii)(D) (Information System Activity Review, OOS-Admin but technically substrated here). GuardDuty provides threat-detection telemetry on AWS account activity — disabled in a region means no automated detection of attacker-pattern activity on ePHI-bearing resources in that region.
EE-RT.1.2 multi-region-enumeration-incomplete: Inspector2 (region 'us-west-2') — BatchGetAccountStatus returned no account-status body. Conservative classifier emits LOW + evidenceGap. Auditor walkthrough required.
Source: aws-inspector-guardduty-auditor
164.312(b) evidence-gap LOW (class-O, EE 0.19.4 Phase R2). aws-inspector-guardduty-auditor emits multi-region / coverage evidence-gaps (Inspector2 BatchGetAccountStatus null-or-unknown-status, GuardDuty GetDetector / FindingPublishingFrequency unverifiable, alerting-destination incomplete, per-account failure / AccessDenied) that now lead with the shared MULTI_REGION_GAP_PREFIX and fail-close EXACTLY this source's native attested set rather than routing to zero controls (the pre-R2 class-O false-clean the 0.19.3 Desktop validation found on plugin 1200). Remediate: grant the missing read permission or resolve the unverifiable signal and re-run.

164.312(c)(1) — Integrity FAIL

Category: Technical Safeguards · Integrity · Violations: 11
⚠️ Coverage caveat: Infrastructure scanning evidences the STORAGE-SUBSTRATE integrity dimension (backup-vault immutability, PITR, replication, snapshot retention, KMS-grants integrity on backup keys, GCS retention policies) but cannot evidence APPLICATION-LAYER integrity (per-record checksumming, tamper-detection on database rows, ePHI-payload integrity verification at access time). Full §164.312(c)(1) coverage requires (a) NSAuditor substrate evidence (this layer) AND (b) application-side data-integrity attestations from the ePHI system of record. The ransomware-defense angle (immutable backup vaults, logically air-gapped storage) is the highest-value HHS-auditor-relevant evidence in this control.
Versioning is disabled – data recovery at risk
Source: aws-s3-auditor
§164.312(c)(1) integrity-via-versioning gap. S3 versioning disabled means object overwrites/deletes are irreversible — no recovery path from improper alteration or destruction of ePHI-bearing objects.
Object Lock not configured
Source: aws-s3-auditor
§164.312(c)(1) integrity-via-immutability gap. S3 Object Lock provides WORM (Write-Once-Read-Many) protection — required substrate for ransomware-resistant ePHI storage.
Versioning is disabled – data recovery at risk
Source: aws-s3-auditor
§164.312(c)(1) integrity-via-versioning gap. S3 versioning disabled means object overwrites/deletes are irreversible — no recovery path from improper alteration or destruction of ePHI-bearing objects.
Object Lock not configured
Source: aws-s3-auditor
§164.312(c)(1) integrity-via-immutability gap. S3 Object Lock provides WORM (Write-Once-Read-Many) protection — required substrate for ransomware-resistant ePHI storage.
Object Lock not configured
Source: aws-s3-auditor
§164.312(c)(1) integrity-via-immutability gap. S3 Object Lock provides WORM (Write-Once-Read-Many) protection — required substrate for ransomware-resistant ePHI storage.
RDS DB instance 'northwind-analytics-cluster' has BackupRetentionPeriod=1 days, below the institutional baseline of 7 days. A1.2 availability partial-gap: a recovery event older than 1 days cannot be restored via PITR. Raise to ≥7 days via rds:ModifyDBInstance --backup-retention-period.
Source: aws-rds-auditor
§164.312(c)(1) RDS backup-retention gap. BackupRetentionPeriod below institutional baseline reduces the recovery-window on ePHI-bearing DB.
RDS DB instance 'northwind-orders-db' is configured single-AZ (MultiAZ=false). A1.2 availability gap: an AZ outage, instance failure, or maintenance event would render the database unavailable until manual recovery. Enable Multi-AZ via rds:ModifyDBInstance for production-tier workloads.
Source: aws-rds-auditor
§164.312(c)(1) cross-references availability dimension. Single-AZ RDS configuration means AZ-level failure causes data unavailability; for ePHI-bearing systems, Multi-AZ provides automated failover preserving integrity-of-access.
RDS DB instance 'northwind-orders-db' has BackupRetentionPeriod=0 — automated backups are DISABLED. A1.2 availability gap: PITR is unavailable (requires automated backups), no recovery from corruption / accidental-DROP / insider-vandalism. Enable via rds:ModifyDBInstance --backup-retention-period <days>; institutional baseline is 7 days.
Source: aws-rds-auditor
§164.312(c)(1) RDS integrity gap. BackupRetentionPeriod=0 disables automated backups — ePHI-bearing DB has no point-in-time-recovery capability; data loss from corruption or attack is irreversible.
ElastiCache Redis replication-group 'nw-product-cache' has SnapshotRetentionLimit=0 — automatic snapshots are DISABLED. A1.2 availability gap: data is unrecoverable from cluster failure / accidental FLUSHALL / insider-vandalism. Set via ModifyReplicationGroup --snapshot-retention-limit <days>; institutional baseline is 7 days. AWS ElastiCache Redis max is 35 days.
Source: aws-elasticache-redis-auditor
§164.312(c)(1) ElastiCache integrity gap. SnapshotRetentionLimit=0 means no automated snapshots — cached ePHI cannot be recovered from corruption or accidental deletion.
ElastiCache Redis cache-cluster 'nw-session-cache' has SnapshotRetentionLimit=0 — automatic snapshots are DISABLED. A1.2 availability gap: data is unrecoverable from cluster failure / accidental FLUSHALL / insider-vandalism. Set via ModifyReplicationGroup --snapshot-retention-limit <days>; institutional baseline is 7 days. AWS ElastiCache Redis max is 35 days.
Source: aws-elasticache-redis-auditor
§164.312(c)(1) ElastiCache integrity gap. SnapshotRetentionLimit=0 means no automated snapshots — cached ePHI cannot be recovered from corruption or accidental deletion.
AWS Backup account audit: ZERO Restore Testing Plans configured. A1.2 disaster-recovery validation gap: NO periodic test-restores are scheduled against the AWS Backup substrate. Per SEC Rule 17a-4 / FINRA 4511 audit-the-restorer doctrine, recovery points without periodic test-restores are unverifiable evidence — backups may exist but operators cannot prove they CAN be restored. Configure at least one Restore Testing Plan covering production-tier recovery points. Auditor walkthrough required if DR is validated via external runbook.
Source: aws-backup-auditor
§164.312(c)(1) backup-verification gap. No Restore Testing Plans means backup-integrity is untested — backup-policy may exist but no evidence that ePHI can actually be recovered.

164.312(c)(2) — Mechanism to Authenticate Electronic Protected Health Information FAIL

Category: Technical Safeguards · Integrity · Implementation Specification · Violations: 5
⚠️ Coverage caveat: Infrastructure scanning provides backup-INTEGRITY-VERIFICATION substrate (Logically Air-Gapped Vault cryptographic-isolation cross-verification, KMS-grants integrity, vault-lock immutability) which corroborates that backup-resident ePHI has not been altered. However, application-layer checksumming / digital signatures on individual ePHI records remains OOS — HIPAA §164.312(c)(2) is an Addressable specification that benefits from application-side integrity attestations beyond what infrastructure scanning can produce. Pair with EHR-system-level integrity attestations for full coverage.
MFA Delete not enabled
Source: aws-s3-auditor
§164.312(c)(2) cross-references §164.312(d) authentication for destruction. S3 MFA Delete requires MFA authentication for object version deletion — without it, unauthorized deletion of versioned ePHI objects cannot be cryptographically prevented by the access layer.
MFA Delete not enabled
Source: aws-s3-auditor
§164.312(c)(2) cross-references §164.312(d) authentication for destruction. S3 MFA Delete requires MFA authentication for object version deletion — without it, unauthorized deletion of versioned ePHI objects cannot be cryptographically prevented by the access layer.
MFA Delete not enabled
Source: aws-s3-auditor
§164.312(c)(2) cross-references §164.312(d) authentication for destruction. S3 MFA Delete requires MFA authentication for object version deletion — without it, unauthorized deletion of versioned ePHI objects cannot be cryptographically prevented by the access layer.
EE-RT.1.2 multi-region-enumeration-incomplete: cloudtrail:DescribeTrails errored in 2 region(s) (me-south-1: TimeoutError, me-central-1: TimeoutError). Single-region trails homed in those regions are UNAUDITED — CloudTrail-derived evidence is PARTIAL. Re-run for full multi-region evidence; persistent errors warrant a network/endpoint/region-enablement check. This is an evidence gap, NOT a control pass.
Source: aws-cloudtrail-auditor
164.312(c)(2) -- CloudTrail/CloudWatch evidence is INCOMPLETE: plugin 1040 aborted at its soft budget (scan-time-budget-exceeded) before finishing the audit, so this control's CloudTrail-derived evidence was not collected. Fails-closed (no silent PASS over an un-audited control surface) per the conservative-classifier principle and consistent with the 1020/1021/1025 evidence-gap convention. Resolve by raising CLOUD_PLUGIN_TIMEOUT_MS / NSA_CT_SOFT_BUDGET_MS or scoping to a single region (NSA_CT_MAX_REGIONS / multiRegionScan=false), then re-run. EE 0.16.5 false-clean fix.
Trail northwind-trail has log file validation disabled (LogFileValidationEnabled=false)
Source: aws-cloudtrail-auditor
§164.312(c)(2) integrity verification on the audit log itself. CloudTrail log-file-validation produces a digest enabling tamper-detection on the audit log — required to corroborate that recorded ePHI access activity has not been altered.

164.312(d) — Person or Entity Authentication FAIL

Category: Technical Safeguards · Person or Entity Authentication · Violations: 5
No MFA configured on active IAM user
Source: aws-iam-deep-auditor
§164.312(d) requires authentication procedures verifying identity. Single-factor authentication (password only) cannot verify identity to HHS-expected standard for ePHI-access-bearing AWS IAM users — MFA is the contemporary baseline for person-authentication on ePHI access.
No MFA configured on active IAM user
Source: aws-iam-deep-auditor
§164.312(d) requires authentication procedures verifying identity. Single-factor authentication (password only) cannot verify identity to HHS-expected standard for ePHI-access-bearing AWS IAM users — MFA is the contemporary baseline for person-authentication on ePHI access.
Secrets Manager secret 'nw-db-credentials' has rotation DISABLED. Long-lived credentials accumulate compromise risk over time; AWS-recommended baseline is enabled rotation with a Lambda rotation function. CC6.1 access-control boundary risk on the credential layer (the credential is the access boundary; without rotation it becomes a single-point-of-failure if leaked). Enable rotation via secretsmanager:RotateSecret + AWSCURRENT/AWSPENDING staging labels.
Source: aws-secrets-auditor
§164.312(d) credential-lifecycle authentication boundary. Long-lived secrets without rotation cannot be cryptographically expired; leaked credentials remain valid indefinitely, defeating the entity-authentication freshness invariant on ePHI access paths.
ElastiCache Redis replication-group 'nw-product-cache' has NO authentication configured (AuthTokenEnabled=false AND no IAM-auth user groups). CC6.1 / CC6.2 authentication gap: the cluster relies SOLELY on network-perimeter security (Security Groups) for access control. Any principal reachable on TCP 6379 can issue arbitrary Redis commands — cross-plugin sister of plugin 1170 SG-perimeter audit. Enable Redis AUTH (minimum) OR Redis ACL user groups with IAM auth (institutional-grade).
Source: aws-elasticache-redis-auditor
§164.312(d) authentication-absent gap. ElastiCache Redis with no authentication relies SOLELY on Security Group perimeter for access — defeats the entity-authentication requirement entirely on ePHI cache.
ElastiCache Redis cache-cluster 'nw-session-cache' has NO authentication configured (AuthTokenEnabled=false AND no IAM-auth user groups). CC6.1 / CC6.2 authentication gap: the cluster relies SOLELY on network-perimeter security (Security Groups) for access control. Any principal reachable on TCP 6379 can issue arbitrary Redis commands — cross-plugin sister of plugin 1170 SG-perimeter audit. Enable Redis AUTH (minimum) OR Redis ACL user groups with IAM auth (institutional-grade).
Source: aws-elasticache-redis-auditor
§164.312(d) authentication-absent gap. ElastiCache Redis with no authentication relies SOLELY on Security Group perimeter for access — defeats the entity-authentication requirement entirely on ePHI cache.

164.312(e)(1) — Transmission Security FAIL

Category: Technical Safeguards · Transmission Security · Violations: 1
ElastiCache Redis cache-cluster 'nw-session-cache' has transit encryption DISABLED (TransitEncryptionEnabled=false). C1.1 transit-encryption gap: client connections + inter-node replication flow over the network in cleartext. Redis client credentials (AUTH tokens) AND cache contents transit unprotected. Enable via in-place migration (Redis 7+ supports TransitEncryptionMode='preferred' for zero-downtime rollout); older engines require recreate-with-encryption + data migration.
Source: aws-elasticache-redis-auditor
§164.312(e)(1) cache-transit gap. ElastiCache Redis without transit encryption transmits cached ePHI in cleartext between application and cache.

164.312(e)(2)(i) — Integrity Controls (Transmission) FAIL

Category: Technical Safeguards · Transmission Security · Implementation Specification · Violations: 1
⚠️ Coverage caveat: Infrastructure scanning evidences the TLS-transit-substrate integrity (TLS provides MAC-based integrity protection on each packet via the chosen cipher suite); without TLS, transit integrity is structurally absent. However, application-layer transit-integrity controls (HMAC on per-record payloads, digital signatures on ePHI documents) remain OOS for infrastructure scanning. Full coverage requires application-side payload-integrity mechanisms.
ElastiCache Redis cache-cluster 'nw-session-cache' has transit encryption DISABLED (TransitEncryptionEnabled=false). C1.1 transit-encryption gap: client connections + inter-node replication flow over the network in cleartext. Redis client credentials (AUTH tokens) AND cache contents transit unprotected. Enable via in-place migration (Redis 7+ supports TransitEncryptionMode='preferred' for zero-downtime rollout); older engines require recreate-with-encryption + data migration.
Source: aws-elasticache-redis-auditor
§164.312(e)(2)(i) cache-transit-integrity absent. ElastiCache without transit encryption transmits cached ePHI with no TLS-layer integrity protection.

164.312(e)(2)(ii) — Encryption (Transmission) FAIL

Category: Technical Safeguards · Transmission Security · Implementation Specification · Violations: 1
ElastiCache Redis cache-cluster 'nw-session-cache' has transit encryption DISABLED (TransitEncryptionEnabled=false). C1.1 transit-encryption gap: client connections + inter-node replication flow over the network in cleartext. Redis client credentials (AUTH tokens) AND cache contents transit unprotected. Enable via in-place migration (Redis 7+ supports TransitEncryptionMode='preferred' for zero-downtime rollout); older engines require recreate-with-encryption + data migration.
Source: aws-elasticache-redis-auditor
§164.312(e)(2)(ii) cache-transit encryption gap. ElastiCache without transit encryption transmits cached ePHI in cleartext.

Passing Controls (Within Scope)

Partial Coverage

No in-scope partial controls (or all partial controls have findings — see Failing Controls with coverage caveats).

Out of Scope

Control IDsTitleReason
164.312(a)(2)(ii), 164.312(a)(2)(iii)§164.312 Technical Safeguards — OOS Implementation Specifications§164.312(a)(2)(ii) Emergency Access Procedure (Required) is a procedural break-glass-runbook control — defines how authorized workforce members obtain ePHI access in emergencies. Not addressable by infrastructure scanning; pair with documented break-glass procedure + workforce training records. §164.312(a)(2)(iii) Automatic Logoff (Addressable) is a session-timeout configuration that lives at the application or operating-system tier, not at the cloud-infrastructure tier; not addressable by API-based infrastructure scanning.
164.308(a)(1)(i), 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(1)(ii)(C), 164.308(a)(1)(ii)(D), 164.308(a)(2), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(3)(ii)(C), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(i), 164.308(a)(5)(ii)(A), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(5)(ii)(D), 164.308(a)(6)(i), 164.308(a)(6)(ii), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.308(a)(7)(ii)(B), 164.308(a)(7)(ii)(C), 164.308(a)(7)(ii)(D), 164.308(a)(7)(ii)(E), 164.308(a)(8), 164.308(b)(1), 164.308(b)(2), 164.308(b)(3)§164.308 Administrative Safeguards (entire)Administrative Safeguards cover the human-process and governance dimensions of the HIPAA Security Rule: Security Management Process (risk analysis, risk management, sanction policy, information-system activity review), Assigned Security Responsibility, Workforce Security (authorization/supervision, clearance procedures, termination procedures), Information Access Management (access authorization, access establishment and modification), Security Awareness and Training (security reminders, malicious-software protection, log-in monitoring, password management), Security Incident Procedures, Contingency Plan (data backup plan, disaster recovery plan, emergency mode operation plan, testing/revision, criticality analysis), Evaluation, and Business Associate Contracts. These are governance, training, contractual, and policy-cycle evidence streams — they require HR systems, signed policies, training records, formal risk-register documents, and BAA legal records, none of which infrastructure scanning can produce. Pair NSAuditor with a HIPAA-focused GRC platform (Drata HIPAA, Vanta HIPAA, Compliancy Group, Tugboat Logic) for §164.308 coverage. Note: §164.312 technical-safeguard substrate evidence DOES inform §164.308(a)(1)(ii)(D) Information System Activity Review (the technical substrate FOR the activity review) and §164.308(a)(7)(ii)(A) Data Backup Plan (the technical substrate FOR the backup plan), but the formal administrative-process documentation itself is OOS.
164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(a)(2)(iv), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(i), 164.310(d)(2)(ii), 164.310(d)(2)(iii), 164.310(d)(2)(iv)§164.310 Physical Safeguards (entire)Physical Safeguards cover the physical-asset and facility dimensions of the HIPAA Security Rule: Facility Access Controls (contingency operations, facility security plan, access control and validation procedures, maintenance records), Workstation Use, Workstation Security, and Device and Media Controls (disposal, media re-use, accountability, data backup and storage). These are physical-asset evidence streams — they require building access logs, badge systems, workstation-inventory + endpoint-management records, hardware-disposal certificates (e.g., NAID-certified destruction), and physical chain-of-custody documentation, none of which infrastructure scanning can produce. Pair NSAuditor with facilities-management + endpoint-management + asset-disposal vendors for §164.310 coverage. The infrastructure-layer KMS-key-disposal substrate (Vault Lock, Key Vault purge protection, multi-region key controls) is mapped under §164.312(a)(2)(iv) Encryption/Decryption — the technical-safeguard counterpart to §164.310(d) media-disposal controls.

Appendix A — Cloud Bucket Exposure Attestation

Buckets with finding(s): 20 violation event(s) across 0 unique bucket(s).

Per-bucket detail in JSON sidecar — report.controls[].violations filtered by source IN ["aws-s3-auditor", "gcp-cloud-storage-auditor", "azure-storage-auditor"].

Appendix B — Accepted Risks & False Positives

No suppressions in this scan.

Report integrity: see companion .sha256 sidecar — verify with shasum -a 256 -c <file>.sha256