Continuous Compliance: From Audit Project to Audit Posture

Every year the same thing happens. Audit prep starts six weeks before the auditor arrives. Engineers rush to prove that Config rules have been passing, that access reviews happened, that CloudTrail logs were not tampered with. Half the evidence does not exist because nobody was collecting it. The audit takes four weeks of senior-engineer time and the findings list is long. By the time it is over, everyone commits to doing it differently next year. They do not.

Continuous compliance is the alternative. Instead of treating each audit as a project with a start and end date, you build your infrastructure so that evidence is produced automatically, checks run daily, and any failing control is treated like a failing production test. The next audit becomes a formality - the auditor reviews evidence that already exists in searchable, timestamped form. We have built this for SOC 2, ISO 27001, HIPAA, and PCI DSS environments on AWS, and this guide covers exactly how the system works.

Why the Annual Audit Model Breaks Down

The project-based approach has three structural problems that get worse as your AWS footprint grows:

• Evidence is reconstructed from memory, not collected in real time. When the auditor asks for the Q2 access review, the answer is hidden in a Slack thread or a spreadsheet someone deleted.
• Configuration drift accumulates silently. A CloudTrail trail gets disabled for debugging and never re-enabled. An S3 bucket policy is relaxed for a one-time data export and left open. An IAM role receives AdministratorAccess during an incident and nobody removes it. These gaps grow for months with no detection.
• The engineers who can answer auditor questions are the same people building the product. Every audit cycle removes 3-6 weeks of productivity from the senior team. For a 50-person engineering org, that is roughly $80K-$150K in fully loaded cost per audit, not including the external auditor fees.

The fix is not better project management. It is infrastructure that produces audit evidence as a byproduct of normal operations.

The Foundation: AWS Config Rules and Conformance Packs

AWS Config is the foundation of continuous compliance on AWS. It continuously records the configuration state of every resource in your account and evaluates those configurations against rules you define. When a resource violates a rule, Config marks it NON_COMPLIANT and can trigger automated remediation.

AWS provides over 350 managed Config rules. The ones that matter most for compliance frameworks are:

• cloudtrail-enabled and cloud-trail-encryption-enabled - verifies CloudTrail is active in all regions and logs are encrypted with KMS.
• s3-bucket-server-side-encryption-enabled and s3-bucket-ssl-requests-only - enforces encryption at rest and denies non-HTTPS requests.
• s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited - prevents public bucket exposure.
• encrypted-volumes - checks that all EBS volumes use encryption.
• rds-storage-encrypted and rds-instance-public-access-check - enforces RDS encryption and blocks public endpoints.
• iam-root-access-key-check - ensures the root account has no active access keys.
• iam-user-mfa-enabled and root-account-mfa-enabled - enforces MFA on all human accounts.
• access-keys-rotated - flags access keys older than 90 days (configurable).
• restricted-ssh - blocks security groups that allow 0.0.0.0/0 on port 22.
• vpc-flow-logs-enabled - verifies VPC Flow Logs are active for network audit trails.

Rather than enabling these rules individually, deploy a conformance pack. A conformance pack is a YAML template that bundles dozens of Config rules into a single deployable unit mapped to a specific compliance framework. AWS provides pre-built templates:

• Operational Best Practices for HIPAA Security - covers encryption, logging, access controls, and network segmentation rules required under the HIPAA Security Rule.
• Operational Best Practices for PCI DSS 4.0 - maps to PCI requirements for cardholder data protection, access management, and monitoring.
• Operational Best Practices for NIST 800-53 rev 5 - the most comprehensive pack, covering over 150 rules across all NIST control families.
• Operational Best Practices for CIS AWS Foundations Benchmark v1.4 Level 1 and Level 2 - maps to CIS hardening standards for IAM, logging, monitoring, and networking.
• Operational Best Practices for NIST CSF - covers the five NIST Cybersecurity Framework functions: Identify, Protect, Detect, Respond, Recover.

Deploying Conformance Packs With Terraform

Compliance-as-code means your compliance rules are versioned, reviewed, and deployed through the same pipeline as your application infrastructure. Here is how we deploy Config rules and conformance packs with Terraform.

A conformance pack deployment uses the aws_config_conformance_pack resource, pointing to a YAML template stored in S3 or inline. The template defines each rule, its source identifier (the AWS managed rule name), and any input parameters. For example, the access-keys-rotated rule takes a maxAccessKeyAge parameter that defaults to 90 days but can be set to 60 for stricter environments.

For individual rules that need auto-remediation, we pair an aws_config_config_rule resource with an aws_config_remediation_configuration resource. The remediation configuration references an SSM Automation document that performs the fix. For example, the s3-bucket-server-side-encryption-enabled rule pairs with the AWS-EnableS3BucketEncryption SSM document. When Config detects an unencrypted bucket, it calls the SSM document with the bucket name as RESOURCE_ID and applies AES-256 encryption. The remediation runs with up to 3 retry attempts at 60-second intervals.

This pattern works for dozens of common findings: AWS-EnableCloudTrail re-enables a disabled trail, AWS-ConfigureS3BucketPublicAccessBlock restricts a public bucket, AWSConfigRemediation-EnforceHTTPSOnlyAccessToS3Bucket adds an HTTPS-only bucket policy. Each remediation is an SSM Automation document - either AWS-provided or custom. The Terraform code is reviewed in a PR, applied through CI/CD, and the entire compliance configuration lives in version control.

Security Hub: Aggregated Compliance Scoring

AWS Security Hub pulls findings from Config, GuardDuty, Inspector, IAM Access Analyzer, Macie, and Firewall Manager into a single dashboard. It also runs its own set of automated security checks against your resources based on enabled standards.

Security Hub supports seven built-in standards. The ones we enable on every account:

• AWS Foundational Security Best Practices (FSBP) - developed by AWS. Covers over 200 controls across IAM, S3, RDS, Lambda, ECS, EC2, and more. This is the broadest standard and catches the most issues.
• CIS AWS Foundations Benchmark v5.0.0 - the latest version, published by CIS in March 2025, with 40 automated controls across identity, storage, logging, monitoring, and networking. Security Hub has CIS certification for both Level 1 and Level 2.
• PCI DSS v3.2.1 - maps Security Hub controls to PCI requirements. Required if you process or store cardholder data.
• NIST SP 800-53 Rev. 5 - the federal standard, but widely used by commercial companies pursuing FedRAMP or working with government customers.

Security Hub gives each enabled standard a compliance score from 0 to 100 percent based on the ratio of passing to failing controls. We set a threshold: anything below 90 percent triggers an alert. Below 80 percent triggers an incident. The auditor can open the Security Hub console and see the current score in real time - that is the kind of evidence that makes audits fast.

AWS Audit Manager: Automated Evidence Collection

AWS Audit Manager sits on top of Config, Security Hub, and CloudTrail to automate the evidence-collection step of an audit. You create an assessment, pick a framework (SOC 2, HIPAA, PCI DSS 4.0, CIS Benchmark, or a custom framework), define the AWS accounts in scope, and Audit Manager starts collecting evidence automatically.

Evidence comes from four sources: automated snapshots of resource configurations (from Config), compliance check results (from Security Hub and Config rules), user activity logs (from CloudTrail), and manual evidence you upload (policies, meeting minutes, training records). Audit Manager organizes all of this by control, so when the auditor asks about CC6.1 (logical access), you open the corresponding control folder and every piece of evidence is there - timestamped, linked to the source, and exportable.

In July 2025, AWS updated 14 Audit Manager frameworks to improve evidence relevance and reduce noise. The SOC 2 and PCI DSS 4.0 frameworks now map more precisely to specific Config rules and Security Hub findings, which means less manual curation of evidence packages. For existing assessments created before June 2024, you need to create new assessments to pick up the updated mappings.

The Remediation Pipeline: EventBridge, Lambda, and SSM

Detection without remediation is just a dashboard of problems. The real value of continuous compliance is completing the cycle: detect a violation, fix it automatically or semi-automatically, and log the remediation as evidence.

The architecture works like this: Security Hub publishes every finding as an event to Amazon EventBridge. An EventBridge rule matches findings by severity, standard, or resource type and routes them to a target - typically a Lambda function or a Step Functions workflow. The Lambda function performs the remediation (enable encryption, restrict a security group, disable an unused access key) and sends a notification to an SNS topic. The remediation action is logged in CloudTrail, which Audit Manager picks up as evidence.

We use two models depending on the risk level of the remediation:

• Fully automatic - for low-risk, high-confidence fixes. Enabling S3 default encryption, enabling EBS encryption on new volumes, blocking public access on a bucket, re-enabling CloudTrail. These run without human approval.
• Semi-automatic - for changes that could affect production. Restricting a security group, rotating an access key, modifying an IAM policy. The Lambda function creates a ticket, tags the resource, and sends a Slack notification. An engineer approves the fix through a Security Hub custom action, which triggers a second EventBridge rule to execute the remediation.

AWS also provides a pre-built solution - Automated Security Response on AWS - that deploys Step Functions workflows, Lambda functions, and EventBridge rules handling dozens of common CIS and FSBP remediation scenarios as a CloudFormation stack. It is a good starting point, though we usually extend it with custom remediations specific to the customer's architecture.

Drift Detection: Catching What Config Rules Miss

Config rules catch resource-level compliance violations, but they do not catch infrastructure drift - the gap between what Terraform says should exist and what actually exists in AWS. Someone makes a manual change in the console, or an automation script modifies a resource outside the Terraform state. The Config rule might still pass (the resource is configured correctly) but your infrastructure-as-code is now out of sync.

We address drift at three levels:

• Terraform plan in CI - run terraform plan on a schedule (daily or on every PR merge) and alert if there are unexpected changes. If the plan shows resources to update or destroy that nobody changed in code, someone made a manual change.
• CloudFormation drift detection - if you use CloudFormation for any stacks, enable drift detection and check results weekly. CloudFormation compares actual resource properties against the template and flags differences.
• CloudTrail analysis - monitor CloudTrail for console-based API calls (identified by the userAgent field containing 'console.amazonaws.com'). In a well-run IaC environment, nearly all changes should come from CI/CD pipelines or automation roles, not human console sessions. We set up an EventBridge rule that alerts on any console-based write action in production accounts.

Compliance Automation Platforms: Vanta, Drata, and Secureframe

Third-party compliance platforms aggregate evidence from AWS, SaaS tools (GitHub, Okta, HRIS systems), and endpoint management into a single dashboard. They map evidence to framework controls and generate reports for auditors. The three leaders are Vanta, Drata, and Secureframe.

Here is what each one does well:

• Vanta - 375+ integrations, 35+ supported frameworks including SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, and SOX. Strong AWS integration that connects to 40+ AWS services including EC2, S3, IAM, and GuardDuty. Fast initial setup. AI-powered policy generation and control mapping. Pricing ranges from $10K-$80K/year depending on company size and framework count. Best for startups that need to achieve SOC 2 certification quickly.
• Drata - 26+ frameworks, deep DevOps integrations. Functions more as a control engine than a checklist tool. Starts at roughly $7.5K/year for the Essential plan, scales to $20K-$50K/year with added frameworks and API access. 8,000+ customers. A better fit for companies with mature engineering teams and complex multi-framework requirements.
• Secureframe - 35+ frameworks including FedRAMP and CMMC, which the others support less deeply. Guided audit support with access to a network of audit firms. Good for organizations navigating their first compliance cycle who want more guided support through the process.

Important: these platforms do not replace correct AWS configuration. Vanta cannot fix a misconfigured CloudTrail - it will only show you the failure in a nicer interface. Our recommendation is to configure the AWS-native controls correctly first (Config conformance packs, Security Hub standards, GuardDuty, Audit Manager), then add a compliance platform for SaaS evidence aggregation and auditor-facing reports. Running Vanta on a misconfigured AWS environment gives you a dashboard full of failures that nobody has time to fix.

Also consider total cost of ownership. Beyond the platform license, expect framework add-ons ($5K-$15K each), bundled penetration testing ($4K-$10K), and external auditor fees ($8K-$25K annually for SOC 2 or ISO audits). A realistic first-year cost for SOC 2 certification including platform, auditors, and remediation work is $40K-$100K.

The People and Process Layer

Tools and automation handle 70-80 percent of continuous compliance. The remaining 20-30 percent is process: access reviews, policy updates, vendor risk assessments, security awareness training, incident response drills. These require human judgment and documentation.

The teams that sustain continuous compliance over multiple audit cycles have these traits:

• A named compliance owner who is not the CTO. This can be a fractional hire, a consultant retainer, or a senior engineer with dedicated time. 'The whole engineering team is responsible' means nobody is responsible.
• A monthly 60-minute compliance review where Config findings, Security Hub scores, and open remediation tickets are reviewed by severity. Not a panic session - a routine meeting on the calendar.
• Engineers understand the mapping between technical controls and framework requirements. They know that the s3-bucket-public-read-prohibited Config rule maps to SOC 2 CC6.6 (data protection) and that restricted-ssh maps to CC6.7 (network security). This shared vocabulary means they fix findings because they understand the audit impact, not because someone told them to.
• Quarterly access reviews are driven by identity-source exports (from IAM Identity Center, Okta, or your HRIS), not manual spreadsheets. The review takes 2-3 hours, not 2-3 days, and produces a documented sign-off that the auditor can verify.

Setting It Up: The 6-Week Implementation

We typically implement continuous compliance in a 6-week engagement. Here is the week-by-week breakdown:

1. Weeks 1-2: Scope and baseline. Identify the compliance framework (SOC 2, ISO 27001, HIPAA, PCI), define the AWS accounts and services in scope, and run a gap assessment against the target framework. Enable AWS Config recording across all accounts and regions.
2. Week 3: Deploy conformance packs and Security Hub standards. Enable GuardDuty, Inspector, and IAM Access Analyzer in all regions. Set up the centralized CloudTrail with log-file validation and immutable S3 storage.
3. Week 4: Build the remediation pipeline. Deploy EventBridge rules for high-priority findings, Lambda functions for automatic remediation, and Slack/PagerDuty integration for semi-automatic items. Configure Audit Manager assessments for the target framework.
4. Week 5: Remediate the initial findings. The first conformance pack deployment typically surfaces 30-80 findings depending on the maturity of the environment. Fix the critical and high items, document accepted risks for anything that cannot be remediated immediately.
5. Week 6: Operationalize. Set up the monthly review cadence, train the team on the compliance dashboard, document the process for handling new findings, and hand off to the internal compliance owner.

After the initial 6 weeks, ongoing maintenance takes 4-8 hours per month: reviewing new findings, updating Config rules as AWS adds new managed rules, running access reviews, and preparing for the annual audit (which now takes days instead of weeks).

We have built this for SaaS companies, healthcare platforms, fintech startups, and public-sector vendors on AWS. The frameworks differ, but the architecture is the same: Config rules for resource compliance, Security Hub for aggregation, Audit Manager for evidence, EventBridge and Lambda for remediation, and Terraform for everything-as-code. If you want to see how this maps to your specific environment, contact us - we do a free compliance readiness assessment.