Cloud Governance Framework: Automating Policies on AWS

Why Manual Governance Does Not Scale

Many organizations start their cloud journey with manual governance processes: Excel checklists for security reviews, monthly audit meetings, manual tag inspections, and reactive compliance checks after incidents. This approach works for a dozen workloads. It breaks down at a hundred.

The data is unambiguous: Gartner projects that through 2025, more than 99% of cloud security failures will be the customer's fault — not due to vulnerabilities in AWS services themselves.^[1] An IBM Security study puts the average cost of a cloud-based data breach in Germany at €4.9 million.^[2] The vast majority of these incidents would have been detectable and preventable through automated compliance checks.

The root cause lies in growth itself: every new account, every new region, every new team multiplies governance overhead. Three mechanisms make manual governance problematic at scale:

1. Configuration drift: Resources are deployed and never again checked against security standards. An S3 bucket that is configured publicly after deployment can go unnoticed for weeks.
2. Inconsistent enforcement: Manual reviews are by definition incomplete. Teams under delivery pressure bypass processes — not out of malice, but because the path of least resistance is not always the compliant one.
3. Missing auditability: When regulators request evidence, logs must be manually assembled. Without continuous recording, evidence of past compliance states simply does not exist.

The alternative is Governance-as-Code: policies are defined in machine-readable form, automatically enforced, and continuously evaluated. AWS provides a coherent toolset for exactly this purpose.

Key Concepts: The AWS Governance Vocabulary

Service Control Policy (SCP)

A JSON-based policy in AWS Organizations that acts as a permission ceiling within Organizational Units (OUs) and accounts. SCPs can fundamentally deny actions — regardless of what IAM permissions are assigned to a user or role. They are the most powerful governance instrument at the organizational level and form the outer boundary of all guardrails.

Config Rule

A rule in AWS Config that defines a desired configuration state for AWS resources. Config Rules are evaluated continuously or on configuration changes. When a deviation is detected, the resource is marked as "non-compliant." AWS provides over 250 Managed Rules; Custom Rules enable arbitrarily specific check logic via Lambda.

Guardrail

A safety mechanism that is either preventive (prevents a non-compliant action from occurring, e.g., SCP) or detective (detects and reports a non-compliant state, e.g., Config Rule). The term originates from the AWS Control Tower framework. Sound governance combines both types.

Compliance-as-Code

The approach of defining compliance requirements as versioned, machine-readable rules — stored in Git, automatically deployed, and continuously checked against infrastructure. Compliance-as-Code makes compliance status measurable, reproducible, and auditable. It replaces static documents with living, verifiable artifacts.

Tag Policy

A policy in AWS Organizations that enforces mandatory tagging standards for AWS resources. It defines permitted tag keys, case sensitivity rules, and optionally permitted values. Tag policies are the foundation for cost allocation, security controls, and automated lifecycle management.

AWS Config Rules in Detail

AWS Config is the core of every detective governance framework. It continuously records the configuration state of all AWS resources, enabling changes to be traced and compared against desired states.

How It Works

AWS Config sends a configuration snapshot to an S3 bucket on every change and optionally triggers evaluations. Config Rules are executed either change-triggered (on every resource change) or periodically (every 1, 3, 6, 12, or 24 hours). The result is a binary compliance status: COMPLIANT or NON_COMPLIANT.

Managed Rules vs. Custom Rules

AWS provides over 250 Managed Rules for common compliance checks — for example:

• s3-bucket-public-read-prohibited — S3 buckets must not be publicly readable
• encrypted-volumes — EBS volumes must be encrypted
• root-account-mfa-enabled — Root account must have MFA enabled
• vpc-flow-logs-enabled — VPC Flow Logs must be active
• iam-password-policy — IAM password policy must meet minimum requirements

Custom Rules allow arbitrarily specific check logic via AWS Lambda — enforcing company-specific standards such as requiring all EC2 instances to carry a particular tag, or all security groups to prohibit certain port exposures.

Conformance Packs

AWS bundles related Config Rules into Conformance Packs. Particularly relevant for DACH enterprises:

• CIS AWS Foundations Benchmark v1.4 — Baseline security controls
• NIST SP 800-53 Rev. 5 — Mapping to US federal standards (frequently used as a BSI C5 proxy)
• AWS Operational Best Practices for ISO 27001 — ISO 27001 controls

Conformance Packs can be rolled out organization-wide via CloudFormation or AWS Control Tower — a single deployment configures governance for all accounts.

Automated Remediation

Config Rules can be linked to Remediation Actions: when a resource is identified as non-compliant, AWS Systems Manager Automation triggers a corrective step — such as automatically disabling public access on an S3 bucket or adding a missing tag. This partially converts detective governance into preventive governance.

Service Control Policies: Guardrails for Accounts

SCPs are the most powerful governance tool in AWS Organizations. They act as access filters at the organizational level: even if an IAM user has been explicitly granted a permission, an SCP prevents execution if it does not allow that action.

Preventive vs. Detective Governance

The decisive advantage of SCPs over Config Rules: they are preventive. They prevent non-compliant actions before they are executed — Config Rules only detect them after the fact. For critical security requirements, SCPs should always be the first line of defense.

Typical SCP Patterns for DACH Enterprises

OU Hierarchy and SCP Inheritance

SCPs cascade down the OU hierarchy. An SCP defined at the root OU applies to all accounts in the entire organization. SCPs at the OU level can further restrict scope — but never expand it. This inheritance logic enables multi-layered governance:

1. Root OU: Absolutely immutable guardrails (e.g., no AWS region outside EU)
2. Environment OU (Prod/NonProd): Environment-specific restrictions (e.g., no public internet access in prod)
3. Workload OU: Workload-specific constraints (e.g., only certain instance types)

Tag Policies and Cost Allocation

Tags are the metadata backbone of every AWS environment. They enable cost allocation by team, project, and cost center; security controls via Attribute-Based Access Control (ABAC); automated lifecycle management; and inventory analysis for compliance evidence.

Without enforced tag standards, cloud FinOps is impossible: when a third of resources are untagged, 30–40% of costs cannot be attributed — a common problem in organically grown multi-account environments.

Setting Up Tag Policies

Tag Policies in AWS Organizations define mandatory standards. A simple policy might specify:

• Tag Environment is required; permitted values: prod, staging, dev
• Tag CostCenter is required; free text
• Tag Owner is required; format: email address
• Tag DataClassification is required; permitted values: public, internal, confidential, restricted

Tag Policies alone do not enforce tags — they only define permitted values. Mandatory enforcement is handled by supplementary Config Rules (e.g., required-tags).

ABAC: Tags as Security Controls

Attribute-Based Access Control (ABAC) extends Tag Policies with a security dimension: IAM policies can be written so that a user may only access resources that carry the same DataClassification tag as their IAM session. This significantly limits the blast radius in the event of compromised credentials.

AWS Security Hub and Audit Manager for Compliance

AWS Security Hub

AWS Security Hub aggregates security findings from all native AWS services (GuardDuty, Inspector, Macie, Config, IAM Access Analyzer) and third-party tools into a centralized view. It evaluates security posture against standardized frameworks:

• AWS Foundational Security Best Practices (FSBP) — over 350 automated controls
• CIS AWS Foundations Benchmark v1.4 / v3.0
• NIST SP 800-53 Rev. 5
• PCI DSS v3.2.1

Each finding receives a normalized severity score (CRITICAL, HIGH, MEDIUM, LOW, INFORMATIONAL) and an AWS Security Finding Format (ASFF)-compliant JSON. EventBridge rules can react to findings — automatically creating a Jira ticket or triggering a Lambda remediation.

AWS Audit Manager

While Security Hub monitors operational security posture, AWS Audit Manager targets the requirements of regulatory audits. It maps compliance frameworks (BSI C5, ISO 27001, SOC 2, GDPR) to AWS controls and automatically collects evidence:

• CloudTrail events as evidence for access controls
• Config snapshots as evidence for configuration standards
• IAM policy documents as evidence for permission management

The result is an audit package that can be handed directly to external auditors or internal review — without weeks of manual assembly. Based on Storm Reply's project experience, AWS Audit Manager reduces the preparation effort for a BSI C5 audit by 40–60%.

Cloud Governance in the Storm Road.MAP Methodology

The Storm Road.MAP structures cloud transformations in four phases. Governance is not a one-time setup — it is built and refined across all phases.

Phase 1: Assess

In the Assess phase, the current governance state is captured. Typical activities:

1. Enable AWS Config and create a first compliance snapshot
2. Enable Security Hub and activate the FSBP standard
3. Write CloudTrail organization-wide to S3
4. Activate IAM Access Analyzer for all regions
5. Prioritize findings by severity and regulatory relevance

The result is a Governance Gap Report: a prioritized list of open findings with effort estimates and regulatory mappings.

Phase 2: Mobilize

In the Mobilize phase, foundational structures are established:

1. Set up AWS Organizations with OU hierarchy
2. Deploy AWS Control Tower (Account Factory, guardrails, landing zone)
3. Define initial SCPs and deploy at root/OU level
4. Activate Tag Policies organization-wide
5. Roll out Conformance Pack for CIS Foundations Benchmark
6. Configure Audit Manager framework for BSI C5 / ISO 27001

Phase 3: Migrate / Build

Governance is refined for specific workloads: Custom Config Rules for application-specific requirements, ABAC structures for data classification, and workload-specific SCPs in dedicated OUs.

Phase 4: Operate & Optimize

Governance is operated as a living process: regular review cycles, automation of remediations, integration into the change management process, and continuous adaptation to new regulatory requirements.

Storm Reply Perspective: Governance as Enabler

In practice, we encounter three governance anti-patterns at DACH clients that we regularly address in projects:

Anti-pattern 1: Governance as an afterthought. Companies deploy hundreds of workloads and only begin thinking about governance when the first compliance audit arrives or a security incident occurs. Retrofitting is always more expensive than initial setup — we see multipliers of 3x to 10x in remediation effort.

Anti-pattern 2: Governance as a gatekeeper. Governance teams block deployments through manual reviews. The result is shadow IT: teams bypass the official cloud environment and deploy in unofficial accounts. Automated guardrails eliminate this incentive — what is compliant can be deployed quickly; what violates policy is simply not enabled in the first place.

Anti-pattern 3: Too many rules from day one. Companies activate all 350 FSBP controls at once and are overwhelmed by the noise. Our recommendation: start with 40–60 critical controls, prioritize findings by severity and regulatory relevance, and expand incrementally.

Storm Reply as AWS Premier Consulting Partner with competencies in Migration, Security, and DevOps has implemented governance frameworks for enterprises in financial services, life sciences, and the public sector. The Storm Road.MAP delivers the structured framework that integrates governance into the transformation process — not as a separate project appended afterward.

Regulatory Context: NIS2, BSI C5, GDPR, and the EU AI Act

Cloud governance on AWS is not an optional nice-to-have — for many DACH enterprises it is a regulatory obligation. Key frameworks at a glance:

NIS2 Directive (national transposition required since October 2024)

NIS2 requires operators of critical infrastructure and important entities to implement technical and organizational measures for risk management, incident reporting, and business continuity. Directly relevant for cloud governance:

• Art. 21 (a): Risk analysis and security policies for information systems — mapped to AWS Config + Security Hub
• Art. 21 (c): Backup management and recovery — AWS Backup + Config Rule backup-plan-min-frequency-and-min-retention-check
• Art. 21 (h): Multi-factor authentication — Config Rule iam-user-mfa-enabled + SCP against root access

BSI C5 (Cloud Computing Compliance Criteria Catalogue)

BSI C5 is the authoritative security standard for cloud services in the German market, particularly for public authorities and regulated industries. AWS holds certifications for all relevant criteria groups. For customers, the shared responsibility model applies: AWS is responsible for infrastructure (C5 attestation available), customers are responsible for the usage layer (own attestation or evidence required). AWS Audit Manager maps BSI C5 as a framework and delivers evidence for the customer side.

GDPR

SCPs restricting data processing to EU regions are the technical foundation for GDPR-compliant cloud computing. Also relevant: S3 Object Lock for retention periods, CloudTrail for traceability of data access, and Macie for automatic classification of personal data in S3.

EU AI Act

The EU AI Act requires operators of high-risk AI systems to establish governance structures covering traceability, auditability, and risk management. AWS Audit Manager and CloudTrail provide the technical basis for the required documentation of training data, model versions, and decision processes.

Benefits and Challenges at a Glance

Frequently Asked Questions

What is the difference between an SCP and an IAM policy?

An IAM policy grants permissions within an account. A Service Control Policy (SCP) in AWS Organizations sets a ceiling: it can restrict permissions but never expand them. SCPs apply to all principals in an account — including account administrators — making them the foundation of organization-wide guardrails.

How many AWS Config Rules does a typical enterprise need?

The AWS Security Hub FSBP standard contains over 350 automated checks. For a mid-sized DACH enterprise without special regulatory requirements, we recommend starting with 40–60 Managed Rules covering the CIS AWS Foundations Benchmark. BSI C5 or DORA add sector-specific packages on top.

Can Compliance-as-Code replace existing manual audits?

Compliance-as-Code automates continuous monitoring of technical controls and significantly reduces manual effort. Regulatory audits (e.g., BSI C5 attestations) still require human assessment of organizational controls and documentation of exception processes. AWS Audit Manager delivers technical evidence directly as an export into the audit package.

How does AWS Control Tower relate to manually configured SCPs?

AWS Control Tower is a managed service that rolls out a landing zone with predefined guardrails (SCPs + Config Rules) and automates account vending. For new environments, we recommend Control Tower as a starting point. In existing, organically grown environments, a manual migration into Control Tower is possible but requires careful planning.

Sources

1. Gartner, "Is the Cloud Secure?", 2019 (forecast: 99% of cloud incidents caused by customer error through 2025)
2. IBM Security, "Cost of a Data Breach Report 2023" — average cost in Germany: USD 4.9M
3. AWS, AWS Config Managed Rules Documentation
4. AWS, Service Control Policies (SCPs) — AWS Organizations
5. BSI, BSI Cloud Computing Compliance Criteria Catalogue (C5)
6. EU, NIS2 Directive (EU) 2022/2555