.svg)
A Practical Guide to Automating SOC 2 on AWS (Compliance as Code)
For most engineering leaders, *SOC 2* is a term that triggers a Pavlovian response of dread. It conjures images of endless spreadsheets, manual screenshot collection, and a six-month fire drill that grinds productivity to a halt. While our Ultimate Guide to SOC 2 Automation covers the platform strategy, this guide dives deeper into the engineering reality.
This is the core idea behind GRC Engineering and its tactical implementation, Compliance as Code (CaC). This approach applies software development principles, such as automation, version control, and testing, to compliance. Instead of proving compliance after the fact, you build it directly into your infrastructure.
This guide provides a practical, hands-on playbook for implementing a robust Compliance as Code strategy for SOC 2 on AWS. We will walk through how to use native AWS services to build a system of continuous, automated compliance that frees your engineers from manual toil and turns your audit into a non-event.
The Core Idea
Instead of proving compliance after the fact, build it directly into your infrastructure. Compliance as Code applies software development principles (automation, version control, testing) to your security and compliance program.
The Foundation: Building an Automated Compliance Engine on AWS
The goal is to create a system that automatically collects evidence and continuously monitors your environment against SOC 2 controls. This replaces error-prone manual checks with an immutable, auditable system of record. AWS provides a powerful, integrated toolchain to build this foundation.
1 AWS CloudTrail: Immutable Audit Trail
CloudTrail records every API call in your account, providing a detailed log of who did what, from where, and when. This is the bedrock of your evidence collection.
- Create a Multi-Region Trail applied to all regions
- Enable Log File Validation so auditors can verify logs have not been tampered with
- Secure Your Log Destination with a dedicated S3 bucket and restrictive bucket policy
2 AWS Config: Continuous Monitoring
AWS Config acts as your 24/7 compliance engine. It continuously scans your AWS resources, evaluates their configurations against predefined rules, and flags any deviations.
- Enable AWS Config to record all supported resources in your region
- Deploy the SOC 2 Conformance Pack (
Operational-Best-Practices-For-SOC-2) to instantly enable dozens of managed rules mapped to SOC 2 controls
3 AWS Audit Manager: Evidence Aggregation
Audit Manager sits on top of CloudTrail and Config, automating the collection and organization of evidence for your audit.
- Create an Assessment in the Audit Manager console
- Select the SOC 2 Framework to automatically map your AWS data sources to specific controls, creating an audit-ready package
Practical Patterns for Key SOC 2 Criteria
With the foundational engine in place, you can implement specific patterns to address the core SOC 2 Trust Services Criteria: Security and Availability.
Automating Security Controls (The Common Criteria)
The Security criterion is mandatory and focuses on protecting systems against unauthorized access.
| Control | AWS Service | What It Does |
| CC6.1 MFA Enforcement | IAM Policies | Deny all actions unless user has authenticated with MFA, providing immutable proof of enforcement |
| CC7.1 Vulnerability Scanning | Amazon Inspector | Continuously scan EC2 instances and container images for software vulnerabilities, providing constant evidence for your vulnerability management program |
Automating Availability Controls
The Availability criterion focuses on ensuring your systems are available for operation as committed or agreed.
| Control | AWS Service | What It Does |
| High-Availability Verification | AWS Config (multi-az-rds-instance-enabled) |
Automatically tests your RDS instances daily, providing evidence that databases are configured for high availability |
| Backup Validation | AWS Backup | Create backup policies applied via tags, automating the backup process and providing centralized evidence that your backup plan is executing as designed |
Shifting Left: Integrating Compliance into Your CI/CD Pipeline
The ultimate goal of GRC Engineering is to prevent non-compliant configurations from ever being deployed. This is achieved by integrating policy checks directly into your CI/CD pipeline.
1 Define Infrastructure as Code (IaC)
Your entire AWS environment should be defined in code using a tool like Terraform. No manual console changes.
2 Implement Policy as Code (PaC)
Use a tool like Open Policy Agent (OPA) to write your compliance rules as code. Policies become version-controlled, testable, and reviewable.
3 Validate in the Pipeline
Add a step before terraform apply that scans the plan against your policies. If a non-compliant change is detected, the pipeline fails. This provides immediate feedback and creates automated evidence that preventative controls are in place.
Why This Matters
The shift-left approach provides immediate feedback to developers, embeds security directly into their workflow, and creates automated evidence that preventative controls are in place. Non-compliant infrastructure never reaches production.
The Future is Engineered Compliance
Adopting a Compliance as Code model on AWS requires an upfront investment of engineering time. However, the return is significant. You move from a state of periodic, painful, and manual compliance to a system of continuous, automated, and proactive security.
This approach doesn't just make audits easier; it builds a fundamentally more secure organization and turns a dreaded obligation into a competitive advantage.
Building an Effective Security Program on AWS?
We help teams implement compliance as code and get SOC 2 right.
Frequently Asked Questions
What is Compliance as Code?
Compliance as Code applies software development principles (automation, version control, testing) to compliance requirements. Instead of manually collecting evidence and checking controls, you define your compliance rules in code and automate their enforcement and monitoring.
Which AWS services are essential for SOC 2 compliance?
The three foundational services are AWS CloudTrail (audit logging), AWS Config (continuous configuration monitoring), and AWS Audit Manager (evidence aggregation). Together, they create an automated compliance engine that maps directly to SOC 2 Trust Services Criteria.
Can AWS Config automatically check SOC 2 controls?
Yes. AWS Config offers a pre-built conformance pack (Operational-Best-Practices-For-SOC-2) that enables dozens of managed rules mapped to SOC 2 controls covering encryption, access management, logging, and more. It continuously evaluates your resources and flags non-compliant configurations.
Do I still need a GRC platform if I use AWS compliance tools?
AWS tools handle the infrastructure-level evidence collection well, but a GRC platform like Secureframe, Vanta, or Drata adds value by covering non-AWS controls (HR, vendor management, policies), centralizing evidence from multiple sources, and streamlining the auditor workflow.
How long does it take to implement Compliance as Code on AWS?
The foundational engine (CloudTrail, Config, Audit Manager) can be set up in a few days. Building out policy-as-code checks in your CI/CD pipeline and custom Config rules typically takes 2-4 weeks depending on the complexity of your infrastructure.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Ali Aleali, CISSP, CCSP
Co-Founder & Principal Consultant, Truvo Cyber
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.