What 32 Security Controls Reveal About Real-World Cloud Landing Zones

The Reality Behind the Checkboxes

Enterprise security teams accumulate scanner after scanner. Between Cloud Native Application Protection Platforms (CNAPP), Cloud Security Posture Management (CSPM), and identity entitlement tooling, organizations spend heavily to buy visibility. The outcome is familiar: security engineers spend their days acting as alert routers, sorting through thousands of Jira tickets.

Scanning is fundamentally reactive. It flags a public storage bucket, an open port, or a hardcoded secret minutes or hours after deployment.

A large share of these recurring findings disappear entirely once you establish the right organizational guardrails and control policies at the root of Amazon Web Services and Google Cloud.

We recently codified the first 32 foundational security controls in an expanding catalog for multi-account landing zones across AWS (28 controls) and Google Cloud (4 controls). While many more controls are currently being built and added over time, every rule in this initial cohort enforces architectural guardrails directly at the organization level, preventing structural misconfigurations before developers deploy workloads.

Analyzing the data across this initial baseline shows why setting up preventative policies across your cloud organization resolves issues that scanners merely report.

---

1. Where Organizational Guardrails Matter Most

Security scanners evaluate thousands of individual resource configurations across compute, networking, databases, and containers.

When we categorize this initial cohort of 32 controls by operational discipline, the data shows that real organizational guardrails focus almost entirely on identity and foundational boundaries:

Fourteen of the 32 controls (43.8%) govern Identity and Access Management (IAM).

Adding Logging (18.8%) and Data Protection (18.8%) brings the total to 81.3% of the entire security baseline.

Consider how this changes daily operations. A typical CNAPP dashboard constantly flags individual S3 buckets lacking encryption or missing public access blocks. Security engineers chase down application owners to fix them one by one.

Applying control AWS-DATA-001: Enforce S3 Block Public Access at Organization Level enforces S3 Block Public Access at the AWS Organizations root via Service Control Policies (SCPs). Hundreds of potential scanner findings vanish across every member account immediately. Developers cannot make a bucket public even by accident, because the cloud control plane rejects the API call outright.

The same principle applies to credentials. Rather than scanning repositories for leaked static access keys after an incident, controls AWS-IAM-005: Enforce OIDC for VCS CI/CD Connections to AWS and GCP-IAM-001: Enforce Workload Identity Federation for VCS CI/CD Connections to GCP mandate OpenID Connect (OIDC) federation for CI/CD pipelines. Workload runners authenticate via short-lived tokens, removing static cloud secrets from third-party build systems altogether.

---

2. Bedrock Policies Carry Systemic Reach

Traditional security scanning surfaces an overwhelming volume of low and medium alerts: missing tags, permissive egress rules, unapplied minor patches. Teams expend enormous energy resolving low-impact findings while root architecture remains fragile.

Our 32 landing zone controls show a top-heavy distribution by design:

Twenty-three out of 32 controls (71.9%) carry High or Critical ratings.

Only one control ranks as Low (AWS-COMP-003: Enable AWS Artifact for Compliance Reports).

Landing zone controls operate at the bedrock of the cloud hierarchy. Misconfiguring a single application container creates an isolated issue. In contrast, failing to secure root accounts (AWS-IAM-001), omitting cross-account trust boundaries (AWS-IAM-002), or leaving audit trails unisolated (AWS-LOG-005) leaves every workload in the tenant vulnerable.

Establishing strict organization policies in AWS and GCP provides broad structural protection. A single Service Control Policy in AWS or an Organization Policy constraint in Google Cloud protects fifty accounts simultaneously, removing the need to monitor each resource individually.

---

3. Resolving 233 Compliance Requirements at Once

Compliance audits often feel like an endless treadmill. Compliance scanners crawl your cloud accounts and produce massive spreadsheets with hundreds of failed checks.

Our dataset reveals how foundational engineering controls resolve this problem through the Multi-Article Effect.

When mapping these 32 technical controls against major regulatory frameworks, 28 out of 32 controls (87.5%) satisfy multiple distinct articles, clauses, and sub-requirements within the exact same standard.

A single technical guardrail implemented at the organization level satisfies multiple compliance mandates simultaneously:

Across the catalog, 32 engineering controls satisfy 233 separate compliance standard requirements—an average multiplier of 7.3 to 1.

Consider a concrete example.

Control AWS-DATA-006: Enforce KMS Key Policies for Central Landing Zone Accounts consists of a single JSON policy baseline. It restricts KMS administrative actions, enforces separation of duties, and mandates encryption context evaluations.

When generating compliance reports, that single policy baseline satisfies 8 distinct compliance articles:

• NIST 800-53 Rev 5: AC-3 (Access Enforcement), SC-12 (Key Establishment and Management), and SC-13 (Cryptographic Protection)
• PCI DSS v4.0: Requirement 3.5.1 (KMS Access Control) and Requirement 3.6.1 (Key Generation and Storage)
• ISO/IEC 27001:2022: A.8.24 (Use of Cryptography)
• SOC 2 Type II: CC6.1 (Logical Access Controls)
• CIS AWS Foundations Benchmark: Section 2.8 (KMS Key Policy Rotation)

Instead of answering hundreds of individual scanner flags during an audit, enforcing central landing zone guardrails satisfies multiple regulatory frameworks automatically.

---

4. Supporting Developers Through Policy Complexity

Building secure cloud infrastructure requires a dual approach: establishing strong landing zone policies at the organizational level, and using scanners to maintain runtime visibility.

In practice, developers face a maze of corporate rules. Most enterprises maintain dozens of internal security standards, architectural review requirements, and compliance wikis. Developers cannot reasonably memorize hundreds of pages of internal policy while trying to deliver software on tight deadlines. In many situations, engineers simply do not know whether a specific configuration aligns with every company guideline.

Expecting developers to read through dense policy documents on their own creates friction and predictable mistakes.

Security teams need to support developers directly by embedding these policies into the landing zone itself:

1. Pre-Approved Infrastructure Baselines: Translate complex internal standards into reusable Infrastructure as Code modules. When developers deploy through standard templates, security compliance happens automatically.
2. Preventative Organizational Guardrails: Implement Service Control Policies in AWS and Organization Policies in Google Cloud as safety nets. Guardrails stop high-risk configurations at the cloud API layer, taking the burden of policy enforcement off the individual engineer.
3. Targeted Scanner Visibility: Use posture scanners and CNAPP tools to detect drift, identify unmanaged assets, and provide runtime context across active environments.

As we continue expanding this living catalog with additional controls over time, the primary objective remains clear: security teams succeed by removing ambiguity for developers. Codifying clear foundational guardrails and policies across AWS and GCP protects the organization while letting engineering teams ship software with confidence.