Skip to main content

Continuous Compliance Automation on AWS (2026): Config Conformance Packs, SSM Auto-Remediation, and Audit Manager — Past Security Hub

Security & ComplianceUpdated Nash Ogden5 min read

Quick summary: Security Hub detects control failures. It is not the compliance pipeline, and treating it as one is why teams still scramble for evidence at audit time. The four jobs are distinct: AWS Config detects drift, conformance packs deploy rules org-wide as immutable bundles, SSM Automation remediates the safe class, and evidence accrues via conformance-pack exports plus Security Hub control status (Audit Manager only if you onboarded before it closed to new customers on 30 April 2026). This post has the tool-per-job matrix, a conformance pack with auto-remediation, and the auto-remediation gotcha to design around.

Key Takeaways

  • A continuous compliance pipeline has four distinct jobs, each owned by a different AWS service, and the mistake is collapsing them into "we have Security Hub on
  • Benchmark pattern (not a cited client): A composite ~30-account org passing point-in-time audits but re-finding the same S3 public-access and unencrypted-EBS drift every quarter, then hand-fixing it
  • The four jobs (and the service that actually does each) Run the decision matrix; the short version: 1
  • 2
  • 3
Continuous Compliance Automation on AWS (2026): Config Conformance Packs, SSM Auto-Remediation, and Audit Manager — Past Security Hub
Table of Contents

Security Hub finds the misconfiguration. It does not deploy your rule baseline across 30 accounts, fix the resource, or assemble the evidence package an auditor asks for, and treating it as if it does is why teams still spend the week before an audit taking screenshots. A continuous compliance pipeline has four distinct jobs, each owned by a different AWS service, and the mistake is collapsing them into “we have Security Hub on.” As of June 2026 the building blocks are mature: AWS Config conformance packs (immutable, org-deployable rule bundles), Systems Manager Automation for remediation, and an evidence layer that depends on when you started: conformance-pack exports + Security Hub control status + CloudTrail Lake or Security Lake for new orgs (AWS closed Audit Manager to new customers on 30 April 2026; existing customers keep their support window). This post maps the jobs to the tools and shows where automation helps and where it causes the outage.

This is for security and platform engineers who already run Security Hub and want a pipeline, not more dashboards. We ship a tool-per-job decision matrix and a Config conformance pack with SSM auto-remediation.

The four jobs (and the service that actually does each)

Run the decision matrix; the short version:

1. Detect drift with AWS Config rules (plus Security Hub to aggregate and score)

Config continuously evaluates resources against rules and marks them compliant/non-compliant; Security Hub aggregates findings and scores you against standards. Detection only; neither fixes anything.

2. Deploy rules at scale with Config conformance packs

Package rules + remediation into an immutable YAML bundle and deploy per-account/Region or org-wide via Systems Manager Quick Setup or StackSets. You stop babysitting individual rules per account. Immutability is the point: to change a rule, you redeploy the pack.

3. Remediate the safe class with SSM Automation wired to Config rules

Associate an SSM Automation document with a Config rule and set Automatic: true with retries. Good first candidates are reversible, low-blast-radius fixes: S3 Block Public Access, EBS encryption-by-default, a missing required tag.

4. Prove it with Config and Security Hub evidence (or Audit Manager if already onboarded)

Default for new orgs (after 30 April 2026): export Config conformance-pack compliance state, capture Security Hub control status against your enabled standards, and query CloudTrail Lake or Security Lake for auditable activity. This is the same technical evidence auditors ask for, without starting on a closed product. If you already run Audit Manager: keep assessments running through your support window; it maps evidence to framework controls (GDPR, HIPAA, PCI DSS, and custom) across accounts via Organizations, with cryptographically verifiable reports and reviewer delegation. Honest limit: neither path assesses whether you are compliant; they collect evidence. They kill the manual scramble; they don’t replace the auditor. Full pipeline context: security & compliance hub.

Opinionated take: deploy a conformance pack detect-only first, confirm the findings are real for your environment, and only then enable remediation on the safe subset. Shipping a 200-rule pack with auto-remediation on across prod on day one is how a “compliance improvement” becomes an outage.

What to do this week

  1. List your recurring compliance findings (the drift you re-find every quarter). That list is your conformance-pack scope.
  2. Deploy a detect-only conformance pack for the top offenders (start with the S3 example) to one OU.
  3. Enable auto-remediation on the safe subset only (encryption, public-access blocks, missing tags). Make the documents idempotent.
  4. If you’re audited against a framework, wire the evidence store now: conformance-pack exports + Security Hub control status + Lake queries for new orgs; keep Audit Manager assessments running only if you onboarded before 30 April 2026.
  5. Route compliance findings to a hardening backlog, not the pager. Keep paging for incident response.

What this post doesn’t cover

Related: Security Hub compliance monitoring · Incident response runbooks · CloudTrail production setup · ISO 27001 on AWS · Cloud compliance services · AWS cloud security

If you only do one thing: Take the misconfiguration you re-discover and hand-fix every quarter, put it in a detect-only conformance pack, and enable auto-remediation only once you’ve confirmed the fix is reversible and idempotent. That single loop is the difference between compliance theater and continuous compliance.

Frequently asked questions

Isn't Security Hub enough for compliance on AWS?
Security Hub is excellent at one job: aggregating findings and scoring your posture against standards like the AWS Foundational Security Best Practices, CIS, and PCI DSS. But that is detection and reporting, not the whole compliance pipeline. A continuous compliance practice has four distinct jobs: detect drift (AWS Config rules, with Security Hub aggregating and scoring), deploy rules at scale (Config conformance packs), remediate the safe class automatically (Systems Manager Automation documents wired to Config rules), and prove it to an auditor (conformance-pack compliance exports, Security Hub control status, and CloudTrail Lake or Security Lake queries for new orgs; Audit Manager evidence collection only if you onboarded before it closed to new customers on 30 April 2026). Teams that treat Security Hub as the entire program keep finding the same misconfigurations manually, fixing them by hand, and scrambling to gather evidence when an audit lands. Security Hub tells you what is wrong; it does not deploy your rule baseline org-wide, fix the resource, or assemble the audit evidence package.
What is an AWS Config conformance pack?
A conformance pack is a collection of AWS Config rules and remediation actions packaged into a single, immutable, deployable entity defined in a YAML template similar to CloudFormation. Individual rules cannot be modified outside the pack, which keeps your compliance baseline tamper-resistant and consistent. Packs give you pack-level compliance reporting and can be deployed to a single account and Region or across an entire AWS Organization using AWS Systems Manager Quick Setup or CloudFormation StackSets. They support automatic remediation through Systems Manager Automation. The practical benefit is that you stop hand-managing dozens of individual Config rules per account and instead deploy and version a curated baseline as one unit. The trade-off of immutability is that changing a rule means redeploying the pack rather than editing it in place.
How does AWS Config auto-remediation work, and what is the gotcha?
You associate a remediation action (either an AWS-managed Systems Manager Automation document or a custom one) with a Config rule, optionally with retry settings, so that when a resource is found non-compliant the SSM document runs to fix it (for example, applying S3 Block Public Access or enabling default encryption). The gotcha to design around is that auto-remediation relies on AWS Config's periodic compliance snapshots, which means it can occasionally trigger on a resource that is already compliant because the evaluation data was stale. The practical consequences: make every remediation document idempotent so a redundant run is harmless, and use the describe-remediation-execution-status CLI command to troubleshoot failed remediations. Start with detect-only, confirm the findings are accurate for your environment, and only then enable the Automatic flag on the safe, reversible subset of rules.
What does AWS Audit Manager do that Config and Security Hub do not?
For existing Audit Manager customers, Audit Manager continuously collects and organizes evidence of your AWS resource configurations and activity, mapping it to framework controls (GDPR, HIPAA, PCI DSS, SOC 2-style, and others) across multiple accounts via AWS Organizations, with cryptographically verifiable assessment reports and reviewer delegation. AWS closed Audit Manager to new customers on 30 April 2026. Existing customers retain their support window, but new engagements should not start there. The replacement evidence path for new orgs: AWS Config conformance packs (regulator-aligned control sets deployable Organization-wide), Security Hub Essentials continuous standards checks, and CloudTrail Lake or Security Lake (OCSF) for the auditable event store: exported Config compliance state plus Security Hub control screenshots plus Lake queries. The honest caveat across both paths: neither Config nor Audit Manager assesses whether you are compliant; they collect technical evidence. They remove the manual scramble; they do not replace the auditor or your judgment. See our [security & compliance hub](/security-compliance/) for the full evidence-pipeline FAQ.
When should we NOT auto-remediate a compliance finding?
Do not auto-remediate any control whose fix could break a running workload or whose blast radius you do not fully understand. The classic self-inflicted outage is an auto-remediation that "fixes" a security group by removing a rule an application actually depends on, or one that flips a setting on a production resource during business hours with no human in the loop. Safe first candidates for automation are reversible, low-blast-radius fixes: enabling S3 default encryption, applying Block Public Access, enabling EBS encryption-by-default, attaching a missing required tag. Anything that changes network reachability, deletes data, or alters production routing should route to human-approved remediation instead: surface the finding, propose the fix, and let an engineer apply it. Automate the boring and reversible; gate the risky.
How do continuous compliance and incident response relate?
They are different layers and should not be conflated. Continuous compliance is about configuration state (is this resource encrypted, is public access blocked, does it carry the required tags), and its findings are drift to be remediated on a backlog cadence, not paged on. Incident response is about active threats, such as a compromised credential or an attack sequence, and those warrant paging. A common anti-pattern is paging the on-call on Security Hub control failures as if they were incidents; they are configuration hygiene, not active compromise. Route compliance findings to auto-remediation or a hardening backlog, route correlated security threats to the incident-response runbooks. Keeping the two streams separate is what stops alert fatigue from burying the one finding that is a real incident.
Share:
Nash Ogden
Nash Ogden

Agentic AI & Cloud Security

Works on making teams more productive with agentic AI. Writes the FactualMinds guides on AWS security and compliance: identity, threat detection, data protection, and audit readiness, the controls AI agents need before they touch production systems.

Agentic AIAI Agent GovernanceAWS SecurityComplianceIAMThreat Detection

Recommended Reading

Explore All Articles »