Introduction
Many organizations establish security policies and compliance requirements, but translating those requirements into consistent technical controls across a growing AWS environment can be challenging.
AWS provides the building blocks through Organizations, Control Tower, Service Control Policies (SCPs), Security Hub, and other native services. However, these services alone do not define a security operating model. Organizations still need a framework that connects governance requirements to technical implementation and ongoing compliance monitoring.
This article outlines a practical security governance model built on AWS Control Tower and AWS Organizations. The model focuses on three key objectives:
Prevent non-compliant configurations from being deployed.
Detect security and compliance drift when it occurs.
Automatically remediate high-risk violations.
The result is a repeatable approach that allows cloud environments to remain aligned with business security policies and standards while maintaining the flexibility expected from modern cloud platforms.
From Policy to Implementation
Every security program begins with policies and standards.
Policies are typically owned by governance, risk, compliance, or security teams and define organizational expectations. Examples might include:
Approved AWS regions
Identity and access management requirements
Logging and audit requirements
Vulnerability management expectations
Network security requirements
The cloud platform team is then responsible for implementing technical controls that enforce those requirements.
To bridge this gap, I advocate maintaining a formal Security Model document. This document serves as the implementation specification for cloud security controls.
A typical purpose statement might read:
This document details specific configurations in the AWS Organization that implement the controls for the organization's multi-account AWS environment, ensuring alignment with security policies and standards. The configuration establishes preventative, detective, and remediative mechanisms to maintain confidentiality, integrity, and availability while meeting customer and industry expectations.
The document should define:
Purpose and scope
Applicable policies and standards
Stakeholders / Review Board members (owner, approvers)
Preventative controls
Detective controls
Remediative controls
Exceptions and compensating controls
Importantly, ownership of the security model should reside with a stakeholder group that periodically reviews and updates the implementation. In some organizations this may be a dedicated governance or compliance function. In others, security governance may be embedded directly within cloud platform engineering.
Establishing the Foundation with AWS Control Tower
The foundation of this model is an AWS Landing Zone implemented using AWS Control Tower.
Control Tower provides:
AWS Organizations management
Organizational Units (OUs)
Centralized identity integration
Audit account
Log Archive account
Standardized account provisioning
This creates a consistent multi-account architecture where controls can be deployed uniformly. While Control Tower provides the foundation, most organizations quickly require controls beyond those available through native guardrails.
This is where Customizations for AWS Control Tower (CfCT) becomes a critical component.
CfCT allows organizations to define a deployment manifest that can:
Deploy Service Control Policies (SCPs)
Deploy resources through CloudFormation stack sets across accounts and regions.
Maintain consistent configuration across the organization
In effect, CfCT becomes the mechanism that transforms governance requirements into enforceable technical controls.
Layer 1: Preventative Controls
Preventative controls stop non-compliant actions before they occur.
Restricting AWS Regions
One of the most effective organizational controls is restricting resource deployment to approved AWS regions.
For many organizations there is no business requirement to operate globally. Allowing unrestricted deployment increases attack surface and can create regulatory concerns around data residency.
A common approach is implementing an SCP that:
Denies actions in non-approved regions
Excludes global AWS services such as IAM and Route53
Allows operations only in explicitly approved regions
This immediately prevents accidental or unauthorized deployment outside approved geographic boundaries.
Eliminating Root User Activity
Another foundational control is preventing use of AWS account root users.
In a Control Tower environment, users should authenticate through IAM Identity Center or an approved identity provider. Administrative access should be granted through federated roles with least-privilege permissions.
An SCP can deny actions when the principal matches:
arn:aws:iam::*:root
This effectively removes root user activity from normal operations while preserving emergency break-glass procedures when required.
The result is a significantly reduced risk profile and improved accountability through centralized identity management.
Layer 2: Detective Controls
Preventative controls are important, but they cannot address every scenario. Organizations also need visibility into compliance posture and configuration drift.
Creating a Central Security Services Account
In several AWS Organizations, I have implemented a dedicated Security Services account was introduced alongside the standard Control Tower Audit and Log Archive accounts.
This account becomes the centralized management plane for security tooling.
Typical deployments include:
AWS Security Hub
Amazon GuardDuty
AWS Firewall Manager
Additional monitoring integrations (Macie, Inspector, etc)
The objective is to provide a single operational view of security posture across all AWS accounts. This configuration can be complimented if using a 3rd party SIEM, or act as a SIEM if an external option is not available.
Cross-Account Security Management
Using CfCT, standardized CloudFormation deployments can establish:
Security administration roles
Cross-account execution roles
Security Hub configuration
GuardDuty enrollment
Supporting automation
A common pattern includes:
SecurityServicesRole in the Security Services account.
SecurityServicesExecutionRole deployed to member accounts.
Automated role assumption for centralized administration.
This creates secure delegated administration without requiring direct access to every account.
Automated Account Enrollment
As organizations scale, manual onboarding becomes unsustainable.
A lightweight Lambda function can monitor AWS Organizations for newly created accounts and automatically:
Send Security Hub invitations from Security Services
Accept invitations in the target account and region.
Configure delegated administration
Enable required security services
This ensures newly provisioned accounts immediately inherit the organization's security baseline.
Layer 3: Remediative Controls
The final layer addresses a reality of cloud operations: non-compliant resources will occasionally be created despite preventative controls.
Rather than relying solely on manual intervention, organizations can implement automated remediation.
Moving Beyond Detection
Security Hub provides excellent visibility into security findings. However, detection alone often creates operational overhead. For frequently recurring findings, remediation can be automated.
Consider a common example:
> A developer creates a security group allowing SSH or RDP access from: 0.0.0.0/0
This violates controls found in multiple standards including CIS Benchmarks and AWS Foundational Security Best Practices.
Security Hub will detect the issue, but detection alone leaves a window of exposure.
Auto-Compliant Controls
An alternative approach is to treat selected findings as self-healing controls.
The workflow becomes:
Security Hub generates a finding.
EventBridge receives the event.
A remediation Lambda is invoked.
The Lambda modifies the resource.
Compliance is restored automatically.
For example:
Remove unrestricted SSH ingress rules.
Remove unrestricted RDP ingress rules.
Restore required logging settings.
Re-enable security monitoring services.
The resource remains available, but the non-compliant configuration is corrected within seconds. This approach significantly reduces operational risk while minimizing the burden on security teams.
Managing Standards and Compensating Controls
A common misconception is that security standards should be treated as immutable checklists and the only and whole source of truth for controls.
Standards such as:
CIS Benchmarks
AWS Foundational Security Best Practices (FSBP)
PCI DSS
NIST frameworks
should be viewed as inputs into the security model rather than requirements that must be adopted verbatim. Organizations frequently implement compensating controls that provide equivalent or stronger protection.
For example, AWS FSBP control IAM.6 recommends hardware MFA on root accounts.
If the organization has implemented an SCP that blocks all root account activity, a governance review board may determine that the risk is already mitigated and approve disabling the finding.
Such decisions should be formally documented, reviewed, and approved as part of the security model governance process.
The objective is not perfect compliance with every benchmark. The objective is effective risk reduction aligned to business requirements.
Closing Thoughts
Effective cloud security governance is not achieved through policies alone, nor through tooling alone. It requires a deliberate connection between governance requirements and technical implementation.
By combining AWS Control Tower, AWS Organizations, Customizations for AWS Control Tower, Security Hub, and automated remediation patterns, organizations can establish a security framework that continuously enforces policy, monitors compliance, and corrects drift at scale.
The most successful implementations treat security as a living system rather than a static configuration. Policies evolve, risks change, and cloud platforms grow. A well-defined security model, reviewed by the appropriate stakeholders and implemented through automation, provides a sustainable mechanism for maintaining security and compliance across the AWS environment.
