Cloud Compliance & Governance: ISO 27017, SOC 2, HIPAA, and PCI DSS Validation

Introduction

Cloud compliance has evolved from a simple checkbox exercise into a comprehensive governance practice spanning security standards, regulatory frameworks, and continuous monitoring. According to Gartner's 2025 Cloud Security Outlook, 99% of cloud breaches through 2025 will result from improper use of cloud services—many stemming from compliance gaps and inadequate governance policies.

Organizations adopting multi-cloud strategies face compounding complexity: AWS requires different compliance approaches than Azure and GCP, yet regulatory requirements (HIPAA, PCI-DSS, GDPR, SOC 2) demand consistency across all platforms. Without a unified compliance framework and automated governance, organizations risk:

Regulatory fines: GDPR penalties up to €20 million or 4% of global annual revenue
Audit failures: Inability to demonstrate compliance for SOC 2, ISO 27001, PCI-DSS
Breach liability: Unencrypted regulated data costing $4.29 million per incident (IBM 2024 Cost of Data Breach Report)
Operational disruption: Compliance violations triggering emergency remediation and service disruptions

This guide provides a complete framework for validating cloud compliance across ISO 27017/27018, SOC 2 Type II, HIPAA, PCI-DSS, and GDPR requirements. We'll cover:

Compliance Framework Mapping - Aligning cloud controls to regulatory standards
HIPAA Compliance for Healthcare Workloads - Technical controls for PHI protection
PCI DSS for Payment Processing - Scope reduction and cardholder data protection
ISO 27017/27018 Cloud Security - Cloud-specific control validation
GDPR Data Residency & Sovereignty - Data location and subject rights
Governance Policies & Enforcement - AWS Organizations, Azure Policy, GCP Organization Policy
Compliance Automation Tools - Continuous monitoring and remediation
Audit Logging & Evidence Collection - SOC 2, ISO 27001 audit readiness
Shared Responsibility Model - Clarifying cloud provider vs. customer obligations

Understanding the Cloud Compliance Landscape

Why Cloud Compliance Differs from On-Premises

Traditional on-premises compliance focused on physical security, direct resource control, and annual audit cycles. Cloud introduces new complexity:

Shared Responsibility Model:

The cloud provider (AWS, Azure, GCP) and customer share security responsibilities:

Layer	Cloud Provider Responsibility	Customer Responsibility
Data Center Security	Physical access control, surveillance, facility hardening	N/A
Network Infrastructure	DDoS protection, intrusion detection, infrastructure logging	VPC configuration, security groups, WAF rules
Compute Services	Hypervisor security, infrastructure hardening, patching	OS patching, application updates, access control
Data Protection	Encryption algorithms, key infrastructure	Encryption key management, data classification
Identity & Access	IAM platform, authentication mechanisms	IAM policy design, access reviews, MFA enforcement
Compliance Monitoring	Built-in compliance tools and dashboards	Configuration, monitoring, evidence collection

Key Implication: Customer misconfiguration of shared responsibility services (S3 bucket permissions, security groups, IAM policies) causes 99% of cloud breaches.

Compliance Framework Interrelationships

Modern cloud workloads often require multiple frameworks simultaneously:

Healthcare: HIPAA (mandatory) + HITRUST (often required by insurers) + NIST 800-53 (if government funding)
Financial Services: PCI-DSS (payment processing) + SOC 2 (SaaS services) + GLBA (customer privacy) + NIST 800-53 (if federal)
SaaS Products: SOC 2 Type II + ISO 27001 + GDPR (if EU customers) + regional frameworks (CCPA for CA customers)
Government/Defense: FedRAMP, NIST 800-53, CJIS, CMMC, DISA STIGs

Strategy: Build on a foundation of CIS Benchmarks and NIST, then layer regulatory-specific controls. This prevents duplication and maintains consistency.

Framework 1: CIS Benchmarks as Compliance Foundation

The Center for Internet Security (CIS) Benchmarks provide prescriptive security configurations for AWS, Azure, and GCP—serving as the foundation for most regulatory frameworks.

CIS Benchmark Levels

Level 1 - Foundational Security:

Recommended for all organizations
Minimal business impact
Automated tooling can enforce with few exceptions
Target: 100% compliance for production

Level 2 - Enhanced Security:

Recommended for highly regulated industries (finance, healthcare, government)
May require process changes or temporary latency
Requires security expertise to implement
Target: 95%+ compliance for sensitive workloads

CIS Benchmark Coverage by Cloud (2025)

AWS CIS Foundations Benchmark v3.0.0:

150 recommendations across 6 sections
Identity and Access Management (30 checks)
Storage (10 checks)
Logging (25 checks)
Monitoring & Alerting (20 checks)
Networking (25 checks)
Data Protection (40 checks)

Azure CIS Foundations Benchmark v2.1.0:

143 recommendations
Identity & Access Management (35 checks)
Logging & Monitoring (30 checks)
Networking (25 checks)
General Security (20 checks)
Compliance (33 checks)

GCP CIS Foundations Benchmark v2.0.0:

75 recommendations
Identity & Access Management (15 checks)
Logging & Monitoring (25 checks)
Networking (15 checks)
Virtual Machines (10 checks)
Cloud SQL (10 checks)

Automated CIS Assessment Tools

AWS:

Prowler (Open Source) - 240+ AWS security checks including CIS compliance
AWS Security Hub - Native CIS Foundations Benchmark standard with continuous assessment
ScoutSuite (Open Source) - Multi-cloud security auditing

Azure:

Microsoft Defender for Cloud - Built-in CIS compliance dashboard and recommendations
Azure Policy - Automated policy enforcement with CIS initiatives
Azure Compliance Manager - Track and audit compliance across CIS and other frameworks

GCP:

Google Cloud Security Command Center (SCC) - CIS Benchmark compliance monitoring
Forseti Security (Open Source) - Policy enforcement and compliance scanning
GCP Policy Intelligence - Policy validation and troubleshooting

Multi-Cloud:

Cloudanix - CIS Benchmarks across AWS, Azure, GCP
Prisma Cloud (Palo Alto Networks) - Unified compliance dashboard
CloudHealth (VMware) - Multi-cloud security posture

Common CIS Benchmark Gaps

Organizations typically fail these CIS checks:

IAM (20-30% failure rate)
- Root account has access keys stored (should be deleted)
- MFA not enabled on console accounts
- Overly permissive service roles (e.g., AdministratorAccess attached to lambda execution role)
- No regular access reviews (quarterly minimum)
Logging (15-25% failure rate)
- CloudTrail disabled in secondary regions
- S3 access logging not enabled for audit buckets
- VPC Flow Logs not capturing network traffic
- Application logs not centralized to SIEM
Encryption (10-20% failure rate)
- RDS/database encryption not enforced
- S3 buckets lack default encryption
- EBS volumes unencrypted
- KMS key rotation not enabled (annual minimum)
Network Segmentation (15-25% failure rate)
- Security groups allow 0.0.0.0/0 on SSH (22), RDP (3389), database ports (5432)
- No network ACLs restricting traffic
- VPC Flow Logs not enabled
- VPC peering lacks proper route restrictions

HIPAA Compliance for Healthcare Workloads

HIPAA (Health Insurance Portability and Accountability Act) governs Protected Health Information (PHI) in cloud environments. HIPAA compliance requires three simultaneous safeguard tiers.

HIPAA Safeguard Tiers

Administrative Safeguards (Organizational & Procedural):

Security Management Process
- Risk analysis (assess likelihood and impact of threats)
- Mitigation strategies and documentation
- Sanctions policy for violations
- Incident response procedures
Assigned Security Responsibility
- Designate HIPAA Security Officer (typically CISO)
- Information security management team
- Clear escalation procedures
Workforce Security
- Unique user IDs (no shared accounts)
- Emergency access procedures (break-glass access with audit logging)
- Termination procedures (credential revocation, access removal)
Information Access Management
- Access control based on role and need-to-know
- Default deny principle (least privilege)
- Quarterly or annual access reviews
Security Awareness & Training
- Annual HIPAA security training (documented)
- Specific role-based training (developers, administrators)
- Incident response drills

Physical Safeguards (Data Center & Device Security):

Facility Access Control
- Cloud provider BAA (Business Associate Agreement) required
- AWS, Azure, GCP all offer HIPAA-compliant facilities
- Facility security plan and audit logs
Device & Media Controls
- Encryption of portable media
- Secure destruction procedures for decommissioned hardware
- Cloud disposal per provider standards (verified through third-party audits)
Workstation Use & Security
- Monitor access logs for PHI systems
- Auto-lockout after inactivity (15-30 minutes recommended)
- Endpoint protection on workstations accessing PHI

Technical Safeguards (Data & System Protection):

Access Control
- Unique user IDs (no shared credentials)
- Emergency access with manual override and audit logging
- Encryption and decryption mechanisms
- Automatic logoff (30 minutes inactivity recommended)
Audit Controls
- Comprehensive audit logging of all PHI access
- CloudTrail/Azure Monitor/Cloud Logging retention (minimum 6-7 years)
- Regular review of logs (monthly minimum)
- Automated alerting for suspicious access patterns
Integrity Controls
- Mechanisms to verify PHI has not been altered (checksums, digital signatures)
- Message authentication codes for data in transit
- Database integrity checks
Transmission Security
- TLS 1.2 minimum for all PHI transmissions
- VPN encryption for remote access
- Secure file transfer protocols (SFTP, not FTP)
- End-to-end encryption for data in transit

PHI Encryption in Cloud

Encryption at Rest (Required):

HIPAA requires encryption for stored PHI, though it permits alternative controls if encryption proves infeasible (rare):

AWS Services:

RDS (MySQL, PostgreSQL, Oracle, SQL Server): AWS KMS encryption, automated backups encrypted
S3: Server-side encryption with AWS KMS or customer-managed keys
EBS: EBS default encryption enabled (since 2018)
DynamoDB: DynamoDB encryption at rest (AWS managed keys or customer KMS)
Glacier: AWS managed encryption

Azure Services:

Azure SQL Database: Transparent Data Encryption (TDE)
Azure Storage: Storage Service Encryption (SSE) with Microsoft-managed or customer-managed keys
Azure Disk Encryption: BitLocker for VM disks
Azure Cosmos DB: Service-managed encryption standard

GCP Services:

Cloud SQL: Encrypted at rest (Google-managed keys), customer-managed CMEK supported
Cloud Storage: Server-side encryption default, customer-managed CMEK optional
Firestore: Automatic encryption at rest
Cloud Spanner: Encryption at rest with optional CMEK

Encryption in Transit (Required):

TLS 1.2 minimum for all PHI transmissions:

AWS Example:
- ALB listener with TLS 1.2, certificate from ACM
- Security group: inbound 443/tcp only
- Redirect HTTP → HTTPS

Azure Example:
- Application Gateway with TLS 1.2 minimum
- NSG rule: inbound 443/tcp to Application Gateway only
- Enforce HTTPS on App Service

GCP Example:
- Cloud Load Balancing with SSL policy (TLS 1.2+)
- Cloud Armor rules restrict access
- Enforce HTTPS on App Engine / Cloud Run

HIPAA Audit Logging Configuration

CloudTrail (AWS):

- Enable in all regions (Organization Trail)
- Send logs to S3 bucket (encrypted, versioning, MFA delete)
- Enable log file validation
- Retention: 7 years minimum (leverage S3 Lifecycle for Glacier)
- Monitor: CloudWatch Logs Insights for PHI access patterns

Azure Activity Log (Azure):

- Enable retention for all subscriptions (minimum 90 days)
- Send to Log Analytics workspace
- Alert on: Password resets, role assignments, policy changes
- Archive to Blob Storage (7-year retention via lifecycle policy)

Cloud Logging (GCP):

- Enable Cloud Audit Logs (Admin Activity, Data Access)
- Forward to Cloud Logging sink
- Retention: 90 days minimum (export to BigQuery for 7-year retention)
- Monitor: Log Analytics for unusual queries to Cloud SQL

HIPAA Breach Notification

HIPAA mandates notification of individuals and HHS within 60 days of breach discovery:

Required: Implement automated breach detection:

Anomalous database queries (rapid extraction of patient records)
Mass downloads from secure storage systems
Unauthorized access attempts across multiple records
Failed decryption attempts (potential ransomware activity)

Tools:

AWS GuardDuty with custom rules for database anomalies
Azure Defender for Cloud with analytics rules
GCP Security Command Center with custom detectors

PCI DSS Compliance for Payment Processing

PCI-DSS (Payment Card Industry Data Security Standard) applies to any organization storing, processing, or transmitting cardholder data. Non-compliance risks fines up to $100,000/month plus incident response liability.

PCI-DSS Scope Determination

Scope includes (Cardholder Data Environment - CDE):

Systems storing, processing, or transmitting cardholder data (PAN, CVV, PIN)
Systems with network access to CDE systems
Databases containing cardholder data

Scope excludes (Out of Scope):

Systems with no access to CHD (e.g., marketing database)
Isolated development/testing environments with anonymized data
End-user devices (POS terminals have separate compliance)

Scope reduction strategies:

Tokenization: Replace card numbers with tokens in your systems
- Example: Stripe, Braintree, Square handle PCI-DSS compliance
- Your application receives tokens instead of card data
- Only payment processor handles raw PAN
Network Segmentation: Isolate CDE from non-CDE systems
- CDE in private subnet with minimal access
- Application servers in separate VPC
- Reduces scope to payment processing tier only
Third-party Payment Providers: Outsource CHD handling
- Use managed payment services (AWS Payment Cryptography)
- Customer payments never touch your infrastructure

PCI-DSS 12 Requirements Mapped to Cloud

Requirement	Cloud Implementation	Example
1. Firewall configuration	Security groups, NACLs, WAF	Restrict inbound to 443/tcp only
2. No vendor defaults	Golden AMIs, hardened images	Custom AMI without default passwords
3. Encrypt stored CHD	KMS encryption at rest	S3 buckets with customer-managed KMS keys
4. Encrypt CHD in transit	TLS 1.2+, VPN	ALB listener with TLS 1.2, CloudFront HTTPS
5. Antivirus/malware	Endpoint Detection & Response	AWS GuardDuty, Endpoint agents on EC2
6. Security patches	Automated patching systems	Systems Manager Patch Manager, auto-scaling AMI updates
7. Least privilege access	IAM roles, resource policies	Role-based access, no wildcard permissions
8. Unique user IDs	Federated identity, MFA	Active Directory federation, MFA on console
9. Physical access restrictions	Cloud provider BAA, audit logs	AWS facility certifications, audit trail review
10. Monitor & log access	CloudTrail, VPC Flow Logs, database logs	Centralized logging to CloudWatch/Splunk
11. Regular security testing	Vulnerability scans, penetration tests	AWS Inspector, AWS Systems Manager Patch Manager
12. Information security policy	ISMS documentation	Policies addressing all 12 requirements

PCI-DSS Network Architecture

Recommended multi-tier architecture (minimizes CDE scope):

Internet
  ↓
AWS WAF (DDoS protection, rate limiting)
  ↓
Application Load Balancer (TLS termination, 443/tcp)
  ↓
Application Tier (EC2 in private subnet)
  ↓
Tokenization Service (external - Stripe/AWS Payment Cryptography)
  ↓
Database Tier (RDS encrypted, no raw CHD)

CDE Scope: Only ALB + Tokenization service
Out of Scope: Application tier (receives tokens), database tier (no CHD)

PCI-DSS Encryption Requirements

Key Management (CRITICAL):

Key Rotation:
  - Annual minimum (every 365 days)
  - Immediately upon employee departure with key access
  - Immediately upon suspected compromise

Key Storage:
  - Never hardcoded in application code
  - Never stored in source control
  - Use AWS KMS, Azure Key Vault, GCP Cloud KMS
  - Separate key per environment (prod, staging, dev)

Key Access Control:
  - Least privilege: only services needing encryption have access
  - Audit all key usage (CloudTrail logs every KMS call)
  - Alert on unusual key access patterns

Algorithm Requirements:

Strong cryptography: AES-256, RSA-2048 minimum
No deprecated algorithms (DES, MD5, SHA-1)
TLS 1.2 minimum (1.3 preferred)

ISO 27017 & ISO 27018 Cloud Security

ISO 27001 (Information Security Management System) provides the foundation; ISO 27017 and 27018 add cloud-specific controls.

ISO 27017: Cloud Information Security Controls

ISO 27017 addresses cloud-specific threats and requirements:

A.5 Organizational Controls:

Cloud provider vetting and evaluation
Service Level Agreement (SLA) review
Data location and sovereignty requirements
Cloud provider audit rights and transparency

A.6 Personnel Controls:

Background checks for cloud provider staff
Training on cloud-specific security risks
Confidentiality agreements with service providers

A.7 Asset Management:

Inventory of cloud assets across all subscriptions
Asset classification (public, internal, confidential, regulated)
Multi-cloud asset tracking and lifecycle management

A.8 Access Control (Cloud-Specific):

Segregation of duties: no single person controls encryption keys and encrypted data
API key rotation and revocation
Service account credential rotation
Automated access review tools (Entitlement Management)

A.9 Cryptography:

Key generation, storage, rotation in KMS
Key escrow for regulatory requirements (customer-managed keys)
Certificate lifecycle management and auto-renewal
Separate key management for different data classifications

A.10 Physical & Environmental Security:

Cloud provider facility certifications (ISO 27001, SOC 2, etc.)
Audit trail access to physical controls
Supply chain security (chip manufacturing, firmware)

A.11 Operations & Communications:

Change management procedures (deployment automation, audit trails)
Incident response with cloud-specific procedures
Service continuity and disaster recovery testing
Backup and restore testing (annual minimum)

A.12 Access Control & Identification:

Unique cloud identities (no shared accounts)
Multi-factor authentication mandatory
Passwordless authentication where possible
Automatic account provisioning/deprovisioning

A.13 Cryptography & Network Security:

TLS 1.2+ for all data in transit
VPN or private connectivity (AWS Direct Connect, Azure ExpressRoute, GCP Dedicated Interconnect)
DDoS protection (AWS Shield, Azure DDoS Protection, GCP Cloud Armor)

A.14 Communications & Third-party Relations:

Vendor risk assessment before cloud adoption
Regular vendor audits (annual minimum)
Contracts specifying data handling, breach notification, audit rights
Supply chain risk management

A.15 Incident Management:

Incident response runbooks specific to cloud (AWS Lambda compromise, S3 ransomware, etc.)
Automated incident detection
Cloud provider collaboration for forensics
72-hour breach notification (GDPR requirement)

ISO 27018: Cloud PII (Privacy) Controls

ISO 27018 layers privacy-specific controls on top of ISO 27017:

Data Subject Rights:

Right to access: Ability to export all personal data in machine-readable format (GDPR requirement)
Right to correction: Mechanisms to update inaccurate data
Right to erasure ("right to be forgotten"): Delete personal data within 30 days
Right to restrict processing: Temporarily stop data processing
Right to portability: Export data for migration to another provider

Implementation in cloud:

AWS Example:
- DynamoDB export to S3 for data access requests
- Lambda function for data anonymization/deletion
- Automated data retention policy (TTL attribute)

Azure Example:
- Azure Data Explorer for data retrieval
- Azure Purview for data lineage and deletion
- Managed data retention at table level

GCP Example:
- BigQuery data export for subject access requests
- Cloud Data Loss Prevention for automated anonymization
- Dataflow pipeline for bulk data deletion

Purpose Limitation (Data Minimization):

Collect only data necessary for stated purpose
Delete data when no longer required
Regular data inventory reviews
Automated data classification (PII, PHI, regulated)

Storage Limitation:

Maximum retention periods by data type
Automated deletion after retention expires
Regulatory hold mechanisms (litigation/compliance)
Backup retention policies aligned to operational requirements

Transparency & Consent:

Privacy policy clearly describing cloud provider usage
Consent mechanisms for data collection
Sub-processor transparency (AWS subcontractors, SaaS data handling)
Data Processing Agreement (DPA) with cloud provider

GDPR Data Residency & Sovereignty

GDPR (General Data Protection Regulation) applies to any organization handling personal data of EU residents, regardless of where the organization is located.

GDPR Fundamental Principles

1. Lawfulness, fairness, transparency

Legal basis for processing (consent, contract, legal obligation, vital interests, public task, legitimate interests)
Privacy notices given at point of collection
Transparent data practices

2. Purpose limitation

Data collected for explicit, specific purposes only
Secondary use requires separate legal basis
Example: Customer email collected for account notifications cannot be used for marketing without consent

3. Data minimization

Collect only necessary data
Delete fields no longer required
Regular data inventory reviews
Example: Don't collect birth date if only age is required

4. Accuracy

Maintain data accuracy and timeliness
Mechanisms for correction and rectification
Archive outdated data separately

5. Storage limitation

Maximum retention periods (typically 3-7 years depending on purpose)
Automated deletion after retention expires
Exceptions: legal holds, backup requirements

6. Integrity & Confidentiality

Encryption at rest and in transit
Access controls and monitoring
Secure deletion procedures

7. Accountability

Document all processing activities
Data Processing Impact Assessment (DPIA) for high-risk processing
Maintain audit trails
Respond to data subject requests within 30 days

GDPR Data Residency Requirements

Rule: EU personal data must be processed in EU regions

Lawful transfer mechanisms for non-EU processing:
1. Standard Contractual Clauses (SCCs) - explicit legal commitment to GDPR equivalence
2. Binding Corporate Rules (BCRs) - internal data policies for multi-entity organizations
3. Adequacy Decisions - rare, only EU Commission pre-approved jurisdictions
4. EU/UK/Switzerland cloud regions only (primary recommendation)

Compliant Cloud Regions:

Provider	Compliant Regions	Compliance Note
AWS	eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-north-1 (Stockholm)	Explicitly GDPR compliant
Azure	North Europe (Dublin), West Europe (Netherlands)	GDPR compliant; UK regions separate post-Brexit
GCP	europe-west1 (Belgium), europe-west4 (Netherlands)	GDPR compliant regions

Non-compliant approaches (DATA BREACH RISK):

Processing EU data in US regions (potential GDPR violation)
US cloud provider's EU infrastructure if data routes through US
Third-party SaaS processing EU data outside EU

GDPR Data Subject Rights Implementation

Right of Access (Article 15): Provide all personal data within 30 days upon request.

Implementation:
1. Create export API that retrieves all customer data from databases
2. Anonymize associated user IDs (GDPR protection)
3. Return in machine-readable format (JSON, CSV, XML)
4. Audit all export requests in access logs

AWS:
- DynamoDB Query API for customer data
- S3 pre-signed URL for download link (15-minute expiration)
- CloudTrail logs all exports

Right to Rectification (Article 16): Enable customers to correct inaccurate data.

Implementation:
1. User self-service edit interface
2. Audit trail of changes
3. Timestamp before/after values
4. Consider "append only" data model (never delete, immutable records)

Right to Erasure ("Right to be Forgotten") (Article 17): Delete all personal data within 30 days, with limited exceptions.

Exceptions:
- Legal obligations (tax records, 7-year requirement)
- Contract fulfillment (order history if warranty applies)
- Legitimate interests (fraud prevention)

Implementation:
1. Automated deletion pipeline (batch job daily)
2. Archive to separate cold storage before hard deletion
3. Encrypt deleted data for forensic recovery if needed (60 days)
4. Audit trail of what was deleted, when, by whom
5. Inform customer via email confirming deletion

Right to Restrict Processing (Article 18): Pause processing while user disputes accuracy or legality.

Implementation:
1. Flag account as "processing restricted"
2. Stop all processing: marketing emails, analytics, profiling
3. Still accessible for service provision (essential processing)
4. Separate "restricted" dataset from "active" dataset
5. Monitor restricted flag in all processing pipelines

Right to Data Portability (Article 20): Provide data in structured, machine-readable format to transfer to competitor.

Implementation:
1. Export all personal data in standardized format (JSON, CSV)
2. Include related data: transactions, preferences, audit history
3. Machine-readable schema (document fields)
4. Provide within 30 days
5. Tools: DynamoDB exports, BigQuery exports, Stripe API exports

Right to Object (Article 21): Opt-out of processing including direct marketing.

Implementation:
1. Email unsubscribe links (one-click opt-out)
2. User preferences interface (granular opt-outs)
3. Immediately stop processing upon opt-out
4. Maintain "do not contact" list (30-year retention for compliance)
5. Regular list cleaning against customer database

GDPR Breach Notification (Article 33-34)

Timeline:

Without undue delay (typically interpreted as 24-48 hours): Notify supervisory authority (DPA)
Without undue delay (typically 72 hours): Notify affected individuals if breach poses high risk

Notification Requirements:

Name of organization and contact information
Description of likely consequences
Measures taken or proposed (containment steps)
Personal data categories affected
Approximate number of individuals affected
Reference to Data Protection Officer or security contact

Implementation in Cloud:

AWS/Azure/GCP Setup:
1. Security events automatically pushed to SIEM (Splunk, Datadog, Sumo Logic)
2. Custom rules detect: Data exfiltration, unauthorized access, encryption key theft
3. Automated alert to incident response team (<5 minutes)
4. Evidence collection: CloudTrail logs, VPC Flow Logs, database audit logs
5. Forensics & scope assessment: (<24 hours) determine affected records
6. Notification: Email affected individuals with breach details & remediation steps

Governance Policies & Enforcement

Compliance requires not just technical controls but governance—policies that enforce compliance automatically and prevent non-compliant changes.

AWS Organizations & Service Control Policies (SCPs)

Service Control Policies (SCPs) allow centralized guardrails across all AWS accounts:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Uploads",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Sid": "DenyUnencryptedRDSCreation",
      "Effect": "Deny",
      "Action": "rds:CreateDBInstance",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "rds:StorageEncrypted": "false"
        }
      }
    },
    {
      "Sid": "DenyPublicS3Access",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeleteBucketPublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "s3:BlockPublicAcls": "false"
        }
      }
    },
    {
      "Sid": "DenyNonHIPAA Services",
      "Effect": "Deny",
      "Action": [
        "redshift:*",
        "elasticsearch:*",
        "iot:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalTag/Environment": "production"
        }
      }
    }
  ]
}

Key Benefits:

Prevents developers from violating compliance requirements
Applies across all accounts automatically
No individual IAM policy changes needed
Real-time enforcement

Azure Policy & Initiatives

Azure Policy uses JSON rules to enforce compliance at deployment time:

{
  "displayName": "HIPAA: Enforce Encryption at Rest",
  "description": "Ensures all managed disks use customer-managed encryption keys",
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/disks"
        },
        {
          "field": "Microsoft.Compute/disks/encryption.type",
          "notEquals": "EncryptionAtRestWithCustomerKey"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}

Azure Policy Initiatives (Compliance Bundles):

Pre-built policy sets for regulatory frameworks:

HIPAA/HITRUST - 42 policies enforcing healthcare compliance
PCI-DSS v3.2.1 - 36 policies for payment processing
ISO 27001:2013 - 53 policies for information security
NIST 800-53 - Comprehensive security control mapping

Enforcement Options:

Audit mode - Log violations without blocking (evaluation period)
Deny mode - Block non-compliant resource creation
DeployIfNotExists - Auto-remediate (add encryption, enable logging, etc.)

GCP Organization Policy

GCP Organization Policy uses constraints to enforce controls across projects:

# Enforce encryption for Cloud Storage
constraint: storage.uniformBucketLevelAccess
listPolicy:
  deniedValues:
    - projects/*/buckets/*
  inheritFromParent: true

# Restrict VM external IP assignment
constraint: compute.skipDefaultNetworkCreation
booleanPolicy:
  enforced: true

# Enforce Cloud SQL backups
constraint: cloudsql.restrictPublicIp
listPolicy:
  deniedValues:
    - projects/*/instances/*
  inheritFromParent: true

# Require VPC connector for Cloud Functions
constraint: cloudfunctions.requireVpcConnector
booleanPolicy:
  enforced: true

Policy Constraints (Pre-built):

Compute: VM external IPs, disk encryption, image projects
Storage: GCS uniform bucket access, encryption
Database: SQL public IP restriction, backup policy
Networking: VPC restrictions, firewall rules
Identity: Domain restrictions, MFA requirement
Billing: Spend limits, commitment plans

Compliance Automation & Continuous Monitoring

Manual compliance audits (quarterly/annually) miss security gaps between reviews. Modern compliance requires continuous automated monitoring.

Compliance-as-Code Frameworks

1. CloudFormation + AWS Config (AWS):

# CloudFormation template with Config rules
Resources:
  S3BucketEncryptionRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: s3-bucket-encryption-enabled
      Source:
        Owner: AWS
        SourceIdentifier: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED
      Scope:
        ComplianceResourceTypes:
          - AWS::S3::Bucket

  RDSEncryptionRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: rds-encryption-enabled
      Source:
        Owner: AWS
        SourceIdentifier: RDS_STORAGE_ENCRYPTED
      Scope:
        ComplianceResourceTypes:
          - AWS::RDS::DBInstance

  # Automated remediation
  S3EncryptionRemediation:
    Type: AWS::Config::RemediationConfigurations
    Properties:
      ConfigRuleName: s3-bucket-encryption-enabled
      Automatic: true
      MaximumAutomaticAttempts: 5
      RetryAttemptSeconds: 60
      TargetType: SSM_DOCUMENT
      TargetIdentifier: AWS-EnableS3BucketEncryption

Compliance Scoring:

Total Rules: 150 (CIS Benchmarks Level 1)
Compliant Rules: 142
Non-Compliant Rules: 8
Compliance Percentage: 94.7%
Trend: +2.3% (previous month 92.4%)

2. Terraform + Sentinel (HashiCorp):

# Sentinel policy: Enforce HIPAA-required encryption
import "tfplan/v2" as tfplan
import "tfplan/v2" as tfplan/v2

# List of HIPAA-sensitive resources that must be encrypted
hipaa_sensitive_resources = [
  "aws_rds_cluster",
  "aws_rds_cluster_instance",
  "aws_ebs_volume",
  "aws_s3_bucket"
]

# Main validation
main = rule {
  all tfplan.resource_changes as address, rc {
    rc.type in hipaa_sensitive_resources {
      rc.after.storage_encrypted is true or
      rc.after.encryption_configuration[0].enabled is true
    } else {
      true
    }
  }
}

3. OPA (Open Policy Agent) - Multi-Cloud:

# OPA policy: Deny public S3 buckets
deny[msg] {
    input.resource_type == "aws_s3_bucket"
    input.acl == "public-read" or input.acl == "public-read-write"
    msg := sprintf(
        "S3 bucket %s cannot be public (acl: %s)",
        [input.name, input.acl]
    )
}

# OPA policy: Require encryption for databases
deny[msg] {
    input.resource_type in ["aws_rds_instance", "aws_dynamodb_table"]
    input.encryption_at_rest == false
    msg := sprintf(
        "Database %s must enable encryption at rest",
        [input.name]
    )
}

Compliance Dashboards & Reporting

AWS:

AWS Audit Manager (Compliance Automation):
- Automated evidence collection (CloudTrail, Config, Inspector)
- Pre-built compliance frameworks (SOC 2, HIPAA, PCI-DSS)
- Evidence assessment workflows
- Compliance reports with remediation tracking

AWS Security Hub Compliance Dashboard:
- Real-time compliance status across 100+ standards
- Drill-down by finding type, severity, resource
- Compliance trends over time
- Custom remediation workflows

Azure:

Microsoft Defender for Cloud Regulatory Compliance Dashboard:
- NIST 800-53, PCI-DSS, HITRUST, ISO 27001 coverage
- Policy compliance assessment with auto-remediation
- Compliance score timeline
- Export compliance reports for auditors

GCP:

Security Command Center Compliance Dashboard:
- CIS Benchmark, NIST 800-53, PCI-DSS, ISO 27001
- Custom control implementation and evidence
- Compliance assessment by framework
- Export findings in audit-ready format

Third-Party Compliance Automation

Dedicated Compliance Platforms:

Tool	Coverage	Key Features
Drata	AWS, Azure, GCP	SOC 2, ISO 27001, HIPAA automation; evidence collection
Vanta	AWS, Azure, GCP, Okta, Slack	Continuous compliance; audit readiness; assessment management
Laika	AWS, Azure, GCP	Compliance gaps, remediation tracking, evidence collection
Cloudanix	AWS, Azure, GCP	CIS Benchmarks, NIST, PCI-DSS; governance policy enforcement
Wiz	AWS, Azure, GCP	Cloud risk, compliance gaps, infrastructure-as-code scanning

Audit Logging & Evidence Collection

Compliance audits require comprehensive evidence: logs proving that controls are in place and effective.

Compliance Evidence Requirements

For SOC 2 Type II Audits:

Evidence must span a 6-12 month period proving:

Control design (policy documentation, architecture diagrams)
Control operation (logs showing control execution)
Control effectiveness (monitoring, incident response)
Control testing (penetration tests, vulnerability scans)

Common Evidence Types:

Access logs (CloudTrail, Azure Activity Log, Cloud Logging)
Configuration snapshots (AWS Config, Azure Policy, GCP Config)
Change logs (deployment history, policy modifications)
Monitoring alerts (threshold violations, security events)
Incident response records (tickets, remediation timelines)
Training records (security awareness completion)
Vendor assessments (cloud provider audit reports)
Penetration test results
Vulnerability scan reports

Centralized Logging Architecture

Multi-cloud logging strategy:

AWS CloudTrail → CloudWatch Logs
                ↓
Azure Activity Log → Log Analytics
                ↓
GCP Cloud Audit Logs → Cloud Logging
                ↓
[Central SIEM: Splunk / ELK / Datadog]
                ↓
[Compliance Dashboard: Search, Alert, Report]
                ↓
[Audit Export: CSV/PDF for auditors]

Implementation:

AWS:

1. Enable CloudTrail in all regions (Organization Trail)
2. CloudTrail → S3 bucket (encrypted, versioning, MFA delete)
3. S3 → CloudWatch Logs (real-time streaming)
4. CloudWatch Logs → Splunk (via Lambda/Kinesis)
5. CloudWatch Alarms on critical events:
   - Root account usage
   - IAM policy changes
   - CloudTrail disabled
   - S3 public access grant
   - KMS key deletion
   - RDS encryption disabled

Azure:

1. Enable Activity Log for all subscriptions
2. Activity Log → Log Analytics workspace
3. Log Analytics → Splunk (via API connector)
4. Alert rules for critical events:
   - Password policy changes
   - Role assignments
   - Network security group modifications
   - Key vault access
   - Storage account permission changes

GCP:

1. Enable Cloud Audit Logs (Admin Activity, Data Access, System Events)
2. Cloud Logging → BigQuery export (long-term retention)
3. BigQuery → Splunk (via connector)
4. Alert rules for:
   - Service account key creation
   - IAM policy changes
   - VPC firewall rule modifications
   - Cloud SQL instance changes

Compliance Query Examples

SOC 2: Trust Service Criteria Validation

-- Trust Service: Security (TSC CC6.1)
-- Verify: Logical access to production systems restricted to authorized personnel

SELECT
    timestamp,
    user_identity.principal_id as user_id,
    event_name,
    source_ip_address,
    resources.arn as resource_accessed
FROM cloudtrail_logs
WHERE
    resource_type = 'AWS::EC2::Instance'
    AND environment_tag = 'production'
    AND user_id NOT IN (SELECT principal_id FROM approved_users)
    AND timestamp > NOW() - INTERVAL 1 DAY
ORDER BY timestamp DESC;
-- Expected: 0 rows (no unauthorized access)

HIPAA: PHI Access Audit (HIPAA Security Rule Audit Controls)

-- Verify: Audit logs capture all PHI access attempts

SELECT
    timestamp,
    user_identity.principal_id as user_id,
    event_name,
    request_parameters,
    response_elements,
    source_ip_address
FROM cloudtrail_logs
WHERE
    resources.arn LIKE '%/tables/patient_records%'
    OR resources.arn LIKE '%/data/phi_database%'
    AND timestamp > NOW() - INTERVAL 7 DAYS
ORDER BY timestamp DESC
LIMIT 1000;
-- Expected: All PHI access logged with user/timestamp/resource

PCI-DSS: Cardholder Data Environment Access (Requirement 7 - Least Privilege)

-- Verify: Only authorized roles access cardholder data environment

SELECT
    user_identity.principal_id,
    user_identity.assumed_role_arn,
    event_name,
    resources.arn,
    COUNT(*) as access_count
FROM cloudtrail_logs
WHERE
    resources.arn LIKE '%cde-env%'
    AND event_name IN ('GetObject', 'PutObject', 'DeleteObject', 'DescribeDBInstances')
    AND timestamp > NOW() - INTERVAL 7 DAYS
GROUP BY user_identity.principal_id, user_identity.assumed_role_arn, event_name, resources.arn
ORDER BY access_count DESC;
-- Expected: Only service roles (not human users) accessing CDE

Shared Responsibility Model Clarification

Cloud compliance fails when organizations misunderstand shared responsibility—assuming the cloud provider handles everything or accepting responsibility for provider-controlled services.

Service Model Responsibility Mapping

Service Model	Provider Controls	Customer Controls
Infrastructure as a Service (IaaS)	Compute hypervisor, networking hardware, datacenter, encryption algorithms, physical security	OS patching, firewall rules, IAM policies, encryption keys, application security
Platform as a Service (PaaS)	Compute, networking, OS, middleware, encryption at rest & transit	Application code, application secrets, access controls, data classification
Software as a Service (SaaS)	Entire stack (infrastructure, platform, application)	User authentication, data governance, access control, data retention

AWS Services: Compliance Responsibility by Service

Customer-Managed Services (Higher Compliance Burden):

Service	Customer Responsibility	Example
EC2	OS patching, firewall rules, intrusion detection, application security	Install security patches, configure security groups, run endpoint protection
RDS	Database patching, encryption key management, backup testing, user access control	Patch DB software, rotate encryption keys, test restore procedures, manage IAM database roles
S3	Bucket policies, encryption at rest (KMS key rotation), bucket logging, versioning	Create KMS key, enforce bucket encryption, enable access logging, configure MFA delete
Lambda	Runtime patching, function code review, secrets management, function logging	Update function code with security fixes, use Secrets Manager for credentials, enable CloudWatch logs
VPC	Network segmentation, security groups, NACLs, route tables, VPC Flow Logs	Configure security groups, implement network ACLs, enable Flow Logs, monitor network traffic

AWS-Managed Services (Lower Compliance Burden):

Service	AWS Responsibility	Customer Responsibility
DynamoDB	Encryption, backups, patching, availability	Encryption key management, IAM access control, monitoring
Aurora	Engine patching, failover, encryption at rest	Minor version patches, encryption key rotation, backup retention
Kinesis	Streaming infrastructure, scalability, encryption	Encryption key management, consumer application security
SNS/SQS	Message delivery, encryption, durability	Encryption key management, IAM access control, message handling

Key Implication for Compliance:

Organizations using self-managed EC2 instances have significantly higher compliance burden compared to managed services (RDS, DynamoDB, ECS).

Example: EC2 vs. RDS for HIPAA Compliance

EC2 (Self-Managed):
- Customer: OS patches (monthly), firewall rules, intrusion detection, encryption key rotation, backup testing
- Higher operational burden

RDS (AWS-Managed):
- AWS: Engine patches, encryption, backups, availability
- Customer: Focus on encryption key rotation, IAM access control
- Lower operational burden, easier compliance

Putting It All Together: Compliance Validation Checklist

Use our comprehensive Compliance Readiness Checklist to systematically validate your cloud compliance posture across all frameworks.

Compliance validation workflow:

Select Applicable Frameworks - Identify which standards apply to your organization (PCI-DSS, HIPAA, SOC 2, ISO 27001, GDPR, CIS Benchmarks)
Run Automated Scans - Execute compliance scanning tools (AWS Security Hub, Azure Policy, GCP SCC) to identify gaps
Document Controls - For each requirement, document:
- Technical control (encryption, access control, logging)
- Operational procedure (who performs control, how often, approval process)
- Evidence (logs, audit trails, testing results)
- Remediation timeline if non-compliant
Assess Vendor Risk - Evaluate third-party SaaS vendors using our Vendor Risk Management Scorecard to ensure they don't introduce compliance gaps
Establish Continuous Monitoring - Deploy automated compliance dashboards and alerting
Plan Remediation - Prioritize findings by severity and implement fixes
Test & Validate - Verify remediation effectiveness before considering finding closed
Audit Preparation - Collect and organize evidence for external auditors

Key Takeaways

Cloud compliance requires multi-layered approach: CIS Benchmarks (foundation) + regulatory frameworks (HIPAA, PCI-DSS, SOC 2, GDPR) + governance enforcement (SCPs, Azure Policy, GCP constraints)
Automation is non-negotiable: Manual quarterly audits miss gaps between reviews. Deploy continuous compliance monitoring with automated evidence collection and remediation.
Shared responsibility requires clear accountability: Understand which controls are your responsibility vs. cloud provider responsibility for each service type.
Data residency matters: For GDPR, healthcare data, and highly regulated workloads, keep data in compliant regions (EU for GDPR, specific regions for HIPAA/PCI-DSS).
Evidence collection enables audits: Build comprehensive logging architecture from day one; SOC 2, ISO 27001, and PCI-DSS audits require 6-12 months of evidence.
Governance policies prevent violations: Service Control Policies, Azure Policy, and GCP Organization Policy stop non-compliant changes before they reach production.
Regular vendor assessment reduces risk: Use Third-party risk tools to continuously validate that cloud providers and SaaS vendors maintain their security commitments.

Related Resources

See Cloud Infrastructure Audit & Optimization Pipeline for comprehensive multi-stage audit workflow
Infrastructure-as-Code Security & Change Management for IaC compliance scanning
NIST Cybersecurity Framework Guide for detailed CSF mapping to cloud
AWS: CIS Benchmarks Guide
Azure: Azure Security Benchmark
GCP: Google Cloud Security Foundations Blueprint

Last Updated: January 6, 2025 Version: 1.0

Cloud Compliance & Governance: ISO 27017, SOC 2, HIPAA, and PCI DSS Validation

Introduction

Understanding the Cloud Compliance Landscape

Why Cloud Compliance Differs from On-Premises

Compliance Framework Interrelationships

Framework 1: CIS Benchmarks as Compliance Foundation

CIS Benchmark Levels

CIS Benchmark Coverage by Cloud (2025)

Automated CIS Assessment Tools

Common CIS Benchmark Gaps

HIPAA Compliance for Healthcare Workloads

HIPAA Safeguard Tiers

PHI Encryption in Cloud

HIPAA Audit Logging Configuration

HIPAA Breach Notification

PCI DSS Compliance for Payment Processing

PCI-DSS Scope Determination

PCI-DSS 12 Requirements Mapped to Cloud

PCI-DSS Network Architecture

PCI-DSS Encryption Requirements

ISO 27017 & ISO 27018 Cloud Security

ISO 27017: Cloud Information Security Controls

ISO 27018: Cloud PII (Privacy) Controls

GDPR Data Residency & Sovereignty

GDPR Fundamental Principles

GDPR Data Residency Requirements

GDPR Data Subject Rights Implementation

GDPR Breach Notification (Article 33-34)

Governance Policies & Enforcement

AWS Organizations & Service Control Policies (SCPs)

Azure Policy & Initiatives

GCP Organization Policy

Compliance Automation & Continuous Monitoring

Compliance-as-Code Frameworks

Compliance Dashboards & Reporting

Third-Party Compliance Automation

Audit Logging & Evidence Collection

Compliance Evidence Requirements

Centralized Logging Architecture

Compliance Query Examples

Shared Responsibility Model Clarification

Service Model Responsibility Mapping

AWS Services: Compliance Responsibility by Service

Putting It All Together: Compliance Validation Checklist

Key Takeaways

Related Resources

Simplify Your Compliance Journey

Related Tools

Compliance Readiness Checklist

Vendor Risk Management "Breach-Proof" Scorecard

Related Articles

SOC 2 Compliance Services - Get Certified in 3-6 Months

How to conduct a GDPR compliance audit?

How often should you reassess vendor security?