The situation
A mid-sized org has grown to about 40 AWS accounts, and the compliance workload is growing with it. Two audit cycles are on the calendar for next year: a PCI DSS 4.0.1 cycle for the payments-scoped accounts (about 8 accounts), and a SOC 2 Type II for the whole org. Currently the work is done by a small compliance team pulling evidence manually (screenshots of Config rule results, CloudTrail exports, IAM policy reviews) into a SharePoint workspace the auditor is sent at the end of each cycle. That process takes roughly 600 person-hours per cycle.
The CTO has asked for automation. The candidate tools are AWS Config (already enabled in every account, ~85 rules per account evaluated) and AWS Audit Manager (not yet enabled). Both are pitched by different people in the conversation as “the answer to compliance.” The question is whether they’re the same thing, what the overlap is, and what the stack should look like.
What actually matters
The compliance job has at least three distinct sub-jobs, and a tool that solves one doesn’t necessarily solve the others.
Evaluating the state of resources continuously is the first. Every compute instance, every bucket, every IAM policy, every security group has a current configuration; compliance says that configuration has to meet certain rules; somebody has to evaluate all of those resources against all of those rules continuously and produce a list of non-compliant findings. The right shape is a sensor that fires on resource change or on a schedule, emitting compliant/non-compliant results that are queryable and exportable.
Collecting evidence of controls is the second, and it is a different kind of work. Evidence is anything that, combined with other evidence, demonstrates a control is operating: continuous-evaluation findings, audit-log events, identity-policy snapshots, posture findings, advisor checks, manually uploaded attestations. A control might have several evidence sources. The evidence has to be collected, dated, attributed, retained in a form the auditor will accept, and tied back to the specific control it supports. The job calls for a catalogue of standards (frameworks), each with a set of controls, each with mapped data sources that an evidence collector pulls from automatically.
Running the assessment workflow is the third. A formal assessment is a finite project: start on date X, end on date Y, produce a report for audience Z. During the assessment, evidence is collected, controls are marked as implemented or deficient, comments are added, remediation tasks are tracked, and a final report is produced. The continuous-evaluation engine doesn’t do this; it has no notion of “assessment window.”
So the picture is: one tool is the sensor and evaluator; another is the workflow and report generator; a third sits between them as the cross-source normaliser. The three are complements, and the work is figuring out which slot each candidate fills before reaching for any of them.
What we’ll filter on
- What produces the finding. Resource evaluation, data-source ingestion, or manual upload?
- Workflow scope. Continuous monitoring or a time-bounded assessment?
- Standards coverage. What frameworks ship built-in?
- Evidence depth. Does the tool hold the actual artifacts or just a summary?
- Output shape. Dashboard, finding stream, or auditor-facing report?
The compliance landscape
1. AWS Config. Continuous resource-configuration evaluator. Records resource state history, evaluates rules (AWS-managed or custom via Lambda) on changes or on a schedule, produces compliance findings. Conformance packs bundle curated rules against standards; ~100+ ship with AWS (PCI DSS, HIPAA, CIS, FedRAMP, NIST SP 800-53, Operational Best Practices for [various services]). Org-wide via aggregator. Priced per configuration item recorded plus per rule evaluation.
2. AWS Audit Manager. Assessment workflow with a framework catalogue (PCI DSS 4.0.1, SOC 2, NIST 800-53 Rev 5, HIPAA, GDPR, ISO 27001, GxP, and others). For each control, Audit Manager has mapped data sources that pull evidence automatically from Config, Security Hub, CloudTrail, Trusted Advisor, and others. Assessments are scoped to a set of accounts and a framework; each assessment is a finite project with collected evidence, a reviewer workflow, and a final report.
3. AWS Security Hub with standards. Not a compliance tool per se, but its security standards (CIS AWS Foundations, AFSBP, PCI DSS, NIST 800-53) evaluate a curated set of controls and produce a compliance score. Narrower than Audit Manager’s assessment workflow, broader than Config’s resource rules. Useful as an always-on posture dashboard and as an evidence source for Audit Manager.
4. AWS Artifact. The portal where AWS’s own compliance reports (ISO, SOC, PCI DSS AoC) live. Not about our resources; about AWS’s own certifications. Complementary; the auditor wants both our evidence and AWS’s.
5. Third-party GRC tools (Vanta, Drata, Secureframe, ServiceNow GRC). Assessment and evidence management for orgs that operate across multiple clouds, SaaS vendors, and on-premises. Integrations with AWS services to pull evidence automatically. Priced per control or per auditor-seat. Used when the compliance estate extends beyond AWS-only.
Side by side
| Tool | What produces findings | Scope | Standards | Evidence depth | Output |
|---|---|---|---|---|---|
| Config conformance pack | Rule evaluation on resources | Continuous, per-account or org | PCI, CIS, NIST, HIPAA, OBP | Resource config snapshots | Dashboard + finding stream |
| Audit Manager | Data-source ingestion + manual upload | Assessment (finite project) | PCI 4.0.1, SOC 2, NIST, HIPAA, ISO, GDPR | Dated artifact repository | Auditor-facing report |
| Security Hub standards | Mix of Config + native checks | Continuous, org-wide | CIS, AFSBP, PCI, NIST | Finding records (ASFF) | Compliance score dashboard |
| AWS Artifact | AWS’s own evidence | N/A | AWS’s own certifications | PDF reports | Download |
| Third-party GRC | Integrations + manual | Cross-cloud | Anything the vendor models | Vendor-hosted artifacts | Vendor reports |
Reading the table: Config and Audit Manager answer different questions. “Are my resources configured correctly right now?” is Config’s question. “Do I have an evidence package demonstrating control operation over Q3 that I can hand to an auditor on 15 November?” is Audit Manager’s. Security Hub sits between them. They all coexist.
The compliance stack, end to end
The picks in depth
Config conformance packs for always-on rule evaluation. Enable Config in every account, recording all supported resource types, with an organisation aggregator in the security-audit account. Deploy the Operational Best Practices for PCI DSS conformance pack to the PCI-scoped accounts and the CIS AWS Foundations Benchmark pack to every account. Each pack is a YAML template deployable via aws configservice put-conformance-pack or CloudFormation. Custom rules (Lambda-backed) cover org-specific policy that isn’t in the packs, like “all S3 buckets must have the DataClassification tag,” or “no security group may allow 0.0.0.0/0 on port 22.” Every rule evaluation is cached; re-evaluation runs on resource change or on a schedule. Findings flow into Security Hub by default.
Audit Manager for the assessment workflow. Enable Audit Manager in the audit account, org-wide. Create an assessment scoped to the 8 PCI-scoped accounts, framework PCI DSS 4.0.1, window 1 October 2028 - 31 December 2028. For each control in the framework (PCI has ~370), Audit Manager has a default data-source mapping. Control 1.2.1 (“install and maintain a firewall configuration”) maps to Config rules for security groups and NACLs, CloudTrail events for security-group changes, and a manual attestation slot for the firewall-config policy document. Audit Manager collects automatically-sourced evidence continuously during the assessment; manual evidence (policies, procedures, interview notes) is uploaded by the compliance team to the control’s evidence folder. At the end of the window, “Generate assessment report” produces a PDF with per-control evidence summaries, and the raw evidence is exported to an S3 bucket for the auditor.
Security Hub standards as the middle layer. Enable CIS AWS Foundations v3 and AFSBP org-wide; enable PCI DSS 4.0.1 on the PCI accounts. Hub’s standards are the dashboard the security team watches daily; Config conformance packs are the rule engine feeding them; Audit Manager is the quarterly assessment that reuses those findings. Don’t double-deploy: Hub’s PCI standard and Config’s PCI conformance pack overlap significantly; pick one or the other for the PCI-specific rule set to avoid double-counting the same control. The usual choice is Config’s PCI conformance pack (more depth, more custom-rule integration) with Hub’s PCI standard disabled to prevent duplicate findings, and Hub CIS+AFSBP always on for the broader security posture.
A worked assessment
October 1, 2028. Audit Manager assessment pci-dss-q4-2028 begins. Scope: 8 PCI accounts. Framework: PCI DSS 4.0.1. Window: Oct 1 - Dec 31. Reviewers: compliance team + payments engineering lead.
During the window, Audit Manager pulls evidence automatically:
- Config compliance data for each resource in scope, every 24 hours, into the assessment’s evidence store.
- CloudTrail events matching mapped patterns (IAM policy changes, KMS key usage, security-group modifications, console logins).
- Security Hub findings against the PCI-tagged accounts.
- Trusted Advisor check results for relevant checks.
The compliance team uploads manual evidence:
- Incident-response runbook (attached to control 12.10.1).
- Penetration test report from Q3 (attached to control 11.3.1).
- Training attendance records (attached to control 12.6.1).
- Vendor attestations (attached to controls 12.8.x).
Weekly, the compliance team reviews the evidence and marks controls as “Compliant,” “Non-compliant,” “Not applicable,” or “Under review.” Non-compliant controls get a remediation ticket (linked from the control).
December 31. The assessment window ends. Audit Manager stops collecting new evidence. “Generate assessment report” produces a PDF with an executive summary, per-control compliance status, evidence counts, and gap analysis. Separately, the raw evidence package is exported to an S3 bucket (~40 GB, gzipped) and provided to the auditor.
Total compliance team time: ~220 hours across the quarter (versus ~600 under the manual process). The saving is the automated data-source collection; the manual work that remains is reviewing the evidence and uploading attestations.
A worked rule remediation
Config finds a NON_COMPLIANT result on an S3 bucket against the s3-bucket-public-read-prohibited rule: the bucket has an ACL granting AllUsers read access. Finding flows to Security Hub, which emits an EventBridge event. An SSM Automation runbook is subscribed to Security Hub Findings - Custom Action: the on-call marks the finding with a Custom Action tag, the runbook fires, the runbook calls s3 put-bucket-acl to remove the public grant, Config re-evaluates, the finding transitions to COMPLIANT within 15 minutes.
The auditor later asks “show me remediation evidence for S3 public-access incidents in Q4.” Audit Manager has collected both the initial Config NON_COMPLIANT record and the CloudTrail s3:PutBucketAcl call for the remediation, dated and attributed. The evidence package shows the incident, the timing of the response, and the post-remediation compliant state.
What’s worth remembering
- Config is the continuous resource evaluator; Audit Manager is the assessment workflow. Different jobs; use both.
- Config conformance packs bundle rules against frameworks. PCI DSS, CIS, NIST 800-53, HIPAA, many others ship as AWS-managed packs.
- Audit Manager has a framework catalogue with pre-mapped data sources. For each control, it knows which Config rule, CloudTrail events, or Security Hub findings to pull as evidence.
- Audit Manager assessments are time-bounded projects. Scope (accounts), framework, window, reviewers. Produce a report at the end.
- Security Hub’s standards overlap with Config conformance packs. Pick one for each specific standard to avoid duplicate findings (usually Config for depth + Hub as the posture dashboard).
- Manual evidence upload is a first-class operation. Policies, procedures, attestations that can’t be automated still go into the assessment’s evidence folder.
- Remediation produces evidence too. CloudTrail records the remediation call; Audit Manager captures it as evidence of “control responds to drift.”
- Org-wide enables via delegated admin. Config aggregator from the security-audit account, Audit Manager org-wide scope from the same account, Hub delegated admin from the same account. One security account is the pattern.
Two tools, two jobs, one stack. Config is always-on; Audit Manager is per-cycle. Together they replace most of the manual evidence collection that used to define audit season.