# Continuous compliance automation — which tool does which job

Security Hub is *detection of control failures*. It is not the whole compliance
pipeline, and treating it as such is why teams stay stuck doing manual evidence
collection at audit time. This matrix maps the four jobs of a continuous
compliance pipeline to the AWS service that actually does each one.

> Capabilities reflect the mid-2026 model. Confirm conformance pack rule
> coverage, Audit Manager framework availability, and Security Hub standards in
> the respective AWS docs before relying on them.

| Job | Service | What it produces | What it does NOT do |
|-----|---------|------------------|---------------------|
| **Detect** drift from a baseline | **AWS Config** rules (+ Security Hub standards) | Compliant/non-compliant per resource, continuously | Fix anything by itself |
| **Package & deploy** rules at scale | **Config conformance packs** | Immutable YAML bundle of rules + remediation, deployable org-wide (Quick Setup / StackSets) | Per-rule edits (packs are immutable by design) |
| **Remediate** non-compliant resources | **SSM Automation** documents wired to Config rules | Auto-fix (e.g. enable encryption, close public access) | Judge whether the fix is safe for your workload |
| **Prove it to an auditor** | **AWS Audit Manager** | Continuous evidence collection mapped to framework controls; cryptographically verifiable assessment reports | *Assess* compliance — it gathers evidence, you/the auditor judge |

## The pipeline, end to end

```
Config (record) -> Config rules / conformance pack (detect)
   -> EventBridge / Config remediation (trigger)
      -> SSM Automation document (remediate)
   -> Security Hub (aggregate findings, score standards)
   -> Audit Manager (collect evidence -> assessment report)
```

## Decisions that actually matter

- **Conformance packs over hand-managed rules.** Packs are immutable and
  deploy across an org via Systems Manager Quick Setup or StackSets. You stop
  babysitting individual rules per account. The trade-off: to change a rule you
  redeploy the pack, you don't edit in place.
- **Auto-remediate only the safe, reversible class first.** Good first
  candidates: enable S3 default encryption, block public access, enable EBS
  encryption-by-default, attach a missing tag. Hold back anything that could
  break a running workload (e.g. flipping security-group rules) for
  human-approved remediation.
- **Know the auto-remediation gotcha.** AWS Config auto-remediation runs off
  periodic compliance snapshots, so it can occasionally fire on an
  already-compliant resource due to stale evaluation data. Make remediation
  documents **idempotent** and use `describe-remediation-execution-status` to
  debug failures.
- **Audit Manager collects evidence; it does not certify you.** This is the
  honest limit: Audit Manager continuously gathers evidence and produces
  audit-ready reports, but it explicitly does not assess whether you are
  compliant. It removes the manual screenshot-gathering scramble; it doesn't
  replace the auditor or your judgment.

## When NOT to automate

- Don't auto-remediate a control you don't understand the blast radius of. A
  "fix" that closes a security group your app depends on is an outage you caused.
- Don't bother with Audit Manager if you have no framework you're actually
  audited against — Config + Security Hub may be enough for internal hygiene.
- Don't deploy a 200-rule conformance pack to prod on day one. Roll out per OU,
  detect-only first, then enable remediation on the safe subset.