AWS Audit Manager — HIPAA Compliance Runbook

Owner: Infrastructure (Rory) Cadence: Weekly check, monthly review, quarterly evidence pull Estimated time: 30 min weekly / 2 hr quarterly

Overview

This runbook covers HIPAA evidence collection and compliance operations across the Cirius AWS org. The two primary compliance tools are AWS Security Hub (NIST 800-53 R5, org-wide findings) and AWS Audit Manager (HIPAA Omnibus Jan 2013 framework, evidence collection for audit). These tools do not overlap in purpose — Security Hub is the day-to-day posture and alerting surface; Audit Manager is the audit evidence store.

A critical distinction: AWS Security Hub has no native HIPAA standard. Security Hub runs NIST 800-53 R5 org-wide. The HIPAA evidence framework lives in Audit Manager. Do not look for a HIPAA standard in Security Hub — it does not exist.

1. Architecture Overview

How the Tools Fit Together

CloudTrail org trail (Logging account 038901680748)
    │
    ├─→ S3 bucket (cirius-cloudtrail-org, Logging account) — raw event archive
    │       └─→ Arctic Wolf connector reads this bucket for the LAW
    │
    ├─→ Security Hub (delegated admin: Logging account 038901680748)
    │       ├─ Aggregates findings from all 7 member accounts
    │       ├─ NIST 800-53 R5 standard enabled org-wide
    │       ├─ Ingests GuardDuty findings (normalized)
    │       └─→ Arctic Wolf connector reads Security Hub findings
    │
    └─→ Audit Manager (delegated admin: Logging account 038901680748)
            ├─ HIPAA Omnibus Jan 2013 framework
            ├─ Pulls evidence from Config, CloudTrail, Security Hub
            └─ Stores evidence in S3 (Audit Manager evidence bucket)

AWS Config (enabled per account, org-wide aggregator in Management 206820231356)
    ├─→ Config snapshots → Audit Manager evidence
    └─→ Security Hub conformance (Config rules back Security Hub controls)

GuardDuty (delegated admin: Logging account 038901680748)
    ├─ Org-wide threat detection
    ├─→ Findings published to Security Hub (normalized)
    └─→ Arctic Wolf AWS connector reads GuardDuty findings directly

Delegated Admin Summary

Service	Delegated Admin Account	Account ID
Security Hub	Logging	038901680748
Audit Manager	Logging	038901680748
GuardDuty	Logging	038901680748
Config Aggregator	Management	206820231356
CloudTrail (org trail)	Logging	038901680748

All compliance-focused console work happens in the Logging account (038901680748) unless stated otherwise. This is where the aggregated views live.

Account Reference

Account	ID	Purpose
Management	206820231356	Org root, billing, Config aggregator
Backup	863609217450	Veeam backup targets, S3 WORM archive
Dev	040067931468	Development (minimal compliance footprint)
Identity	414134953818	IAM Identity Center, identity services
Logging	038901680748	CloudTrail, Security Hub, Audit Manager, GuardDuty — all delegated admin
Networking	238342914131	Palo Alto firewall infrastructure
Prod	807267566999	DR workloads, Cloud PC

How Findings Flow

AWS Config evaluates resource configurations in each member account continuously
Config rules fire → findings appear in Security Hub as NIST 800-53 R5 checks
GuardDuty detects threats in each member account → publishes findings to Security Hub
Security Hub aggregates all findings into the Logging account delegated admin view
Audit Manager queries CloudTrail, Config, and Security Hub periodically to collect evidence against HIPAA controls
Arctic Wolf's AWS connector reads CloudTrail (from S3), GuardDuty, and Security Hub from the Logging account, forwarding telemetry to the Arctic Wolf cloud and into cirius-logging-law-central via the Arctic Wolf connector

2. Access — Getting Into the Logging Account

All compliance operations run in the Logging account unless you need to investigate a specific member account directly.

Portal: https://d-9267898861.awsapps.com/start
Federated through: ciriusgroup.com (Entra / Microsoft SSO)
Permission set: AdministratorAccess
Account: Logging (038901680748)

Go to https://d-9267898861.awsapps.com/start
Log in with your ciriusgroup.com Microsoft account
Select Logging (038901680748) → Management console
Confirm region is us-west-2 (Oregon) — all compliance services are in this region

CLI Access

bash

# Authenticate (covers all profiles for 8 hours)
aws sso login --profile logging

# Verify you're in the right account
aws sts get-caller-identity --profile logging
# Should return: Account: 038901680748

# Switch to the management account for Config aggregator work
aws sts get-caller-identity --profile main
# Should return: Account: 206820231356

See AWS Account Access Guide for full profile setup.

3. Security Hub Operations

Accessing the Aggregated View

In the Logging account console:

AWS Console → Security Hub → Summary

This shows the aggregated posture across all 7 accounts. The default landing page shows the NIST 800-53 R5 compliance score and a breakdown of findings by severity.

To see member account breakdown:

Security Hub → Settings → Accounts

All 7 accounts should show Enabled and Invitation accepted status. If any account shows a different state, Security Hub is not getting findings from it.

NIST 800-53 R5 Findings

The NIST 800-53 R5 standard maps AWS-native controls (S3 encryption, MFA, logging, IAM) to the NIST 800-53 Rev 5 control catalog. This is the standard you use for day-to-day posture management and the one that generates most of the automated evidence collected by Audit Manager.

Severity scores in Security Hub are normalized on a 0–100 scale:

Severity Label	Score Range	What It Means
CRITICAL	90–100	Actively exploitable or immediately required by compliance
HIGH	70–89	Significant control gap, remediate within 5 business days
MEDIUM	40–69	Control weakness, remediate within 30 days
LOW	1–39	Minor gap, track and address in scheduled maintenance
INFORMATIONAL	0	Context only, no action required

Critical findings at Cirius require Rory's attention before the next business day. Do not leave CRITICAL findings open longer than 48 hours without a documented remediation plan or suppression justification.

Finding Lifecycle

Security Hub findings move through these workflow states:

NEW → NOTIFIED (optional) → RESOLVED
NEW → SUPPRESSED

NEW: Freshly generated, no action taken yet
NOTIFIED: Finding has been communicated to a stakeholder (optional use)
RESOLVED: Underlying issue is fixed — Security Hub will auto-set this when the Config rule passes on the next evaluation cycle
SUPPRESSED: Finding is acknowledged and intentionally not being remediated (requires documented justification — see suppression policy below)

Security Hub does NOT use the word "ACKNOWLEDGED" as a workflow state. Use WorkflowStatus in the API/CLI, not RecordState (which is a different field controlling whether the finding is archived entirely).

Suppressing a Finding

Suppression means you are telling Security Hub: "I have reviewed this finding and I am accepting the risk or have a compensating control." It does NOT fix the issue. Reserve suppression for cases where remediation is impossible, decommission is imminent, or a documented compensating control satisfies the underlying HIPAA requirement.

Suppression policy:

Never suppress without Rory's approval
Always document the justification in the Note field when suppressing
Never use suppression as a placeholder while waiting to fix something — that is what the finding lifecycle (OPEN/NOTIFIED) is for
Reviewed quarterly — suppressed findings must be re-evaluated

Suppressing via console:

Security Hub → Findings → select finding(s)
  → Actions → Suppress
  → Add a note explaining why (required — do not leave blank)

Suppressing via CLI:

bash

# Suppress a finding and add a justification note
aws securityhub batch-update-findings \
  --profile logging \
  --region us-west-2 \
  --finding-identifiers '[{"Id":"<finding-id>","ProductArn":"<product-arn>"}]' \
  --workflow '{"Status":"SUPPRESSED"}' \
  --note '{"Text":"Compensating control: <describe control>. Approved by Rory <date>.","UpdatedBy":"kobe"}'

To get the finding ID and product ARN for a specific finding, drill into it in the console or use:

bash

aws securityhub get-findings \
  --profile logging \
  --region us-west-2 \
  --filters '{"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --query 'Findings[].{Id:Id,ProductArn:ProductArn,Title:Title,Severity:Severity.Label}' \
  --output table

Remediating Common NIST 800-53 Findings

S3 bucket public access blocked

This fires when a bucket does not have the S3 Block Public Access setting enforced. All Cirius S3 buckets should have public access blocked at the account level.

bash

# Check account-level block (run per account)
aws s3control get-public-access-block \
  --account-id <account-id> \
  --profile <profile>

# Enable account-level block (fixes all buckets in the account)
aws s3control put-public-access-block \
  --account-id <account-id> \
  --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true \
  --profile <profile>

Fix in Terraform (aws-infra) — the vpc-spoke and storage modules should enforce this. If the finding reappears after a plan+apply, the resource is outside Terraform management.

Unencrypted EBS volumes

bash

# List unencrypted volumes per account
aws ec2 describe-volumes \
  --profile <profile> \
  --region us-west-2 \
  --filters Name=encrypted,Values=false \
  --query 'Volumes[].{VolumeId:VolumeId,State:State,InstanceId:Attachments[0].InstanceId}' \
  --output table

Remediation: stop the instance, create an encrypted snapshot, create a new encrypted volume from the snapshot, detach the old volume, attach the new one. This requires a maintenance window — coordinate with Rory. Fix the Terraform module to default encrypted = true so future volumes are compliant at creation.

MFA not enabled on root user

This cannot be fixed via CLI — root MFA is a manual console operation.

Log in to the AWS console as root (credentials in Keeper → "AWS Root — [Account Name]")
Physical MFA token is required (kept in the office)
Root → Security credentials → Multi-factor authentication → Assign MFA device

If MFA is missing from a root account, this is a CRITICAL HIPAA gap (§164.312(d)). Remediate immediately and document the fix in the quarterly evidence package.

CloudTrail not enabled

This should not fire if the org trail is healthy. If it does:

bash

# Verify the org trail status
aws cloudtrail describe-trails \
  --profile logging \
  --region us-west-2 \
  --include-shadow-trails true \
  --query 'trailList[?IsOrganizationTrail==`true`].{Name:Name,S3:S3BucketName,MultiRegion:IsMultiRegionTrail,LogValidation:LogFileValidationEnabled}'

If the org trail is healthy and the finding persists, it may be a regional trail gap (the finding checks all regions, not just us-west-2). Investigate which region triggered the finding before creating a new trail.

How Security Hub Findings Reach Arctic Wolf and the LAW

Arctic Wolf's AWS connector reads Security Hub findings from the Logging account (038901680748) via the securityhub:GetFindings API. There is no additional configuration required on our side — the connector IAM role has this permission.

The connector also reads the CloudTrail org trail S3 bucket directly and GuardDuty findings. All of this telemetry is forwarded to the Arctic Wolf cloud platform, which routes relevant events into cirius-logging-law-central via the Arctic Wolf LAW connector.

This means Security Hub findings appear in the LAW under the Arctic Wolf ingestion pipeline, not as direct AWS findings. To query them in KQL:

kql

// Security Hub findings via Arctic Wolf (check table name with AW Concierge if this doesn't return results)
CommonSecurityLog
| where DeviceVendor == "Amazon Web Services"
| where DeviceProduct == "Security Hub"
| where TimeGenerated > ago(7d)
| sort by TimeGenerated desc

See Arctic Wolf AWS Connector for full connector verification steps.

4. Audit Manager — HIPAA Framework

What Audit Manager Does

Audit Manager continuously collects evidence against the controls in the HIPAA Omnibus Jan 2013 framework. Evidence comes from three sources:

AWS Config — configuration snapshots proving resources are configured correctly
CloudTrail — API call records proving access controls and change management are operating
Security Hub — compliance check results proving controls are being evaluated

Audit Manager does not do threat detection or alerting. It is purely an evidence store for audit purposes. When a HIPAA auditor asks "show me evidence that access to PHI-adjacent systems is logged," you pull the Audit Manager assessment report.

Navigating to the HIPAA Assessment

In the Logging account console (038901680748):

AWS Console → Audit Manager → Assessments

The HIPAA Omnibus Jan 2013 assessment should appear in the list. If you see an empty list, either:

You are in the wrong account (must be Logging — 038901680748)
You are in the wrong region (must be us-west-2)
The assessment has not been created — see note below on initial setup

Click the assessment name to open it. The default view shows:

Assessment overview — framework version, scope, delegated admin account
Controls — top-level HIPAA control categories (Administrative Safeguards, Physical Safeguards, Technical Safeguards, Organizational Requirements, Documentation)
Evidence folders — per-control evidence collected to date

Assessment Structure

HIPAA Omnibus Jan 2013 Assessment
  └─ Control Sets (maps to HIPAA §164 sections)
       ├─ Administrative Safeguards (§164.308)
       │    ├─ Control: Risk Analysis
       │    │    └─ Requirements: security risk assessment performed and documented
       │    │         └─ Evidence folders (auto-collected: Config, CloudTrail, SecHub)
       │    └─ Control: Workforce Training (manual evidence required)
       ├─ Technical Safeguards (§164.312)
       │    ├─ Control: Access Control
       │    ├─ Control: Audit Controls
       │    ├─ Control: Integrity
       │    └─ Control: Transmission Security
       └─ Organizational Requirements
            └─ Control: Business Associate Contracts (manual evidence)

Automatically Collected Evidence

Audit Manager pulls evidence automatically on a schedule (daily for most controls). You do not trigger this manually. Each evidence item shows:

Evidence type — AWS API call, Config snapshot, or Security Hub finding
Assessment date — when the evidence was collected
Compliance check result — PASS or FAIL at the time of collection
Resource — the specific AWS resource the evidence covers

To see evidence for a specific control:

Audit Manager → Assessments → [assessment name] → Controls
  → Click a control (e.g., "Audit Controls")
  → Evidence folders tab
  → Click an evidence folder → Review evidence items

Adding Manual Evidence

Some HIPAA controls cannot be satisfied by automated AWS evidence. Examples:

Workforce training records
BAA/vendor contract documents
Risk assessment documents (the Security Hub posture score is supporting evidence, not a substitute for a documented risk analysis)
Policy documents (e.g., Acceptable Use Policy, Incident Response Plan)

These are the documents Adriana uploads to SharePoint. To attach them in Audit Manager:

Export the document from SharePoint as PDF
Navigate to the specific control in Audit Manager
Click the control → Evidence folders tab → Add manual evidence
Upload the PDF
Add a comment describing what the document is and the date range it covers
Click Upload

File naming convention for manual evidence:

<hipaa-section>-<control-short-name>-<YYYY-QQ>.pdf

Examples:
  164308a1-risk-assessment-2026-Q2.pdf
  164308a5-workforce-training-roster-2026-Q2.pdf
  164314a1-baa-vendor-register-2026-Q2.pdf

Assessment Report Generation

Generate a report at the end of each quarter before handing off to Adriana.

Via console:

Audit Manager → Assessments → [assessment name]
  → Assessment reports tab → Create assessment report
  → Report name: cirius-hipaa-<YYYY>-Q<N>
  → Destination: [the configured S3 evidence bucket]
  → Create

The report generates as a PDF. It may take 5–15 minutes. When complete, it appears in the Assessment reports tab and is also written to the S3 evidence bucket.

Via CLI:

bash

# Get the assessment ID first
aws auditmanager list-assessments \
  --profile logging \
  --region us-west-2 \
  --query 'assessmentMetadata[].{Id:id,Name:name,Status:status}' \
  --output table

# Generate the report
aws auditmanager create-assessment-report \
  --profile logging \
  --region us-west-2 \
  --name "cirius-hipaa-2026-Q2" \
  --assessment-id <assessment-id>

Where the PDF is stored:

The Audit Manager assessment is configured to write reports to an S3 bucket in the Logging account. The bucket name follows the pattern cirius-auditmanager-evidence-<suffix>. Confirm the exact bucket name:

bash

aws auditmanager get-assessment \
  --profile logging \
  --region us-west-2 \
  --assessment-id <assessment-id> \
  --query 'assessment.metadata.assessmentReportsDestination'

Download the PDF after generation:

bash

aws s3 cp \
  s3://<auditmanager-evidence-bucket>/assessment-reports/cirius-hipaa-2026-Q2.pdf \
  ~/Downloads/cirius-hipaa-2026-Q2.pdf \
  --profile logging

Hand the PDF to Adriana for SharePoint upload:

SharePoint → Compliance → AWS HIPAA Evidence → <YYYY>-Q<N> → cirius-hipaa-<YYYY>-Q<N>.pdf

5. Evidence Collection Workflow — Quarterly Pull

Run at the end of Q1 (March), Q2 (June), Q3 (September), Q4 (December). Estimated time: 2 hours end-to-end.

Step 1 — Generate the Security Hub Compliance Report

Security Hub's compliance posture at quarter-end documents that NIST 800-53 R5 controls were being evaluated and their pass/fail state.

bash

# Pull a summary of Security Hub findings for the quarter
aws securityhub get-findings \
  --profile logging \
  --region us-west-2 \
  --filters '{
    "UpdatedAt": [{"Start":"<YYYY-MM-01T00:00:00Z>","End":"<YYYY-MM-31T23:59:59Z>"}],
    "ComplianceStatus": [{"Value":"FAILED","Comparison":"EQUALS"}]
  }' \
  --query 'Findings[].{Title:Title,Severity:Severity.Label,Account:AwsAccountId,Status:Workflow.Status}' \
  --output table > ~/Downloads/securityhub-q<N>-<YYYY>-failures.txt

Also capture the overall compliance score snapshot:

Security Hub console → Summary → Take a screenshot
Save as: securityhub-posture-<YYYY>-Q<N>.png

This screenshot + the failure export becomes supporting evidence for §164.308(a)(1) (risk analysis — Security Hub posture quantifies the control gap at a point in time).

Step 2 — Generate the Audit Manager Assessment Report

See Section 4 above for the full report generation procedure.

Report naming: cirius-hipaa-<YYYY>-Q<N>.pdf

Verify the report downloaded completely before proceeding:

bash

ls -lh ~/Downloads/cirius-hipaa-<YYYY>-Q<N>.pdf
# Should be several MB — if it's <100KB the report may have truncated

Step 3 — Export Config Conformance Pack Results

AWS Config conformance packs enforce HIPAA-aligned rules across the org. Pull the current compliance summary per account.

bash

# List conformance packs in the management account (aggregator)
aws configservice describe-conformance-packs \
  --profile main \
  --region us-west-2 \
  --query 'ConformancePackDetails[].{Name:ConformancePackName,Arn:ConformancePackArn}' \
  --output table

# Get compliance summary for a conformance pack
aws configservice get-conformance-pack-compliance-summary \
  --profile main \
  --region us-west-2 \
  --conformance-pack-names <pack-name> \
  --output table

# Pull non-compliant rules from a conformance pack
aws configservice get-conformance-pack-compliance-details \
  --profile main \
  --region us-west-2 \
  --conformance-pack-name <pack-name> \
  --filters '{"ComplianceType":"NON_COMPLIANT"}' \
  --query 'ConformancePackRuleEvaluationResults[].{Rule:EvaluationResultIdentifier.EvaluationResultQualifier.ConfigRuleName,Resource:EvaluationResultIdentifier.EvaluationResultQualifier.ResourceId,Status:ComplianceType}' \
  --output table > ~/Downloads/config-noncompliant-q<N>-<YYYY>.txt

If no conformance packs are listed, the org is relying on Security Hub's Config-backed rules rather than standalone conformance packs. In that case, the Security Hub findings export from Step 1 already captures Config compliance — skip this step and note in the evidence package that conformance packs are not separately deployed.

Step 4 — HIPAA §164 Control to AWS Evidence Mapping

Use this table to know which evidence file covers which HIPAA control when assembling the audit package:

HIPAA Control	Section	AWS Evidence Source	Evidence File
Risk analysis	§164.308(a)(1)	Security Hub posture score	securityhub-posture-<YYYY>-Q<N>.png + securityhub-q<N>-<YYYY>-failures.txt
Log-on monitoring	§164.308(a)(5)	CloudTrail org trail + GuardDuty	Audit Manager report — Audit Controls section
Access control	§164.312(a)(1)	IAM findings in Security Hub (NIST 800-53 R5 controls IA-2, AC-2)	Audit Manager report — Access Control section
Audit controls	§164.312(b)	CloudTrail org trail evidence in Audit Manager	Audit Manager report — Audit Controls section
Integrity	§164.312(c)(1)	Config recording, S3 Object Integrity findings	Audit Manager report — Integrity section
Authentication	§164.312(d)	MFA enforcement findings in Security Hub	Audit Manager report — Access Control section; manually document root MFA status
Workforce training	§164.308(a)(5)(ii)(A)	Manual evidence only	Upload from SharePoint: training-roster-<YYYY>-Q<N>.pdf
BAA management	§164.314(a)(1)	Manual evidence only	Upload from SharePoint: baa-vendor-register-<YYYY>-Q<N>.pdf
Transmission security	§164.312(e)(1)	Config rules on TLS/encryption in transit	Audit Manager report — Transmission Security section
Contingency plan	§164.308(a)(7)	AWS Backup, Veeam job logs	Manual evidence — backup-restore-test-<YYYY>-Q<N>.pdf

Step 5 — Hand-Off to Adriana

Collect the following files before handing off:

cirius-hipaa-<YYYY>-Q<N>.pdf            — Audit Manager assessment report
securityhub-posture-<YYYY>-Q<N>.png     — Security Hub posture screenshot
securityhub-q<N>-<YYYY>-failures.txt    — Security Hub failures export (if any)
config-noncompliant-q<N>-<YYYY>.txt     — Config conformance non-compliant items (if applicable)

Send to Adriana with instructions to upload to:

SharePoint → Compliance → AWS HIPAA Evidence → <YYYY>-Q<N>

If there are open CRITICAL or HIGH Security Hub findings at quarter-end that are not suppressed and not remediated, document them in a brief note (open-findings-<YYYY>-Q<N>.txt) and include it in the handoff. Auditors will ask about any gaps — better to proactively document with a remediation timeline than to have an unexplained finding.

6. HIPAA Control Mapping

Full mapping of HIPAA §164 requirements to Audit Manager controls and the automatic evidence AWS collects.

HIPAA Requirement	Ref	Audit Manager Control	Auto-Evidence	Manual Evidence Needed
Risk analysis and risk management	§164.308(a)(1)	Administrative Safeguards — Security Management Process	Security Hub NIST 800-53 RA-3, RA-5 compliance checks	Documented risk register or risk analysis report
Sanction policy	§164.308(a)(1)(ii)(C)	Administrative Safeguards — Security Management Process	CloudTrail — IAM policy enforcement events	HR sanction records
Log-on monitoring	§164.308(a)(5)(ii)(C)	Administrative Safeguards — Security Awareness and Training	CloudTrail login events, GuardDuty UnauthorizedAccess findings	None
Password management	§164.308(a)(5)(ii)(D)	Administrative Safeguards — Security Awareness and Training	IAM password policy Config rules	None
Workforce training	§164.308(a)(5)(ii)(A)	Administrative Safeguards — Security Awareness and Training	None (AWS has no training evidence)	Training completion records from LMS
Contingency plan / backup	§164.308(a)(7)	Administrative Safeguards — Contingency Plan	AWS Backup Config rules	Veeam job logs, restore test results
Evaluation	§164.308(a)(8)	Administrative Safeguards — Evaluation	Security Hub compliance score snapshots	Periodic review documentation
BAA / vendor contracts	§164.314(a)(1)	Organizational Requirements — Business Associate Contracts	None	BAA register from SharePoint
Access control	§164.312(a)(1)	Technical Safeguards — Access Control	IAM findings (NIST AC-2, AC-3, AC-6), MFA findings (IA-2)	None
Emergency access	§164.312(a)(2)(ii)	Technical Safeguards — Access Control	Break-glass CloudTrail events (should show zero except emergencies)	Break-glass procedure document
Automatic logoff	§164.312(a)(2)(iii)	Technical Safeguards — Access Control	IAM session policy Config rules	None
Encryption / decryption	§164.312(a)(2)(iv)	Technical Safeguards — Access Control	EBS encryption Config rules, S3 encryption Config rules	None
Audit controls	§164.312(b)	Technical Safeguards — Audit Controls	CloudTrail org trail: IsOrganizationTrail=true, LogFileValidationEnabled=true, IsMultiRegionTrail=true	None
Integrity controls	§164.312(c)(1)	Technical Safeguards — Integrity	Config resource compliance, S3 Object Integrity Config rules	None
Mechanism to authenticate ePHI	§164.312(c)(2)	Technical Safeguards — Integrity	S3 versioning, Object Lock Config rules	None
Authentication (person/entity)	§164.312(d)	Technical Safeguards — Authentication	MFA Config rules, IAM credential report (access keys > 90 days)	Root MFA verification
Encryption in transit	§164.312(e)(2)(ii)	Technical Safeguards — Transmission Security	ACM certificate Config rules, load balancer HTTPS enforcement	None

7. GuardDuty Operations

Accessing Aggregated Findings

GuardDuty is delegated to the Logging account (038901680748). All findings from all 7 member accounts appear in a single aggregated view.

AWS Console (Logging account) → GuardDuty → Findings

Filter by severity and account to focus on what matters:

bash

# List HIGH and CRITICAL findings across the org
aws guardduty list-findings \
  --profile logging \
  --region us-west-2 \
  --detector-id <detector-id> \
  --finding-criteria '{
    "Criterion": {
      "severity": {"Gte": 7}
    }
  }' \
  --output table

# Get detector ID for the Logging account
aws guardduty list-detectors \
  --profile logging \
  --region us-west-2 \
  --query 'DetectorIds[0]' \
  --output text

Severity Thresholds and Escalation

GuardDuty uses a numeric severity scale (0.1–10). These map to actions:

GuardDuty Severity	Range	Action
LOW	0.1–3.9	Log in SecOps platform, no immediate escalation
MEDIUM	4.0–6.9	Investigate within 24 hours; if confirmed malicious, escalate to Arctic Wolf
HIGH	7.0–8.9	Escalate to Arctic Wolf immediately via Concierge; open SecOps incident
CRITICAL	9.0–10.0	Arctic Wolf acts first (MDR contract); parallel open SecOps CRITICAL incident

Arctic Wolf's AWS connector reads GuardDuty findings and auto-creates observations. For HIGH/CRITICAL findings, Arctic Wolf's MDR team may already be working the case. Check the Arctic Wolf portal before taking action — avoid duplicate investigation effort.

HIPAA-Relevant Finding Types

These GuardDuty finding types are most significant for HIPAA evidence and incident response:

Finding Type	HIPAA Relevance	Response
`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration`	§164.312(a)(1) access control breach	CRITICAL — contains credential and rotates immediately
`UnauthorizedAccess:IAMUser/MaliciousIPCaller`	§164.312(a)(1) unauthorized access	HIGH — block IP, audit session
`UnauthorizedAccess:IAMUser/UnusualASNCaller`	§164.308(a)(5) logon monitoring	MEDIUM — verify whether the call was legitimate
`Recon:EC2/PortProbeUnprotectedPort`	§164.312(e)(1) transmission security	MEDIUM — review security group rules
`Recon:EC2/Portscan`	§164.312(e)(1)	HIGH if from internal source, MEDIUM if external
`CryptoCurrency:EC2/BitcoinTool.B`	Resource integrity	HIGH — instance may be compromised
`Backdoor:EC2/C&CActivity.B`	§164.312(c)(1) integrity	CRITICAL — isolation required
`CredentialAccess:IAMUser/AnomalousBehavior`	§164.312(d) authentication	HIGH — review IAM activity
`Policy:IAMUser/RootCredentialUsage`	§164.312(d) authentication	Always CRITICAL — root usage outside break-glass = incident

GuardDuty and the SecOps AWS Agent

The Cirius AWS security agent (running in the aws/ agent folder in ops-automation) reads GuardDuty findings via the delegated admin account and creates incidents in the SecOps platform. It checks HIGH and CRITICAL findings each 4-hour cycle. If GuardDuty is generating findings but they are not appearing in SecOps, check:

The agent is running: Container Apps Job → job-orchestrator-cirius → Run history
The agent IAM role has guardduty:ListFindings and guardduty:GetFindings on the detector ARN in the Logging account
The SecOps API is reachable: curl -sk https://secops.bedrockcybersecurity.org/health

8. IAM Access Analyzer

What It Does

IAM Access Analyzer identifies external access to resources — S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues — that are accessible from outside the AWS org. For HIPAA purposes, any S3 bucket or IAM role accessible to a principal outside the Cirius org is a potential PHI exposure.

Access Analyzer findings appear in each member account (where the resource lives) and in the organization-level analyzer in the Management account.

Reviewing External Access Findings

AWS Console (Management account 206820231356) → IAM → Access analyzer
  → Organization analyzer
  → Findings tab

bash

# List active external access findings org-wide
aws accessanalyzer list-findings \
  --profile main \
  --region us-west-2 \
  --analyzer-arn <org-analyzer-arn> \
  --filter '{"status":{"eq":["ACTIVE"]}}' \
  --query 'findings[].{Id:id,Resource:resource,ResourceType:resourceType,Principal:principal,Status:status}' \
  --output table

# Get the org analyzer ARN
aws accessanalyzer list-analyzers \
  --profile main \
  --region us-west-2 \
  --query 'analyzers[?type==`ORGANIZATION`].arn' \
  --output text

Addressing Findings

For each ACTIVE finding, determine whether the external access is intentional:

Arctic Wolf IAM role — intentional cross-account access for the AWS connector. Archive with note: "Arctic Wolf MDR connector — intentional, IAM role trust scoped to AW account with ExternalId."
GitHub Actions OIDC — intentional cross-account access for CI/CD. Archive with note: "GitHub Actions OIDC federation — intentional, trust policy scoped to Cirius-Group-Inc org."
Any unknown principal — treat as a potential incident until proven otherwise. Do not archive without Rory's review.

Archiving a legitimate finding:

bash

aws accessanalyzer update-findings \
  --profile main \
  --region us-west-2 \
  --analyzer-arn <org-analyzer-arn> \
  --ids '["<finding-id>"]' \
  --status ARCHIVED

Always add a note in the SecOps platform when archiving Access Analyzer findings — even legitimate cross-account access should be documented.

9. Config Conformance Packs

What They Are

Config conformance packs are collections of Config rules deployed as a single unit. AWS provides a HIPAA-aligned conformance pack template (Operational-Best-Practices-for-HIPAA-Security) that maps Config rules to HIPAA controls. Whether Cirius has deployed a standalone conformance pack or is relying on Security Hub's Config-backed rules (which is the common pattern) determines how you query compliance.

Check Whether Conformance Packs Are Deployed

bash

# Check in the management account (aggregator)
aws configservice describe-conformance-packs \
  --profile main \
  --region us-west-2 \
  --query 'ConformancePackDetails[].{Name:ConformancePackName,State:ConformancePackState}' \
  --output table

# Check in each member account if needed
for profile in logging networking prod dev identity backup; do
  echo "--- $profile ---"
  aws configservice describe-conformance-packs \
    --profile $profile \
    --region us-west-2 \
    --query 'ConformancePackDetails[].ConformancePackName' \
    --output text
done

If no conformance packs appear, Security Hub is the compliance check layer. Skip to the Config aggregator queries below.

Config Aggregator — Compliance Summary

The Config aggregator in the Management account (206820231356) collects Config compliance data from all member accounts.

bash

# List Config aggregators
aws configservice describe-configuration-aggregators \
  --profile main \
  --region us-west-2 \
  --query 'ConfigurationAggregators[].{Name:ConfigurationAggregatorName,Arn:ConfigurationAggregatorArn}' \
  --output table

# Get aggregate compliance by Config rule
aws configservice get-aggregate-config-rule-compliance-summary \
  --profile main \
  --region us-west-2 \
  --configuration-aggregator-name <aggregator-name> \
  --output table

# Get all non-compliant resources across the org for a specific rule
aws configservice list-aggregate-discovered-resources \
  --profile main \
  --region us-west-2 \
  --configuration-aggregator-name <aggregator-name> \
  --resource-type AWS::S3::Bucket \
  --output table

Per-Account Config Rule Check

If you need to drill into a specific account:

bash

# List non-compliant rules in the Prod account
aws configservice describe-compliance-by-config-rule \
  --profile prod \
  --region us-west-2 \
  --compliance-types NON_COMPLIANT \
  --query 'ComplianceByConfigRules[].{Rule:ConfigRuleName,Compliance:Compliance.ComplianceType}' \
  --output table

# Get non-compliant resources for a specific rule
aws configservice get-compliance-details-by-config-rule \
  --profile prod \
  --region us-west-2 \
  --config-rule-name <rule-name> \
  --compliance-types NON_COMPLIANT \
  --query 'EvaluationResults[].{Resource:EvaluationResultIdentifier.EvaluationResultQualifier.ResourceId,Type:EvaluationResultIdentifier.EvaluationResultQualifier.ResourceType}' \
  --output table

10. Routine Task Schedule

Weekly (Every Monday)

[ ] Log into the Logging account console (038901680748)
[ ] Navigate to Security Hub → Summary
- Review CRITICAL findings — any new ones require same-week remediation
- Review HIGH findings — any new ones go on the weekly work queue
- Capture the overall compliance score for the weekly trend (no formal logging required, just awareness)
[ ] Check GuardDuty → Findings — review any HIGH findings not already in SecOps

[ ] Verify the org trail is healthy (spot check, not a deep dive):

bash

aws cloudtrail get-trail-status \
  --profile logging \
  --region us-west-2 \
  --name <org-trail-name> \
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime,LatestDeliveryError:LatestDeliveryError}'

Monthly (First Monday)

Part of the broader monthly security review — see Monthly Security Review.

AWS-specific additions:

[ ] Review Audit Manager assessment — check for any controls showing evidence gaps (controls with zero evidence collected for 30+ days may indicate a Config or CloudTrail integration problem, not a real gap — investigate before escalating)
[ ] Review IAM Access Analyzer findings — archive legitimate ones, escalate unknown ones
[ ] Review suppressed Security Hub findings — confirm justifications are still valid
[ ] Check for Security Hub findings that are 90+ days old without resolution — these need either remediation or a formal suppression decision
[ ] Pull the monthly Config compliance summary and note any new failures

Quarterly (Last Week of March, June, September, December)

Full evidence collection per Section 5. Checklist:

[ ] Generate Security Hub compliance report (Step 1)
[ ] Generate Audit Manager assessment report (Step 2)
[ ] Export Config conformance pack results (Step 3)
[ ] Identify any HIPAA controls with evidence gaps and add manual evidence (Step 4)
[ ] Assemble evidence package and hand off to Adriana for SharePoint upload (Step 5)
[ ] Notify Kevin and Greg that the quarterly evidence package is in SharePoint

11. Troubleshooting

Security Hub Shows No Findings

Confirm you are in the Logging account (038901680748) and us-west-2 region
Check that Security Hub is delegated: Management account → Security Hub → Delegated administrator
Verify the NIST 800-53 R5 standard is enabled: Security Hub → Standards → NIST Special Publication 800-53 Revision 5
Run a manual standards check: Security Hub → Standards → NIST → View results

Audit Manager Assessment Shows No Evidence

Evidence gaps can mean Config or CloudTrail is not flowing to Audit Manager correctly.

bash

# Check Audit Manager data sources
aws auditmanager get-assessment \
  --profile logging \
  --region us-west-2 \
  --assessment-id <assessment-id> \
  --query 'assessment.metadata.{Scope:scope,Status:status}' \
  --output json

# Check whether Config is enabled in all accounts
for profile in logging networking prod dev identity backup main; do
  echo "--- $profile ---"
  aws configservice describe-configuration-recorders \
    --profile $profile \
    --region us-west-2 \
    --query 'ConfigurationRecorders[].{Name:name,RoleArn:roleARN}' \
    --output text
done

If Config recording is stopped in any account, Audit Manager will not collect Config evidence for resources in that account. Re-enable recording:

bash

aws configservice start-configuration-recorder \
  --profile <affected-profile> \
  --region us-west-2 \
  --configuration-recorder-name <recorder-name>

GuardDuty Finding Missing from SecOps

Check the AWS agent last run time:

Azure Portal → Container Apps → job-orchestrator-cirius → Execution history

Verify the finding is HIGH or CRITICAL severity — the agent only creates incidents for severity ≥ 7.0
Check the SecOps findings tab for the finding ID — it may already be there as a finding rather than an incident
Confirm the agent IAM role (OrganizationSecurityAudit or equivalent) has guardduty:GetFindings on the detector ARN in the Logging account

CloudTrail Org Trail Gaps

If the org trail is not delivering to S3:

bash

aws cloudtrail get-trail-status \
  --profile logging \
  --region us-west-2 \
  --name <trail-name>

Check LatestDeliveryError — common causes:

S3 bucket policy does not allow CloudTrail to write (bucket policy drift)
KMS key policy does not allow CloudTrail to encrypt (CMK drift)
CloudTrail service role lost permissions

These are not self-healing — the fix requires a Terraform PR to restore the bucket policy and/or KMS key policy to the correct state.

AWS Account Access Guide — SSO setup, CLI profiles
Arctic Wolf AWS Connector — connector verification and telemetry flow
Arctic Wolf Ingestion Validation — confirming data reaches the LAW
Monthly Security Review — full monthly checklist
Incident Response — how to handle GuardDuty-sourced incidents
Log Retention Verification — confirming CloudTrail archive meets 6-year HIPAA retention

Document History

Date	Change	Author
May 2026	Initial draft — architecture overview, Security Hub operations, Audit Manager HIPAA framework, quarterly evidence workflow, HIPAA control mapping, GuardDuty, IAM Access Analyzer, Config conformance packs, routine schedule, troubleshooting	Kobe

AWS Audit Manager — HIPAA Compliance Runbook ​

Overview ​

1. Architecture Overview ​

How the Tools Fit Together ​

Delegated Admin Summary ​

Account Reference ​

How Findings Flow ​

2. Access — Getting Into the Logging Account ​

SSO Login ​

CLI Access ​

3. Security Hub Operations ​

Accessing the Aggregated View ​

NIST 800-53 R5 Findings ​

Finding Lifecycle ​

Suppressing a Finding ​

Remediating Common NIST 800-53 Findings ​

How Security Hub Findings Reach Arctic Wolf and the LAW ​

4. Audit Manager — HIPAA Framework ​

What Audit Manager Does ​

Navigating to the HIPAA Assessment ​

Assessment Structure ​

Automatically Collected Evidence ​

Adding Manual Evidence ​

Assessment Report Generation ​

5. Evidence Collection Workflow — Quarterly Pull ​

Step 1 — Generate the Security Hub Compliance Report ​

Step 2 — Generate the Audit Manager Assessment Report ​

Step 3 — Export Config Conformance Pack Results ​

Step 4 — HIPAA §164 Control to AWS Evidence Mapping ​

Step 5 — Hand-Off to Adriana ​

6. HIPAA Control Mapping ​

7. GuardDuty Operations ​

Accessing Aggregated Findings ​

Severity Thresholds and Escalation ​

HIPAA-Relevant Finding Types ​

GuardDuty and the SecOps AWS Agent ​

8. IAM Access Analyzer ​

What It Does ​

Reviewing External Access Findings ​

Addressing Findings ​

9. Config Conformance Packs ​

What They Are ​

Check Whether Conformance Packs Are Deployed ​

Config Aggregator — Compliance Summary ​

Per-Account Config Rule Check ​

10. Routine Task Schedule ​

Weekly (Every Monday) ​

Monthly (First Monday) ​

Quarterly (Last Week of March, June, September, December) ​

11. Troubleshooting ​

Security Hub Shows No Findings ​

Audit Manager Assessment Shows No Evidence ​

GuardDuty Finding Missing from SecOps ​

CloudTrail Org Trail Gaps ​

12. Related Documents ​

Document History ​

AWS Audit Manager — HIPAA Compliance Runbook

Overview

1. Architecture Overview

How the Tools Fit Together

Delegated Admin Summary

Account Reference

How Findings Flow

2. Access — Getting Into the Logging Account

SSO Login

CLI Access

3. Security Hub Operations

Accessing the Aggregated View

NIST 800-53 R5 Findings

Finding Lifecycle

Suppressing a Finding

Remediating Common NIST 800-53 Findings

How Security Hub Findings Reach Arctic Wolf and the LAW

4. Audit Manager — HIPAA Framework

What Audit Manager Does

Navigating to the HIPAA Assessment

Assessment Structure

Automatically Collected Evidence

Adding Manual Evidence

Assessment Report Generation

5. Evidence Collection Workflow — Quarterly Pull

Step 1 — Generate the Security Hub Compliance Report

Step 2 — Generate the Audit Manager Assessment Report

Step 3 — Export Config Conformance Pack Results

Step 4 — HIPAA §164 Control to AWS Evidence Mapping

Step 5 — Hand-Off to Adriana

6. HIPAA Control Mapping

7. GuardDuty Operations

Accessing Aggregated Findings

Severity Thresholds and Escalation

HIPAA-Relevant Finding Types

GuardDuty and the SecOps AWS Agent

8. IAM Access Analyzer

What It Does

Reviewing External Access Findings

Addressing Findings

9. Config Conformance Packs

What They Are

Check Whether Conformance Packs Are Deployed

Config Aggregator — Compliance Summary

Per-Account Config Rule Check

10. Routine Task Schedule

Weekly (Every Monday)

Monthly (First Monday)

Quarterly (Last Week of March, June, September, December)

11. Troubleshooting

Security Hub Shows No Findings

Audit Manager Assessment Shows No Evidence

GuardDuty Finding Missing from SecOps

CloudTrail Org Trail Gaps

12. Related Documents

Document History