How to Set Up Continuous Audit Evidence Collection Across an AWS Organization

The situation

The compliance team at a mid-sized SaaS business is preparing for their second SOC 2 Type II audit. The first one, last year, was run out of a shared Google Drive and a spreadsheet: engineers opening each (then thirty) account’s console, screenshotting bucket encryption configuration into a CC6.1 folder, MFA state into CC6.6, patching compliance exports into a PDF, and a spreadsheet tracking which folder went with which control number.

It worked, barely, for thirty accounts and a point-in-time snapshot. This year the account count is sixty, the audit window is a rolling twelve months, and the auditor has asked for continuous evidence. Doing last year’s process twice as hard isn’t a plan.

What they want: evidence collection across all sixty accounts with no per-account screenshot ritual; every piece of evidence filed under the SOC 2 control it supports (CC6.1, CC6.6, CC7.2, and so on); framework coverage that extends to HIPAA and PCI DSS next year without redoing the mapping; an auditor-ready bundle, control list, evidence per control, a manifest, not a shared-drive link; and continuous monitoring that catches a control slipping on a Wednesday rather than at the next annual audit.

What actually matters

Before picking a service, it’s worth being clear about what the audit relationship actually requires of a compliance tool.

The first thing is that the deliverable is the control, not the finding. Auditors work from a list of controls, each with a description (“CC6.1: the entity encrypts data at rest”), and they want evidence that this specific control was met. A raw finding feed is useful for engineers, it tells them what’s broken, but an auditor handed a GuardDuty export asks “and which control does this prove?” A compliance tool has to file evidence under control numbers, not only under severity tags.

The second is framework coverage and its cost. SOC 2 this year, HIPAA next, PCI after that. The control maps overlap but aren’t identical. A tool where “add a framework” means “import a pre-built template and click go” turns the per-framework work from weeks to an afternoon; a tool where it means “hand-map every control again” turns compliance from a ratchet into an annual rebuild.

The third is multi-account collection without a campaign. Sixty accounts is too many to log into. The tool has to integrate with AWS Organizations, take evidence from every member account centrally, and onboard new accounts as they join the Org. The last piece is easy to miss, if “add account 61” means “extend the evidence collector’s IAM policy” then the team is back in the ticket queue every product launch.

The fourth is the shape of the report. At audit time, the auditor wants a bundle: a control list, the evidence per control, a manifest linking the two. That bundle lives in an S3 bucket, ideally KMS-encrypted, owned by the audit team. A tool that ends at a console dashboard makes the audit bundle a hand-assembly job; a tool that ends at a signed report folder makes it a cross-account S3 share.

The fifth is continuous monitoring between audits. The first audit’s failure mode was “something slipped in March, nobody noticed until November.” The remedy is that every control has a continuously-evaluating rule, a non-compliant evaluation is visible centrally, and the team can respond same-day. Rules that run once a quarter and a dashboard nobody watches are the problem, not the solution.

The sixth is the escape hatch for controls the framework doesn’t cover. Every company’s interpretation of the Trust Services Criteria has controls the pre-built framework doesn’t map, “every production Lambda must be deployed by the central pipeline,” or “all IAM changes must go through a named approval workflow.” A tool where custom controls can be added inside the framework, with a bespoke data source, keeps the whole audit in one place. A tool that forces “everything the framework covers” plus “a separate tracker for everything else” doubles the maintenance.

Finally, who feeds what. Most of the useful SOC 2 evidence comes from AWS Config rule evaluations; the audit tool is the collector, not the rule engine. If the rules aren’t deployed, the collector collects silence. The correct shape is a rule layer and a collection layer, side by side, with Config deploying the rules and the audit tool reading the evaluations.

What we’ll filter on

1. Control-to-evidence mapping, evidence organised by the control it supports, not raw findings.
2. Multi-account collection. Organizations-native, centralised, auto-onboarding.
3. Framework templates. SOC 2, HIPAA, PCI DSS, NIST, ISO ready to instantiate.
4. Report packaging, auditor-ready bundle with manifest, not a dashboard screenshot.
5. Continuous monitoring, drift caught between audits, linked to the control it affects.

The compliance landscape on AWS

AWS has four mechanisms in this corner of the platform, plus the third-party GRC market for completeness.

AWS Audit Manager. A managed evidence-collection and audit-report service built for this shape. Ships pre-built framework templates for SOC 2, HIPAA Security Rule, PCI DSS, NIST 800-53, NIST CSF, ISO/IEC 27001, CIS AWS Foundations, GDPR, FedRAMP Moderate, AWS Well-Architected, and more. A framework is a tree of control sets containing controls; each control has data sources naming where evidence comes from (Config rule evaluations, Security Hub findings, CloudTrail events, AWS API snapshots, manual uploads). Instantiated as an assessment scoped to accounts in the organisation. Multi-account via Organizations delegated administrator. Generates assessment reports (PDF index plus evidence files) into an S3 bucket the team controls.

AWS Config conformance packs. A deployable bundle of Config rules and remediation actions in YAML. Pre-built packs exist for PCI DSS, HIPAA, NIST CSF, CIS, SOC 2 operational controls, and dozens more. Deploy organisation-wide via Config’s delegated administrator; every rule evaluates across every member account continuously. Packs are the continuous-monitoring engine. They don’t produce an auditor-ready report.

AWS Security Hub. A finding aggregator consuming findings from GuardDuty, Inspector, Macie, Config, Access Analyzer, and third parties, normalising them into ASFF. Ships security standards that look framework-shaped but are finding-oriented, not control-evidence-oriented. A posture dashboard, not an audit deliverable.

CloudTrail plus Athena. The raw-log answer. Organisation trails land in a central bucket; Athena queries the logs with SQL. For any control, possible to hand-write a query that reconstructs evidence and package it. For dozens of controls, a substantial engineering project.

Third-party GRC tools. Drata, Vanta, Tugboat Logic, Secureframe sit outside AWS and offer managed SOC 2 / HIPAA / ISO audit automation across a broader surface. HR, training, laptop encryption. The correct answer when compliance spans beyond cloud infrastructure; a vendor relationship otherwise.

Side by side

Mechanism	Control mapping	Multi-account	Framework templates	Report packaging	Continuous monitoring
AWS Audit Manager	✓	✓ (Orgs)	✓ (SOC 2, HIPAA, PCI)	✓ (assessment report)	✓ (via data sources)
AWS Config conformance packs	, (rule-level)	✓ (Orgs)	✓ (pre-built packs)	✗	✓ (rule evaluations)
AWS Security Hub	, (finding-oriented)	✓	, (standards)	✗	✓ (findings)
CloudTrail + Athena	✗ (hand-mapped)	✓ (org trail)	✗	✗	, (query-time)
Third-party GRC	✓	✓	✓	✓	✓

Matching the audit to a toolchain

Audit Manager in depth

Setup. In the management account, register one member account as the delegated administrator for Audit Manager. From the delegated admin account, enable the service; it provisions IAM roles it assumes into each member account.

Framework selection. The SOC 2 framework is a pre-built template covering the Trust Services Criteria. Security (CC1–CC9), Availability, Processing Integrity, Confidentiality, Privacy. Each criterion contains controls; each control has automated data sources plus a manual-evidence slot.

Assessment creation. Create an assessment from the SOC 2 framework. The assessment names the framework, the scope (in-scope accounts selected from the organisation, up to the full sixty here, plus the AWS services relevant to the controls), the audit owner, the S3 bucket where evidence and reports land, and optional KMS encryption.

Evidence collection. From the moment the assessment is active, Audit Manager’s evidence collectors run continuously, scoped to the assessment’s accounts and services. Four collector types:

• AWS Config evaluations. For every control mapped to a Config rule, Audit Manager captures each rule’s compliance evaluation results on a rolling basis. Stored per-resource, per-rule, timestamped, with the compliant/non-compliant verdict.
• AWS Security Hub findings. For controls mapped to Security Hub standards, the relevant findings (with state transitions) are captured.
• CloudTrail events. For controls where the proof is “this API was called with these parameters” – CreateBucket with encryption configuration, PutUserPolicy attaching a specific managed policy, matching CloudTrail events are captured.
• AWS API reads. For controls where the proof is the current configuration state, Audit Manager periodically calls describe/list APIs (iam:GetAccountPasswordPolicy, ec2:DescribeSecurityGroups, s3:GetBucketEncryption) and stores the responses.

Manual evidence. Controls that cannot be automated, a signed security policy, a pen-test report, evidence of a board review, have a manual upload slot on the control page.

Report generation. When the audit window closes, the audit owner generates an assessment report. Audit Manager produces a PDF index listing every control in the framework, the evidence count per control, and a manifest linking to the evidence files. The report and evidence land in the configured S3 bucket, KMS-encrypted. The auditor receives either the S3 URI with cross-account read or a ZIP of the bucket prefix.

Why Config conformance packs belong alongside

Audit Manager is the evidence service, not the rule engine. When SOC 2 CC6.1 says “the entity encrypts data at rest,” the mapped data source is typically a Config rule evaluation such as s3-bucket-server-side-encryption-enabled, rds-storage-encrypted, and ebs-encrypted-volumes. If those rules are not deployed across the organisation, Audit Manager files “no evidence found” against CC6.1.

Config conformance packs solve that. A pack is a YAML template bundling a named set of rules, optional parameters per rule, and optional remediation actions (Systems Manager automation documents triggered on non-compliance). Pre-built packs include an Operational Best Practices for SOC 2 pack, an encryption pack, an identity pack, a PCI DSS pack, a HIPAA Security Rule pack, and many more. Deploy via Config’s organisation delegated administrator.

The pairing: Audit Manager owns “this is the SOC 2 framework, these are the controls, here is the evidence per control, here is the report.” Config conformance packs own “these are the rules that produce those evaluations, and they run continuously.”

Between audits, a conformance pack failing (a new unencrypted bucket appears) is the continuous-monitoring signal. Config publishes the non-compliance immediately, Audit Manager captures it as a fresh evidence item against CC6.1, and the team can intervene same-day.

Where CloudTrail plus Athena still fits

The raw-log path isn’t wasted work. Two honest uses.

Audit-time forensic investigation. When the auditor asks “show me every principal who touched this KMS key in the last ninety days,” CloudTrail plus Athena answers quickly. Audit Manager’s collected evidence is summary-shaped; the underlying CloudTrail data is where the full story lives.

Custom controls Audit Manager does not cover. The SOC 2 framework is comprehensive but not exhaustive for every company’s interpretation of the TSC. A control the framework does not map, “every production Lambda must be deployed by the central pipeline”, may need a bespoke CloudTrail query as its data source. Audit Manager supports custom controls whose data source is a CloudTrail event filter, which keeps bespoke queries inside the framework. When Audit Manager cannot collect what a control requires, CloudTrail plus a scheduled Athena query delivering into the manual-upload slot is the escape hatch.

Security Hub’s role is the same: its findings feed Audit Manager as one data source among several; the Security Hub console is the correct place for SecOps day-to-day response. It is not the audit deliverable.

What’s worth remembering

1. AWS Audit Manager is the managed service for SOC 2 / HIPAA / PCI / ISO / NIST evidence collection and auditor-ready report generation.
2. Framework vs assessment. A framework is the control template; an assessment is a running instance scoped to specific accounts and services.
3. Multi-account is via AWS Organizations delegated administrator for Audit Manager, one nominated account assesses every member account.
4. Controls have data sources: Config rule evaluations, Security Hub findings, CloudTrail events, AWS API snapshots, manual uploads. One control can combine several.
5. Assessment reports are PDF indexes plus evidence files delivered into an S3 bucket the audit owner controls, optionally KMS-encrypted.
6. Config conformance packs deploy the rules whose evaluations feed Audit Manager’s controls. Deploy organisation-wide via Config’s delegated administrator.
7. Pre-built conformance packs exist for PCI DSS, HIPAA, NIST CSF, CIS, and SOC 2 operational best practices, among many others.
8. Security Hub is a finding aggregator, not an audit deliverable. Its findings feed Audit Manager as one data source.
9. CloudTrail + Athena is the forensic layer and the escape hatch for custom controls Audit Manager does not cover.
10. Third-party GRC tools (Drata, Vanta, Tugboat Logic, Secureframe) cover the same ground plus non-AWS evidence; pick one when compliance spans beyond AWS.
11. Custom controls let the team add bespoke data sources into an existing framework when the pre-built list does not fit the company’s interpretation.