Automating Cloud Compliance: AWS Config, Azure Policy, and GCP Organization Policies

Manual Compliance Does Not Scale

Every audit I have participated in follows the same pattern. Someone asks for evidence that all S3 buckets are encrypted. An engineer runs a script, screenshots the output, pastes it into a spreadsheet, and emails it to the compliance team. Two weeks later, someone creates an unencrypted bucket. Nobody notices until the next audit. The compliance team is frustrated because the evidence is stale. The engineering team is frustrated because they spent three days generating reports instead of building features. Everyone agrees they need to automate this. Nobody does.

Cloud compliance automation changes this dynamic completely. Instead of periodic manual evidence collection, you define policies as code, deploy continuous monitoring, and generate audit evidence automatically. When a resource violates a policy, you can detect it within minutes (detective controls) or prevent it from being created in the first place (preventive controls). Remediation can be manual (alert the team) or automatic (fix the violation without human intervention).

This guide covers the native compliance automation tools on AWS, Azure, and GCP -- AWS Config Rules, Azure Policy, and GCP Organization Policies -- with specific mappings to SOC 2, PCI DSS, and HIPAA requirements. The focus is on practical implementation: which rules to deploy first, how to handle remediation safely, and how to generate the evidence auditors actually want.

Preventive vs Detective Controls

This distinction is the foundation of compliance automation, and most teams get the balance wrong. They deploy detective controls for everything and wonder why violations keep happening, or they deploy preventive controls too aggressively and break developer workflows.

Preventive controls stop violations before they happen. AWS Service Control Policies (SCPs), Azure Policy with deny effects, and GCP Organization Policy constraints prevent non-compliant resources from being created. An SCP that denies s3:CreateBucket unless server-side encryption is specified means an unencrypted bucket cannot exist -- period. No detection needed, no remediation needed, no audit evidence to generate.

Detective controls find violations after they happen. AWS Config Rules, Azure Policy with audit effects, and GCP Security Command Center scan existing resources and report non-compliance. A Config Rule that checks whether S3 buckets have encryption enabled will find unencrypted buckets, but it does not prevent their creation. You still need a process to remediate violations.

The right approach is layered: preventive controls for hard security requirements (encryption, public access, network restrictions) and detective controls for soft requirements (tagging, cost optimization, best practices) and for validating that preventive controls are working correctly. Yes, you should have detective controls that verify your preventive controls. Defense in depth applies to compliance, too.

AWS Config Rules

AWS Config is the backbone of compliance automation on AWS. It records configuration changes for supported resource types, maintains a configuration history, and evaluates resources against rules. AWS Config is not free -- it charges $0.003 per configuration item recorded and $0.001 per rule evaluation -- but for compliance purposes, the cost is trivial compared to the cost of a failed audit or a security breach.

AWS Config offers two types of rules: managed rules (AWS-authored, covering common compliance requirements) and custom rules (Lambda functions you write to evaluate any condition). There are over 350 managed rules covering encryption, access control, logging, networking, and more. For most compliance frameworks, managed rules cover 70-80% of requirements.

Critical Config Rules for Every Account

These rules should be active in every AWS account, regardless of compliance framework:

• s3-bucket-server-side-encryption-enabled: Verifies all S3 buckets have default encryption configured.
• s3-bucket-public-read-prohibited / s3-bucket-public-write-prohibited: Detects S3 buckets with public access.
• encrypted-volumes: Verifies all EBS volumes are encrypted.
• rds-storage-encrypted: Verifies all RDS instances have storage encryption enabled.
• restricted-ssh: Verifies no security group allows unrestricted SSH (0.0.0.0/0 on port 22).
• root-account-mfa-enabled: Verifies MFA is enabled on the root account.
• iam-password-policy: Verifies the account password policy meets complexity requirements.
• cloudtrail-enabled: Verifies CloudTrail is logging in the account.
• multi-region-cloudtrail-enabled: Verifies CloudTrail is logging across all regions.
• vpc-flow-logs-enabled: Verifies VPC Flow Logs are active on all VPCs.

Remediation with SSM Automation

AWS Config can automatically remediate non-compliant resources using SSM Automation documents. When a rule evaluation finds a non-compliant resource, Config triggers an SSM Automation runbook that fixes the issue. For example, the AWS-EnableS3BucketEncryption runbook adds default AES256 encryption to an unencrypted S3 bucket.

A word of caution on automatic remediation: start with manual remediation (Config sends an SNS notification, a human reviews and approves the fix) before enabling automatic remediation. Automatic remediation can cause outages if it modifies resources that applications depend on in specific configurations. For example, automatically enabling encryption on an existing S3 bucket is safe. Automatically modifying a security group to remove a rule could break an application that depends on that rule. Build confidence gradually.

Azure Policy

Azure Policy is the most mature and comprehensive compliance automation tool of any cloud provider. It supports both preventive (deny, deployIfNotExists, modify) and detective (audit, auditIfNotExists) effects in the same policy framework. Policies can be authored in JSON or Bicep, assigned at the management group, subscription, or resource group level, and exempted for specific resources that have legitimate reasons for non-compliance.

Azure Policy's strength is its built-in policy definitions. Microsoft maintains hundreds of built-in policies mapped to specific compliance frameworks. The "Azure Security Benchmark" initiative contains over 200 policies covering identity, networking, data protection, logging, and incident response. You can assign this single initiative to your management group and immediately get a compliance dashboard showing your posture across all subscriptions.

Policy Effects

Understanding Azure Policy effects is critical for safe deployment:

• Audit: Logs non-compliance but allows the resource. Use for visibility and initial assessment.
• Deny: Prevents resource creation or modification that violates the policy. Use for hard security requirements.
• Modify: Adds, updates, or removes properties on a resource during creation or update. Useful for adding required tags or enabling settings that developers might forget.
• DeployIfNotExists: Deploys a related resource if it does not exist. For example, deploy a diagnostic setting for every storage account to ensure logging is always enabled.
• AuditIfNotExists: Checks for the existence of a related resource. For example, audit whether each VM has a backup policy associated.
• Disabled: The policy exists but is not evaluated. Useful for testing or temporary exemptions.

Remediation Tasks

For policies with Modify or DeployIfNotExists effects, Azure Policy can create remediation tasks that apply the policy to existing non-compliant resources. When you assign a new policy with DeployIfNotExists effect, it only applies to new resources by default. To bring existing resources into compliance, you create a remediation task that evaluates all existing resources and applies the remediation action. Remediation tasks use a managed identity and can be scoped to specific resource groups or subscriptions.

GCP Organization Policies

GCP Organization Policies are purely preventive -- they define constraints on resource configurations that cannot be violated. Unlike AWS Config (detective) or Azure Policy (both), Organization Policies do not scan existing resources. They enforce constraints at creation and modification time.

GCP offers two types of constraints: boolean constraints (on/off) and list constraints (allow/deny specific values). Boolean constraints include disabling serial port access for VMs, requiring OS Login, and disabling service account key creation. List constraints include restricting which regions resources can be created in, which VM machine types can be used, and which external IP addresses can be assigned.

Custom Organization Policy Constraints

Custom constraints (GA since 2023) let you write your own organization policy constraints using Common Expression Language (CEL). For example, you can create a constraint that requires all Cloud Storage buckets to have uniform bucket-level access enabled, or that all GKE clusters must have Workload Identity enabled. Custom constraints evaluate against the resource's API request body, giving you access to any field in the resource configuration.

For detective controls on GCP, use Security Command Center (SCC). SCC continuously scans your GCP resources for security misconfigurations, vulnerabilities, and threats. Security Health Analytics (a built-in SCC feature) provides findings for over 140 detectors covering IAM, networking, encryption, logging, and Kubernetes security. SCC findings can trigger Cloud Functions or Pub/Sub notifications for automated remediation.

Mapping Compliance Frameworks to Cloud Controls

SOC 2

SOC 2 Trust Services Criteria map to cloud controls as follows:

• CC6.1 (Logical Access): IAM policies enforcing least privilege, MFA on all human accounts, service account key rotation. AWS: iam-user-mfa-enabled, access-keys-rotated. Azure: MFA conditional access policies. GCP: enforce MFA via workspace, disable service account key creation org policy.
• CC6.6 (Encryption in Transit): Enforce HTTPS on all public endpoints. AWS: alb-http-to-https-redirection-check. Azure: Policy requiring HTTPS on App Service. GCP: SSL policy requiring TLS 1.2+.
• CC6.7 (Encryption at Rest): Default encryption on all storage. AWS: s3-bucket-server-side-encryption-enabled, encrypted-volumes, rds-storage-encrypted. Azure: Policy requiring encryption on storage accounts. GCP: default encryption is always on, but you may need CMEK for compliance.
• CC7.2 (Monitoring): Centralized logging and alerting. AWS: cloudtrail-enabled, cloudwatch-alarm-action-check. Azure: Activity Log diagnostic settings, Azure Monitor alerts. GCP: Data Access audit logs enabled, Cloud Monitoring alert policies.
• CC8.1 (Change Management): Infrastructure as code, deployment pipelines with approvals, GitOps with audit trails. This is where your IaC and CI/CD tooling generates compliance evidence automatically.

PCI DSS

PCI DSS has the most specific technical requirements:

• Requirement 1 (Firewalls): Security groups/NSGs with explicit deny-all defaults, no unrestricted inbound rules. AWS: restricted-ssh, vpc-default-security-group-closed. Azure: NSG flow logs, deny-all default rules. GCP: VPC firewall rules with logging enabled.
• Requirement 2 (No Default Credentials): No default passwords on databases, no default security group rules. AWS: rds-instance-public-access-check. Azure: Policy denying public database access.
• Requirement 3 (Protect Stored Data): Encryption at rest with key management. AWS: s3-default-encryption-kms, kms-cmk-not-scheduled-for-deletion. Azure: Customer-managed keys on storage. GCP: CMEK on Cloud Storage and Cloud SQL.
• Requirement 8 (Authentication): MFA everywhere, password complexity, session timeouts. AWS: iam-password-policy with specific complexity requirements. Azure: Conditional Access policies. GCP: Workspace security settings.
• Requirement 10 (Logging): Immutable audit logs with 1-year retention. AWS: CloudTrail with S3 Object Lock. Azure: Immutable blob storage for activity logs. GCP: Locked log sinks to Cloud Storage.

HIPAA

HIPAA compliance in the cloud focuses on protecting electronic protected health information (ePHI):

• Access Controls (164.312(a)): Role-based access, unique user identification, automatic session termination. AWS: iam-user-no-policies-check (enforce group-based policies), iam-root-access-key-check. Azure: Conditional access with session controls. GCP: IAM roles with conditions.
• Audit Controls (164.312(b)): Record and examine access to ePHI. AWS: cloudtrail-s3-dataevents-enabled for buckets containing ePHI. Azure: Diagnostic settings capturing data plane operations. GCP: Data Access audit logs (not enabled by default -- this is a common gap).
• Transmission Security (164.312(e)): Encryption in transit for ePHI. AWS: enforce TLS 1.2+ on all endpoints. Azure: Minimum TLS version policies on storage and App Service. GCP: SSL policies on load balancers.
• Integrity Controls (164.312(c)): Mechanisms to protect ePHI from improper modification. AWS: S3 Object Lock, versioning, MFA Delete. Azure: Immutable storage, soft delete. GCP: Object versioning, retention policies.

Building the Automation Pipeline

Compliance automation is not just deploying rules. It is building a pipeline that continuously monitors, detects, remediates, and generates evidence. Here is the architecture that works:

1. Policy Definition (Git): All policies are defined as code and stored in Git. AWS Config Rules as CloudFormation or Terraform. Azure Policies as JSON or Bicep. GCP Organization Policies as YAML. Every change is a pull request, reviewed, and approved. This is your change management evidence.
2. Policy Deployment (CI/CD): Policies are deployed automatically when merged to main. Use Terraform, CloudFormation StackSets (for multi-account), or Azure Management Group assignments. Never create policies manually in the console.
3. Continuous Evaluation: AWS Config evaluates continuously (configuration change-triggered or periodic). Azure Policy evaluates on creation, update, and via periodic compliance scans (every 24 hours by default). GCP Organization Policies evaluate at creation/update time; SCC scans periodically.
4. Alerting: Non-compliant resources trigger alerts via SNS (AWS), Azure Monitor (Azure), or Pub/Sub (GCP). Route alerts to Slack, PagerDuty, or your SIEM. Critical violations (public S3 bucket, unrestricted security group) should page immediately.
5. Remediation: Automatic for safe, well-understood violations (adding encryption, adding tags). Manual for potentially disruptive violations (modifying security groups, changing network configurations). Track remediation via tickets (Jira, ServiceNow) for audit evidence.
6. Evidence Generation: Export compliance reports on a schedule. AWS Config generates compliance snapshots to S3. Azure Policy compliance data is queryable via Azure Resource Graph. Build dashboards that auditors can access directly, reducing evidence request turnaround time.

Common Pitfalls

• Deploying too many rules at once. Start with 10-15 critical rules covering encryption, public access, and logging. Expand gradually. Deploying 200 rules on day one creates alert fatigue and makes it impossible to prioritize remediation.
• No exemption process. Some resources legitimately need to violate policies (a public website bucket, a development account with relaxed controls). Build an exemption process with expiration dates, owner approval, and documented justification. Azure Policy exemptions handle this natively; on AWS, use Config Rule tags and suppression logic.
• Ignoring multi-account/multi-subscription scope. Deploying rules in one account while 50 other accounts have no monitoring is worse than useless -- it creates a false sense of security. Use AWS Organizations with delegated Config administrator, Azure Management Groups with inherited policies, or GCP Organization Policies at the org node.
• Not testing policies before enforcement. A deny policy on Azure or an SCP on AWS can block legitimate operations, including infrastructure deployments and incident response. Always deploy in audit mode first, review the impact for at least two weeks, then switch to deny/enforce mode.
• Treating compliance as a security team problem. Compliance automation works only when development teams understand and support the policies. Involve developers in policy design, provide clear documentation on why each policy exists, and make it easy to request exemptions when needed.

The Payoff

Teams that invest in compliance automation report audit preparation time dropping from weeks to hours. Instead of scrambling to generate evidence, they hand auditors a dashboard with real-time compliance data. Instead of discovering violations during annual audits, they catch and fix violations within minutes. The initial investment is significant -- expect 2-4 weeks of engineering time to set up the foundation -- but the ongoing savings in audit preparation, incident prevention, and engineering time make it one of the highest-ROI investments a cloud team can make.