Control Tower's guardrails are frequently deployed by default during landing zone setup without a clear map back to which specific compliance control each one actually satisfies — which means compliance teams end up manually re-verifying what the guardrails were already enforcing, or worse, missing the ones that matter most for their specific framework.
Preventive vs. Detective Guardrails, and Why the Distinction Matters for Evidence
Control Tower guardrails come in two flavors: preventive guardrails implemented as Service Control Policies that block a prohibited action outright, and detective guardrails implemented as AWS Config rules that flag non-compliant resources after the fact for remediation. For audit evidence purposes, this distinction matters — a preventive guardrail gives you evidence that a violation was structurally impossible, while a detective guardrail gives you evidence that violations get caught and remediated, which is a slightly different (and generally weaker, standing alone) evidentiary story for an auditor.
Mapping Common Guardrails to SOC 2 Control Areas
Disallow public read access to S3 buckets (preventive) maps directly to data protection controls (commonly grouped under CC6.1/CC6.7 in most SOC 2 mappings) — demonstrating that customer or sensitive data can't be inadvertently exposed via a misconfigured bucket policy.
Disallow changes to CloudTrail configuration (preventive) protects the integrity of your audit logging itself, which underpins evidence for nearly every other control — if CloudTrail can be disabled or reconfigured by anyone with sufficient IAM permissions, every other piece of log-based evidence becomes suspect.
Detect unencrypted EBS volumes (detective) and detect RDS instances without encryption (detective) map to data-at-rest protection controls, giving compliance teams a continuously-updated inventory of any drift from encryption defaults.
Detect root user activity (detective) is particularly valuable evidence for access control controls — root account usage should be rare and deliberate, and a guardrail flagging any root login or API activity gives you an auditable trail proving the account isn't used for routine operations.
Configuring Guardrails With Evidence Collection in Mind
resource "aws_organizations_policy" "deny_public_s3" {
name = "deny-public-s3-access"
type = "SERVICE_CONTROL_POLICY"
content = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "DenyPublicReadS3"
Effect = "Deny"
Action = ["s3:PutBucketPublicAccessBlock", "s3:PutBucketAcl"]
Resource = "*"
Condition = {
StringNotEquals = { "s3:x-amz-acl" = ["private"] }
}
}]
})
}
Beyond configuring the guardrail itself, evidence collection needs a pipeline that periodically exports Config rule compliance status and SCP denial events (visible in CloudTrail as AccessDenied events tied to an SCP) into a format your GRC platform or auditor can consume directly, rather than relying on someone manually screenshotting the Control Tower console each audit cycle.
Guardrails That Commonly Get Missed
Teams often deploy the default guardrail set Control Tower ships with, but skip enabling some of the stronger optional guardrails relevant to compliance — particularly around mandatory tagging enforcement (useful for both cost allocation and for scoping which resources fall inside a compliance boundary) and guardrails restricting specific high-risk regions or services that aren't part of your approved architecture.
Handling Guardrail Exceptions
Occasionally a legitimate business need conflicts with a guardrail's default restriction — a specific account genuinely needs a public-read S3 bucket for a CDN origin, for example. Rather than removing the guardrail organization-wide, Control Tower supports account-level or OU-level guardrail exceptions, letting you maintain the restriction everywhere else while documenting the specific, narrow exception with its own rationale — itself a piece of evidence showing your control exceptions are deliberate and reviewed, not accidental gaps.
Frequently Asked Questions
Does Control Tower guarantee SOC 2 compliance on its own?
No — guardrails enforce and detect specific technical controls, but SOC 2 compliance also requires documented policies, operational evidence of processes actually running (access reviews, incident response), and a formal audit. Control Tower is foundational infrastructure, not a complete compliance program.
How do we export guardrail compliance status for auditor evidence?
AWS Config's compliance API and CloudTrail-based SCP denial events can both be extracted programmatically and formatted as evidence artifacts — this is a common integration point for feeding automated evidence into a GRC platform rather than relying on manual console review each cycle.
Can we use Control Tower guardrails alongside a custom Terraform-managed landing zone?
Yes, though the integration requires care — some organizations use Control Tower for the core landing zone while managing additional guardrails and account-specific resources via Terraform on top, which works but needs clear ownership boundaries to avoid configuration drift or conflicts.
What happens if a preventive guardrail blocks something we actually need to do?
Request an account or OU-level exception through Control Tower's guardrail exception mechanism rather than removing the guardrail broadly — this preserves the security/compliance posture everywhere else while documenting the specific, reviewed exception.
Do detective guardrails automatically remediate non-compliant resources?
Not by default — detective guardrails flag non-compliance via AWS Config, but automated remediation requires additional configuration (Config remediation actions or custom automation) layered on top of the detection itself.
Book a technical call → rutagon.com/contact or call 907-841-8407.