SOC 2 on AWS: Automate Compliance with Config & Security Hub
Learn how to map SOC 2 controls to AWS Config and Security Hub, automate security remediation, manage compliance exceptions, and build audit-ready evidence across multiple AWS accounts.
SOC 2 on AWS: Mapping Controls to AWS Config Rules and Security Hub
How to build continuous compliance, automate remediation, manage exceptions, and produce audit-ready evidence across enterprise AWS accounts.
Your AWS Security Hub dashboard is green.
CloudTrail is enabled. S3 buckets are protected. Databases are encrypted. Your Config rules show healthy compliance.
Then your SOC 2 auditor asks:
“Can you prove these controls worked consistently throughout the last six months?”
Suddenly, your green dashboard isn't enough.
You need configuration history.
Access approvals.
Remediation records.
Documented exceptions.
Evidence showing who reviewed failures, what changed, and when those changes were verified.
And if your organization operates 25 AWS accounts across several Regions, that problem becomes considerably harder.
Here's the uncomfortable truth:
Most cloud teams automate security checks. Far fewer automate the evidence needed to demonstrate that their security processes actually work.
That's the real challenge of SOC 2 on AWS.
Not enabling more security services.
Connecting security controls, infrastructure automation, operational accountability, and evidence collection into one repeatable system.
In this guide, we'll connect AWS Config, Security Hub CSPM, AWS Organizations, Lambda, Systems Manager Automation, EventBridge, and Audit Manager into a practical enterprise compliance architecture.
We'll also cover the problems that don't appear in simple tutorials: multi-account governance, custom controls, escalating Config costs, exception management, and audit evidence overload.
Because passing an audit once is useful.
Building a cloud environment that can continuously demonstrate its controls is much more valuable.
1. First, Understand What SOC 2 Actually Requires
SOC 2 is an attestation framework based on the AICPA Trust Services Criteria.
It addresses five categories:
| Category | What it evaluates |
|---|---|
| Security | Protection against unauthorized access |
| Availability | Systems available according to commitments |
| Processing Integrity | Complete, accurate, timely, and authorized processing |
| Confidentiality | Protection of designated confidential information |
| Privacy | Appropriate handling of personal information |
Security is the required foundation. Other categories are included based on the organization's scope and commitments.
Here's where cloud engineers often misunderstand the framework.
SOC 2 doesn't require a specific AWS service.
It doesn't say every company must use AWS Config or Security Hub.
Instead, organizations must demonstrate that applicable controls are appropriately designed and, for Type II examinations, operate effectively over the assessment period.
Type I versus Type II
SOC 2 Type I: Examines control design at a specified point in time.
SOC 2 Type II: Also examines the operating effectiveness of controls over a defined period.
This distinction determines your evidence strategy.
A passing AWS Config rule today can help demonstrate the current state.
But it doesn't automatically prove the control operated effectively throughout the examination period.
That requires historical evaluations, change records, and evidence of operational response.
A green dashboard is a snapshot. A mature control program produces a defensible history.
2. Map SOC 2 Controls to AWS Config and Security Hub
The first practical step is translating governance objectives into technical checks.
SOC 2 defines control objectives and criteria.
AWS Config evaluates resource configurations.
Security Hub CSPM identifies security control findings.
AWS Audit Manager collects supported evidence.
But these aren't interchangeable.
One AWS Config rule can support a SOC 2 objective without satisfying the entire organizational control.
Here's a practical starting matrix.
| SOC 2 area | AWS Config rule | Security Hub CSPM control |
|---|---|---|
| CC6.x — Privileged access | iam-policy-no-statements-with-admin-access | IAM.1 |
| CC6.x — IAM console MFA | mfa-enabled-for-iam-console-access | IAM.5 |
| CC6.x — S3 public access | s3-bucket-level-public-access-prohibited | S3.8 |
| CC6.x — Public SSH access | restricted-ssh | EC2.13 |
| CC6.x / C1.x — Database encryption | rds-storage-encrypted | RDS.3 |
| CC7.x — Management activity logging | multi-region-cloudtrail-enabled | CloudTrail.1 |
| CC7.x — S3 server access logging | s3-bucket-logging-enabled | S3.9 |
These are example technical mappings, not official one-to-one AICPA equivalencies.
The auditor evaluates the suitability and effectiveness of the complete control.
Example: Restricting public SSH access
Security Hub CSPM control EC2.13 checks whether security groups permit unrestricted inbound SSH access on port 22.
The underlying AWS Config rule is:
restricted-sshIf an applicable security group allows SSH from
0.0.0.0/0 or ::/0, the check fails.That's meaningful technical evidence.
But it's only part of the story.
An auditor may also want to know:
- Who owns the security group?
- Who approved the network change?
- How quickly was the exposure detected?
- What happened after detection?
- Was an exception approved?
- Was remediation verified?
Configuration monitoring tells you what happened. Operational records explain how your organization handled it.
This is why a control mapping should include more than rule names.
Every important control needs an evidence source, an accountable owner, and a defined response process.
3. Enterprise Reality: SOC 2 Across Multiple AWS Accounts
Imagine a fictional SaaS company, AtlasCloud.
It operates:
- 10 production AWS accounts.
- 8 development and staging accounts.
- 4 shared infrastructure accounts.
- 3 security and administrative accounts.
The company uses several AWS Regions.
An engineer enables Security Hub in one account.
Another configures AWS Config in a different Region.
A third creates a custom compliance rule.
The result?
Several security dashboards. Inconsistent coverage. No reliable organization-wide picture.
This is why enterprise compliance architecture starts with AWS Organizations.
Use delegated administrator accounts
AWS Organizations provides centralized account governance.
For a scalable security architecture, separate the organization management account from everyday security operations.
A typical structure looks like this:
AWS Organizations management account
Used for organizational administration and service delegation.
Security tooling account
Houses centralized Security Hub CSPM administration and security orchestration.
Audit and compliance account
Runs Audit Manager assessments and coordinates evidence review.
Workload accounts
Run production applications, databases, networking, and supporting services.
Security Hub CSPM supports centralized configuration using a delegated administrator.
You can define security policies at the organizational unit level and manage security controls across linked Regions.
Audit Manager also supports delegated administration, although its regional setup is separate.
A delegated Audit Manager administrator must be designated in each Region where required, preferably using the same account.
Add AWS Control Tower
AWS Control Tower adds structured landing zone governance.
It supports preventive, detective, and proactive controls.
For example:
- Preventive controls can restrict prohibited actions.
- Detective controls identify undesirable configurations.
- Proactive controls can evaluate supported CloudFormation resources before provisioning.
A new account can be provisioned with a consistent governance foundation.
However, optional Control Tower controls and monitoring integrations must still be configured and validated.
The important objective is consistent onboarding.
When AtlasCloud creates account number 26, its security baseline shouldn't depend on an engineer remembering 15 manual steps.
The best security baseline is the one that doesn't depend on memory.
4. Managed Config Rules Are Not Enough: The Custom Lambda Reality
AWS Config managed rules are valuable.
They cover common misconfigurations such as public access, insecure networking, missing encryption, and insufficient logging.
But enterprise governance is rarely limited to generic AWS security recommendations.
Organizations also need to enforce internal business policies.
Consider resource ownership.
A company may require every production resource to identify:
OwnerCostCenterDataClassification
These tags help teams determine resource ownership, allocate costs, and understand data handling requirements.
Start with the AWS Config required-tags rule
AWS already provides a managed rule called:
required-tagsIt checks whether supported resources contain specified tags and can evaluate up to six tag requirements.
For straightforward mandatory tagging, this should be your first option.
You don't need to write Lambda code just to verify that a supported EC2 instance has a
CostCenter tag.But what happens when company policy becomes more sophisticated?
Suppose AtlasCloud requires:
Ownermust reference a valid internal team identifier.CostCentermust match a defined accounting format.DataClassificationmust contain an approved value.- Production databases classified as Restricted must have a valid ownership assignment.
- Certain combinations of tags must trigger additional validation.
Those requirements can exceed what a standard managed rule conveniently expresses.
Build an AWS Config Custom Lambda Rule
AWS Config supports custom rules backed by AWS Lambda.
The workflow is straightforward.
Step 1: Define the policy
A simplified organizational tagging policy might look like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Required:
Owner
CostCenter
DataClassification
Allowed classifications:
Public
Internal
Confidential
Restricted
CostCenter pattern:
CC-####
Additional condition:
Restricted resources require
an approved owner identifier.This is illustrative policy logic, not an AWS Config configuration file.
Step 2: Implement the evaluation function
Create a Lambda function that inspects applicable resource configuration data and evaluates organizational requirements.
Step 3: Return the evaluation
Use AWS Config's
PutEvaluations API to report outcomes such as:COMPLIANTNON_COMPLIANTNOT_APPLICABLEThe evaluation should include the relevant resource identity, resource type, and appropriate ordering timestamp.
Step 4: Configure evaluation triggers
Custom Lambda rules may evaluate configurations after relevant changes or periodically, depending on their implementation.
Step 5: Deploy at organizational scale
Use AWS Config organization rules or conformance packs where suitable, with appropriate cross-account roles and permissions.
AWS also provides the Rule Development Kit (RDK) to simplify development, deployment, and testing of Lambda-backed rules.
When should you use Guard instead of Lambda?
AWS Config also supports Custom Policy Rules written in the CloudFormation Guard language.
Use Guard when the requirements can be expressed cleanly as configuration policies.
Choose Lambda when the evaluation genuinely needs more complex logic, supported external context, or custom API operations.
Don't introduce serverless code where a managed rule or declarative policy is sufficient.
Custom rules create ongoing engineering responsibilities: testing, versioning, runtime maintenance, permissions, evaluation costs, and failure monitoring.
Connect custom rules to audit evidence
AWS Audit Manager supports mapping AWS Config custom rules to custom assessment controls.
Custom AWS Config evaluations can also be sent into Security Hub CSPM through the AWS Config integration when enabled.
But that doesn't automatically turn your custom rule into an AWS-defined, numbered Security Hub CSPM security control.
Preserve that distinction in your architecture and documentation.
AWS managed rules establish a foundation. Custom controls translate your organization's own security policies into measurable behavior.
5. Detection Is Only Half the Job: Automate Remediation With Systems Manager
A failed security control is a signal.
It isn't a solution.
Suppose a developer accidentally opens SSH access to the internet.
Security Hub CSPM reports an EC2.13 failure.
Now what?
In an immature environment, the finding waits for someone to notice it.
In a mature environment, the finding enters a defined response workflow.
The AWS-native remediation architecture
- AWS Config evaluates the relevant resource.
- Security Hub CSPM generates a finding for EC2.13.
- Amazon EventBridge matches the finding.
- An approved workflow initiates remediation.
- AWS Systems Manager Automation runs the selected remediation document.
- AWS Config and Security Hub provide subsequent evaluation results.
- The response system records the outcome.
One relevant Systems Manager runbook is:
AWS-DisablePublicAccessForSecurityGroupThis AWS-managed runbook is designed to remove certain unrestricted SSH and RDP exposures.
It can be useful for narrowly defined remediation policies.
But it isn't a universal security group repair tool.
AWS documents specific conditions where the runbook can fail, including certain non-default VPC configurations.
Always test its behavior against your networking architecture before production deployment.
Automatic versus approval-based remediation
Not every failure should trigger an immediate infrastructure change.
Consider two scenarios.
Scenario A: An unintended public SSH rule
Your team may approve a narrowly scoped automatic remediation workflow.
Scenario B: A production database requires an encryption architecture change
That may involve downtime, backups, dependencies, and an approved maintenance window.
Automatic remediation could create greater operational risk.
A mature workflow categorizes the findings.
Low-risk, well-understood remediation can be automated.
Higher-impact remediation requires approval and change management.
Preserve the execution trail
An effective remediation record should show:
- Finding identifier.
- Affected AWS account and resource.
- Detection timestamp.
- Automation execution identifier.
- Runbook used.
- Approval, if required.
- Action outcome.
- Verification evidence.
- Related engineering ticket.
If remediation fails, the system should escalate rather than silently discard the failure.
Also design for duplicate findings, retries, stale resource states, and cross-account IAM permissions.
Automation isn't mature because it runs without humans. It's mature because its decisions and failures are predictable.
6. Handle Exceptions Properly: Security Hub SUPPRESSED Is Not PASSED
Here's a real-world governance problem.
A security finding appears.
The team investigates it and decides that the existing configuration is acceptable under a documented business exception.
For example, a designated S3 bucket is intentionally used to serve public content.
The finding may be valid.
But the business may have approved that design after evaluating the associated risks and safeguards.
Should the team repeatedly remediate it?
No.
Should the team simply delete or ignore the finding?
Also no.
This is where formal exception management matters.
Use Security Hub workflow status
Security Hub CSPM findings support workflow statuses including:
NEWNOTIFIEDSUPPRESSEDRESOLVED
Setting a finding's workflow status to
SUPPRESSED indicates that the finding was reviewed and no action is currently considered necessary.You can change the workflow status in the console or programmatically through
BatchUpdateFindings.A finding update can also include a note explaining the decision.
For example:
1
2
3
4
5
6
7
Workflow.Status: SUPPRESSED
Note:
Approved exception EXC-2026-041.
Public-content bucket.
Owner: Web Platform Team.
Review due: 2027-01-15.This is an illustrative record.
Actual approvals, dates, and ownership should be maintained in an authoritative governance system.
Here's the distinction that matters
Suppressing a finding does not make the underlying resource compliant.
A finding can retain a failed compliance evaluation while its investigation workflow status is
SUPPRESSED.Security Hub CSPM also excludes suppressed findings when calculating the overall status of the relevant security control.
That means your aggregate dashboard may look healthier after suppression without any infrastructure change.
Your reporting must make that distinction visible.
Suppression is an operational decision—not proof of technical remediation.
Also, changing the status of one finding doesn't prevent new findings from being generated for the same issue.
Connect approved exceptions to Jira
For organizations using Jira, EventBridge can route relevant Security Hub CSPM findings into a custom integration.
A Lambda function or other integration service can create or update a Jira issue.
That issue might record:
- Security Hub finding ID.
- Affected account and resource.
- Exception justification.
- Risk classification.
- Assigned engineering owner.
- Approver.
- Approval date.
- Expiration or review date.
- Compensating controls.
If the organization wants two-way synchronization, it can build a workflow where approved Jira actions update the associated Security Hub finding through the AWS API.
However, this is not a built-in automatic bidirectional synchronization feature.
You must implement authentication, authorization, field mapping, webhook processing, retries, and safeguards against synchronization loops.
Don't allow an arbitrary Jira status change to suppress a critical security finding without an authorized decision.
Don't create permanent exceptions by accident
A strong exception has a review date.
It also has an owner and a documented reason.
Automated suppression rules can be useful for carefully defined recurring cases, but should not become a mechanism for hiding genuine risk.
Periodically review suppressed findings.
When an exception expires, reassess the affected resource and take the appropriate action.
An exception without ownership or review is just risk waiting to be forgotten.
7. AWS Config Cost Optimization: The Problem That Appears at Scale
AWS Config can generate significant costs in environments with frequent resource changes and large numbers of rule evaluations.
Consider a platform that runs EC2 Auto Scaling groups, temporary development infrastructure, and frequently created or terminated compute resources.
Every supported resource's relevant configuration changes can contribute to recorded configuration items.
Multiply that across AWS accounts and Regions.
Costs can grow faster than expected.
Optimize global IAM recording
Legacy global IAM resource types include IAM users, groups, roles, and customer-managed policies.
AWS Config supports recording those resources in appropriate Regions, subject to regional restrictions.
Avoid unnecessarily duplicating global IAM recording and related evaluations across Regions.
But validate the configuration against Security Hub CSPM's actual requirements.
Not every global AWS resource has identical recording behavior.
Use daily recording where appropriate
AWS Config supports continuous and daily recording for eligible resource types.
Continuous recording provides granular configuration change visibility.
Daily recording captures a less frequent configuration history and can reduce recorded configuration item volume.
The tradeoff is important.
A resource can change several times before its daily recording.
That can reduce the ability to reconstruct temporary configurations.
For critical security controls, continuous recording may be warranted.
For lower-risk resources, daily recording may be acceptable when justified by policy and evidence requirements.
Understand high-churn workloads
EC2 Spot Instances, Auto Scaling, and EMR environments can produce substantial configuration recording activity.
EKS and Fargate workloads also require careful analysis of their supported underlying AWS resource types.
Don't assume AWS Config records every Kubernetes pod or individual container lifecycle event.
Evaluate actual resource coverage and billing data.
Watch service-linked recorders
Security Hub CSPM can use AWS Config service-linked recorders when the relevant AWS services are enabled.
These are distinct from customer-managed recording configurations.
Before making cost-control changes, identify which recorder supports each workload and compliance requirement.
Don't disable recording simply because the same resource appears in multiple monitoring systems.
Measure before optimizing
Track configuration item volume, rule evaluation count, account and Region distribution, and high-churn resource types.
Use billing tools to connect cost changes to recording behavior.
The goal isn't minimum monitoring cost. It's reliable control evidence without paying for unnecessary duplication.
8. Shift Left: Stop Misconfigurations Before Deployment
Runtime controls are essential.
But they're reactive.
AWS Config generally evaluates deployed resource configurations, while Security Hub CSPM reports the resulting security control findings.
A stronger architecture adds preventive checks before infrastructure reaches production.
Introduce policy-as-code
Tools such as CloudFormation Guard and Checkov can validate infrastructure definitions before deployment.
Terraform-focused scanning capabilities available through Trivy and related tools can also help.
A typical process:
Developer opens a pull request.
CI/CD runs policy checks.
Misconfigurations fail the pipeline.
The developer corrects the issue.
Approved changes proceed to deployment.
For example, a pipeline can reject a Terraform change that violates the organization's S3 public-access policy.
But the scanner alone isn't a preventive control.
The repository must enforce the required passing check through branch protection or equivalent merge restrictions.
And alternate deployment paths must be appropriately controlled.
A user with unrestricted direct infrastructure permissions may still bypass the pipeline.
What auditors can review
Useful evidence includes:
- Version-controlled policies.
- Pull request approvals.
- CI/CD security scan results.
- Required status-check configurations.
- Deployment records.
- Exception approvals.
- Change management tickets.
For supported use cases, AWS Config Custom Policy Rules can also perform proactive resource evaluations, and AWS Control Tower provides proactive controls for supported CloudFormation provisioning.
Don't rely only on detecting insecure infrastructure. Make insecure changes harder to deploy in the first place.
9. The Audit Manager Data Dump Problem Nobody Talks About
Now imagine you've built all these controls.
Your AWS Config rules are active.
Security Hub is collecting findings.
Custom Lambda policies are evaluating resource ownership.
Systems Manager is recording remediation executions.
Your exception workflow is documented.
AWS Audit Manager is collecting supported evidence.
Everything sounds ready.
Then you generate the assessment report.
And realize that collecting evidence was only half the work.
The difference between evidence and explanation
AWS Audit Manager can produce a downloadable assessment report archive.
The ZIP contains a report summary, supporting files, and evidence organized through nested folders by control, data source, and date.
It includes PDF-based report and evidence navigation.
Your broader evidence package may also contain JSON exports, CSV reports, configuration histories, CI/CD logs, and ticket records from associated systems.
Technically rich?
Absolutely.
Easy for every auditor to interpret?
Not necessarily.
An auditor shouldn't need to reverse-engineer your AWS architecture to determine whether a control operated effectively.
Don't confuse volume with audit quality
A large collection of technical records is not automatically persuasive evidence.
The reviewer needs to understand:
- What control is being tested?
- Which systems are in scope?
- What does the technical result demonstrate?
- When was the control evaluated?
- Did the control fail?
- What happened after failure?
- How was the outcome verified?
If those answers are buried inside hundreds of exported files, the audit process becomes slower than necessary.
Build an auditor-friendly evidence summary
For every significant technical control, create a concise explanation linked to its supporting records.
Consider this example:
Control objective: Restrict public SSH access to production resources.
| Evidence field | Example |
|---|---|
| Control reference | CC6.x |
| Technical check | Security Hub EC2.13 |
| AWS Config rule | restricted-ssh |
| Scope | In-scope production accounts |
| Owner | Cloud Security Engineering |
| Monitoring frequency | Per documented evaluation behavior |
| Failure response | Ticket or approved SSM automation |
| Exception policy | Documented approval and review |
| Verification | Subsequent Config/Security Hub evaluation |
| Supporting records | Findings, tickets, execution details |
Now add a short human-readable control narrative.
For example:
"The control monitors applicable production security groups for unrestricted SSH exposure. Findings are routed to the responsible team. Approved remediation workflows close eligible exposures, while exceptions require documented approval and review. Supporting evaluations and response records are retained for examination."
That paragraph does something raw evidence cannot.
It explains what the organization intended and how the supporting records relate to that intent.
Preserve traceability
Do not replace original evidence with an unsupported summary.
The narrative should link to original evidence identifiers, timestamps, and relevant records.
If you're generating custom reports programmatically, consider fields such as:
ControlIDAccountIDResourceIDEvaluationTimeComplianceStatusFindingIDRemediationReferenceExceptionReference
Only include fields actually supported by the underlying evidence.
Keep the original records available and protect sensitive data through appropriate access controls.
Audit Manager is an evidence source, not an audit verdict
AWS explicitly states that assessment reports do not evaluate the compliance of the underlying evidence.
They organize the records for review.
And Audit Manager doesn't directly collect evidence from most AWS Config service-linked rules, including rules created for many Security Hub CSPM controls.
For these cases, map to supported Security Hub CSPM evidence sources or independently managed Config rules as appropriate.
Automate evidence collection. Then engineer the evidence presentation for humans.
This final step often determines whether an audit feels controlled or chaotic.
10. A Practical 30-Day SOC 2 AWS Implementation Roadmap
You won't complete every SOC 2 requirement in 30 days.
But you can build the technical foundation for continuous evidence collection.
Week 1: Define Scope and Ownership
Map applicable SOC 2 criteria to AWS services, controls, and manual processes.
Identify in-scope accounts and Regions.
Assign technical control owners.
Configure or verify delegated administration.
Document your initial control-to-evidence matrix.
Deliverable: Approved technical scope and control ownership map.
Week 2: Build the Compliance Baseline
Enable relevant AWS Config recording and rules.
Configure Security Hub CSPM across organizational units.
Deploy managed rules and justified custom controls.
Test Lambda-based evaluations.
Review IAM global-resource recording and Config cost drivers.
Deliverable: Centralized technical monitoring and initial rule coverage.
Week 3: Automate Response and Exceptions
Implement EventBridge routing.
Test SSM Automation runbooks.
Configure cross-account execution roles.
Establish exception approvals and Security Hub suppression procedures.
Connect engineering tickets where appropriate.
Add policy-as-code checks to CI/CD.
Deliverable: Tested detection, response, and exception management workflows.
Week 4: Validate Evidence and Auditor Reporting
Configure Audit Manager assessments.
Verify automated evidence collection.
Test a complete finding-to-remediation workflow.
Create a control-level evidence summary.
Review exception and remediation records.
Document missing coverage and follow-up actions.
Deliverable: An initial auditor-readable evidence package and prioritized remediation backlog.
The key is to test the entire chain.
Not just whether AWS Config reports a result.
But whether the team can demonstrate what happened before, during, and after a meaningful control deviation.
11. Measure Compliance as an Operational System
A mature compliance program measures more than passing checks.
Consider the following operational metrics.
| Metric | What it reveals |
|---|---|
| Asset monitoring coverage | Whether important resources are monitored |
| Control evidence coverage | Whether mapped controls have supporting records |
| Evidence freshness | Whether records cover the required period |
| Mean time to detect | How quickly issues become visible |
| Mean time to remediate | How quickly findings are addressed |
| Automation success rate | Whether remediation workflows are reliable |
| Recurring findings | Whether root causes remain unresolved |
| Exception age | Whether accepted risks receive timely review |
| Config cost per account | Whether monitoring costs are sustainable |
| Evidence review completion | Whether controls receive required human oversight |
These metrics support continuous improvement.
They don't replace SOC 2 control testing or auditor judgment.
But they help expose gaps before an examination begins.
Because a compliance failure often starts months before the audit.
A missing account.
A broken evidence collector.
An unreviewed exception.
A remediation workflow that silently failed.
A resource without an owner.
The audit merely reveals the problem.
12. Seven Production Lessons Every Cloud Ops Engineer Should Know
1. Centralize governance, not necessarily every workload.
AWS Organizations and delegated administration provide consistency without requiring application workloads to run in one account.
2. Use managed rules before writing custom code.
Start with AWS Config managed rules such as
required-tags. Add Lambda or Guard when organizational policies genuinely require them.3. Don't confuse suppression with remediation.
SUPPRESSED is a workflow decision. It does not change a failed technical configuration into a passing one.4. Automate carefully.
Systems Manager Automation is powerful, but not every change is safe without approval.
5. Optimize Config costs using real resource data.
Don't exclude resources blindly or sacrifice necessary historical coverage to reduce a bill.
6. Enforce security before deployment.
Policy-as-code, protected branches, and controlled deployment permissions can prevent many problems that runtime monitoring would otherwise detect.
7. Make evidence understandable.
Technical evidence is only useful when reviewers can determine what it proves, where it came from, and which period it covers.
13. The Bigger Lesson: Compliance Is an Engineering Discipline
Let's return to AtlasCloud.
At the beginning, its team was exporting screenshots, manually collecting configuration histories, and chasing engineers for evidence.
Then the architecture changed.
AWS Organizations standardized governance across accounts.
AWS Config continuously evaluated relevant configurations.
Custom Lambda rules checked organizational policies that generic rules couldn't fully express.
Security Hub CSPM helped surface important findings.
EventBridge and Systems Manager Automation supported controlled remediation.
Jira workflows preserved the context behind approved exceptions.
Policy-as-code reduced the chance of insecure deployments.
Audit Manager organized supported evidence.
And human-readable control summaries gave auditors a practical path from a security objective to the underlying records.
The company didn't eliminate all security findings.
No realistic architecture can promise that.
But it established a process for detecting deviations, assigning responsibility, responding appropriately, and explaining the outcome.
That's the difference between an audit project and a mature control environment.
Compliance is not a collection of screenshots.
It's the ability to demonstrate that your organization consistently operates the controls it claims to operate.
The most effective cloud engineering teams don't build security just for audit season.
They build repeatable infrastructure, clear ownership, controlled changes, reliable remediation, and traceable evidence.
Then audit preparation becomes less about reconstructing the past.
And more about reviewing a system that has been operating all along.
Don't automate compliance paperwork while leaving security operations inconsistent.
Automate the controls.
Engineer the response.
Document the exceptions.
Curate the evidence.
Keep humans accountable.
The goal isn't to look compliant on audit day.
The goal is to operate securely every day—and have the evidence to prove it.
Official Technical References
- AWS Config — Required Tags Managed Rule
- AWS Config — Custom Lambda Rules
- AWS Config — Custom Policy Rules
- Security Hub CSPM — Central Configuration
- Security Hub CSPM — Findings Workflow Status
- Security Hub CSPM — Automation Rules
- Systems Manager — Disable Public Access for Security Groups
- AWS Audit Manager — Assessment Reports
- AWS Audit Manager — Custom AWS Config Evidence Sources
- AWS Architecture Icons — Official Assets
Technical note: Control coverage, API behavior, integrations, and regional availability can change. Validate your architecture against current AWS documentation and review the final SOC 2 control mappings with your auditor.
Which problem takes the most time in your AWS environment: custom compliance rules, multi-account monitoring, remediation, exception management, or preparing evidence for auditors?
Share your experience. The most valuable cloud engineering lessons usually come from the problems that don't appear in the architecture diagram.
Open to Cloud Ops Remote and technical writing projects.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article