Cloud Compliance and Governance

Compliance is what happens when your good engineering practices need to be proven to someone external — an auditor, a regulator, or a customer's security team. The best compliance programs are a natural output of good engineering. The worst are a parallel bureaucracy that generates paperwork without improving security. This lesson covers how to build the former.

Shared Responsibility Applied to Compliance

The shared responsibility model applies to compliance too, and misunderstanding it is expensive. The cloud provider handles compliance for the infrastructure layer — physical security, hypervisor hardening, network fabric. They provide certifications (SOC 2, ISO 27001, HIPAA eligibility) for their services. But those certifications cover the provider's responsibilities, not yours. Your application, your configurations, your access controls, your data handling — that's your audit.

When an auditor asks "is your infrastructure SOC 2 compliant?", the answer is never just "we're on AWS and AWS is SOC 2 certified." You need to demonstrate that your use of AWS meets the trust service criteria.

The Frameworks

SOC 2 is the most common compliance framework for SaaS companies. It evaluates trust service criteria: security, availability, processing integrity, confidentiality, and privacy. Type I is a point-in-time assessment — your controls exist and are designed correctly on the audit date. Type II evaluates whether those controls operated effectively over a period (typically 6-12 months). Type II is what customers care about; Type I is the stepping stone.

HIPAA governs protected health information (PHI) in the US healthcare system. If your application touches patient data, you need a Business Associate Agreement (BAA) with your cloud provider (all three offer them for eligible services — not all services are eligible). HIPAA doesn't have a certification; it has requirements you must meet and penalties for violations.

GDPR applies to personal data of EU residents regardless of where your company is based. Key concepts: lawful basis for processing (consent, legitimate interest, contract), data residency requirements (some interpretations require EU data stays in EU regions), right to erasure (users can request deletion of their data), and data protection impact assessments for high-risk processing. GDPR violations carry fines up to 4% of global annual revenue.

PCI-DSS applies if you process, store, or transmit credit card data. The primary strategy is scope reduction — use Stripe, Braintree, or a similar payment processor so card data never touches your infrastructure. If card numbers never hit your servers, your PCI scope shrinks dramatically.

ISO 27001 is an international information security management standard. It's process-heavy and popular in European and enterprise markets. FedRAMP is the US federal government's cloud security standard — extremely rigorous and expensive to achieve, but required for selling to federal agencies.

Governance Mechanics

Governance is the organizational structure that prevents bad configurations from reaching production.

Landing zones are pre-configured account/project structures that encode your organization's standards. AWS Control Tower sets up a multi-account environment with guardrails. GCP uses a resource hierarchy (organization → folders → projects). Azure uses management groups and Azure Landing Zones. These give new teams a compliant starting point rather than a blank canvas.

Account strategy as blast radius. Separate accounts (AWS), projects (GCP), or subscriptions (Azure) per environment and per team. A compromised dev account can't reach production data. A misconfigured staging project doesn't affect production networking. This is your primary blast-radius control.

SCPs and Organization Policies are preventive guardrails that can't be overridden by individual account administrators. AWS Service Control Policies can deny actions across the entire organization: no resources outside approved regions, no disabling CloudTrail, no public S3 buckets. GCP Organization Policies provide similar constraints. Azure Policy with deny effects does the same. These are your seatbelt — they prevent violations rather than detecting them after the fact.

Tagging enforcement ensures every resource is attributed to a team, environment, and cost center. Without consistent tagging, you can't answer basic audit questions like "who owns this database?" or "is this a production resource?"

AWS Implementation

AWS governance stack: Organizations with SCPs for preventive guardrails. Control Tower for landing zone setup. Config with managed rules for continuous compliance checking (is encryption enabled? are security groups overly permissive?). Security Hub aggregates findings from Config, GuardDuty, Inspector, and third-party tools into a single dashboard with compliance scores against frameworks like CIS Benchmarks and PCI-DSS. CloudTrail provides immutable API audit logs (enable organization trail in all regions). AWS Artifact provides access to AWS's own compliance reports.

GCP Implementation

GCP governance stack: Resource hierarchy (organization → folders → projects) with Organization Policies as preventive guardrails. Security Command Center (SCC) provides asset inventory, vulnerability scanning, and compliance reporting. Cloud Audit Logs for API logging (admin activity logs are always on and immutable). Assured Workloads creates folders with compliance guardrails for specific frameworks (FedRAMP, HIPAA, etc.). Access Transparency logs when Google employees access your data.

Azure Implementation

Azure governance stack: Management groups with Azure Policy (including deny effects and built-in policy initiatives for CIS, HIPAA, etc.). Microsoft Defender for Cloud provides continuous compliance assessment with a regulatory compliance dashboard. Activity Logs and Diagnostic Logs for auditing. Blueprints (being replaced by deployment stacks and template specs) for repeatable compliant environments. Compliance Manager in the Microsoft 365 compliance center tracks compliance posture across Azure and M365.

Side-by-Side Comparison

Aspect	AWS	GCP	Azure
Preventive guardrails	SCPs	Organization Policies	Azure Policy (deny)
Landing zones	Control Tower	Assured Workloads	Azure Landing Zones
Compliance dashboard	Security Hub	Security Command Center	Defender for Cloud
Audit logging	CloudTrail (org trail)	Cloud Audit Logs	Activity Logs
Continuous compliance	Config Rules	SCC policies	Policy compliance
Account isolation	AWS Organizations (accounts)	Folders and projects	Management groups / subscriptions
Framework mappings	CIS, PCI-DSS, HIPAA	CIS, PCI-DSS, HIPAA	CIS, PCI-DSS, HIPAA, NIST, ISO

Policy as Code and Continuous Compliance

Point-in-time audits are theatre. You pass the audit on Tuesday, someone opens a security group to the world on Wednesday, and you're non-compliant for eleven months until the next audit catches it.

Continuous compliance means your controls are checked constantly — not annually, not quarterly, but every time a resource changes. AWS Config Rules, GCP SCC, and Azure Policy all evaluate resources against rules in near-real-time. Non-compliant resources are flagged immediately. Some rules can auto-remediate (close that security group, enable that encryption).

Policy as code takes this further. Define your compliance rules in version-controlled code (OPA/Rego, Sentinel, custom Config Rules). Test them. Review them in PRs. Deploy them through CI/CD. Your compliance posture becomes as auditable and reproducible as your infrastructure.

Evidence and Audit Trails

Auditors need evidence, and producing it manually is exhausting and error-prone. Immutable logs are the foundation — CloudTrail logs sent to a write-once S3 bucket (Object Lock), Cloud Audit Logs with organization-level sinks to locked storage, Activity Logs exported to immutable blob storage. If someone can delete the logs, the logs are worthless.

Retention requirements vary by framework. SOC 2 typically requires 1 year. HIPAA requires 6 years. GDPR requires deletion when data is no longer needed (tension with retention). Configure log retention policies explicitly.

Automate evidence collection. Don't make engineers screenshot console pages for auditors. Export Config compliance data, Security Hub findings, and access reviews programmatically. Auditors who get automated, continuous evidence finish faster and find fewer issues than auditors who get annual screenshots.

Architectural Tensions

Data residency vs sovereign clouds. GDPR doesn't strictly require EU data residency, but many interpretations and customer contracts do. All three providers offer EU-only regions. Sovereign cloud offerings (AWS European Sovereign Cloud, Google Sovereign Cloud, Azure confidential computing) provide additional isolation guarantees for regulated industries.

Right to deletion vs immutable backups. GDPR says users can request deletion of their personal data. Your disaster recovery says backups are immutable and retained for 30 days. These directly conflict. Solutions include crypto-shredding (encrypting user data with a per-user key and deleting the key), soft-deletion with expiry in backups, or accepting that backup restoration might reintroduce deleted data and having a process to re-delete it. None of these are elegant.

Key Takeaways

• The provider's compliance certifications cover their responsibilities; your configurations, access controls, and data handling are your audit scope
• Separate accounts/projects per environment are your primary blast-radius control and simplify compliance scoping enormously
• SCPs, Organization Policies, and Azure Policy deny-effects are preventive guardrails that stop violations before they happen — far more valuable than detective controls
• Point-in-time audits are theatre; continuous compliance with Config Rules, SCC, and Azure Policy evaluates every resource change in near-real-time
• Automate evidence collection — auditors who get continuous, programmatic evidence finish faster and find fewer issues
• Right-to-deletion and immutable backups are a genuine architectural tension with no elegant solution; address it explicitly in your design

This lesson concludes the cloud category. The patterns here — identity, encryption, least privilege, automation, continuous compliance — aren't cloud-specific; they're engineering discipline applied to cloud infrastructure.