9.4 Cloud Compliance Frameworks & Governance Auditing

Cloud Compliance Frameworks & Governance Auditing

Migrating enterprise workloads to the public cloud does not absolve an organization of its legal, regulatory, or industry compliance obligations. Under the Cloud Shared Responsibility Model, while the Cloud Service Provider (CSP) maintains compliance for the underlying physical infrastructure, hypervisors, and data centers, the cloud customer retains full legal liability for the compliance of their configurations, data classification, and access governance.

For the CompTIA Cloud+ (CV0-004) examination, cloud professionals must understand global compliance frameworks (SOC 1/2/3, ISO/IEC 27001/27017/27018, PCI DSS 4.0, HIPAA/HITECH, GDPR, FedRAMP), navigate cloud compliance portals such as AWS Artifact, and implement programmatic guardrails using Policy-as-Governance across enterprise multi-account hierarchies.

---

1. Global Regulatory & Industry Compliance Frameworks

+-----------------------------------------------------------------------------------------+
|                        MAJOR CLOUD COMPLIANCE FRAMEWORKS MATRIX                         |
|                                                                                         |
|   Framework          Target Domain / Scope              Key Technical Mandates          |
|   +----------------+----------------------------------+-------------------------------+ |
|   | SOC 1 (SSAE 18)| Financial Reporting Controls     | Internal Controls over        | |
|   |                | (ICFR)                           | Financial Reporting (ICFR)    | |
|   |                |                                  |                               | |
|   | SOC 2 (AICPA)  | Cloud Service Trust Principles   | Security (Common Criteria),   | |
|   |                | (SaaS, IaaS, Managed Providers)  | Availability, Confidentiality,| |
|   |                |                                  | Processing Integrity, Privacy | |
|   |                |                                  |                               | |
|   | ISO/IEC 27001  | Information Security Management  | Formal ISMS, risk treatment,  | |
|   |                | System (ISMS)                    | continuous audit cycle        | |
|   |                |                                  |                               | |
|   | ISO/IEC 27017  | Cloud Security Specifics         | Delineates cloud customer vs  | |
|   |                |                                  | CSP security responsibilities | |
|   |                |                                  |                               | |
|   | ISO/IEC 27018  | Cloud PII Protection             | Protection of Personal Data   | |
|   |                |                                  | in Public Cloud Storage       | |
|   |                |                                  |                               | |
|   | PCI DSS 4.0    | Payment Card Data                | CDE Network Segmentation,     | |
|   |                | (Credit card processing/storage) | AES-256 encryption, strict MFA| |
|   |                |                                  |                               | |
|   | HIPAA / HITECH | Healthcare Data (ePHI)           | Mandatory BAA execution,      | |
|   |                |                                  | audit logging, ePHI encryption| |
|   |                |                                  |                               | |
|   | GDPR / CCPA    | Consumer Privacy & Data Rights   | Data residency, Right to      | |
|   |                |                                  | Erasure, cross-border transfer| |
|   |                |                                  |                               | |
|   | FedRAMP        | US Federal Government Agencies   | Low, Moderate, High baseline  | |
|   |                | and defense contractors          | authorizations (NIST SP 800-53)| |
|   +----------------+----------------------------------+-------------------------------+ |
+-----------------------------------------------------------------------------------------+

SOC 1, SOC 2, and SOC 3 Reports

Developed by the American Institute of Certified Public Accountants (AICPA), Service Organization Control (SOC) reports evaluate an organization's internal controls:

• SOC 1 (SSAE 18): Focuses strictly on controls relevant to a client's Internal Control over Financial Reporting (ICFR) (e.g., payroll processing, billing engines).
• SOC 2: Evaluates cloud and technology service providers against the Trust Services Criteria (TSC): Security (the baseline Common Criteria required in every report), Availability, Processing Integrity, Confidentiality, and Privacy.
• SOC 2 Type I vs. Type II:
  • Type I Report: Evaluates the suitability of the design of an organization's security controls at a single specific point in time (e.g., as of June 30).
  • Type II Report: Evaluates both the design and the operational effectiveness of security controls over a continuous testing period (typically 6 to 12 months). Enterprise customers and compliance auditors almost universally require SOC 2 Type II reports because they provide historical evidence that controls functioned consistently over time.
• SOC 3: A publicly distributable summary of the SOC 2 examination providing a high-level seal of compliance without disclosing proprietary technical architecture details.

ISO/IEC Cloud Standards Family

• ISO/IEC 27001: Global standard defining the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).
• ISO/IEC 27017: A specialized code of practice extending ISO 27002 specifically for cloud services. It outlines security controls for both cloud service providers and cloud customers, covering topics such as virtual machine isolation, administrator shared credentials, and cloud network monitoring.
• ISO/IEC 27018: The first international standard focused exclusively on the protection of Personally Identifiable Information (PII) in public cloud environments. It prohibits CSPs from using customer PII for advertising or marketing without explicit consent and mandates breach notification protocols.

Payment Card Industry Data Security Standard (PCI DSS 4.0)

PCI DSS applies to any entity that stores, processes, or transmits Cardholder Data (CHD) (Primary Account Numbers, cardholder names, expiration dates) or Sensitive Authentication Data (SAD) (CVV/CVC codes, PINs).

• Cardholder Data Environment (CDE) Segmentation: A fundamental cloud architectural requirement. By placing payment processing systems inside dedicated, isolated Virtual Private Clouds (VPCs) or subnets with restrictive firewall rules blocking all non-essential traffic, organizations isolate the CDE and drastically reduce the scope and cost of PCI DSS compliance audits.
• Core Technical Requirements: Enforcing AES-256 encryption at rest, TLS 1.3 in transit, strict multi-factor authentication (MFA) for all administrative access, quarterly external vulnerability scans by an Approved Scanning Vendor (ASV), and annual penetration testing.

Healthcare: HIPAA & HITECH

• Health Insurance Portability and Accountability Act (HIPAA) & HITECH Act: Regulates the storage, transmission, and processing of electronic Protected Health Information (ePHI).
• Business Associate Agreement (BAA): A legally binding contractual agreement required between a healthcare entity (Covered Entity) and a cloud service provider (Business Associate). The BAA outlines shared liabilities, data safeguarding duties, and mandatory breach notification timelines (under 60 days). No ePHI can be legally hosted in a public cloud until a BAA is fully executed with the CSP.

Privacy Frameworks: GDPR & CCPA

• General Data Protection Regulation (GDPR): Comprehensive European Union privacy regulation governing personal data of EU residents.
  • Key Principles: Data minimization, purpose limitation, storage limitation, and data accuracy.
  • Data Subject Rights: Right of Access, Right to Rectification, Right to Data Portability, and the Right to Erasure ('Right to be Forgotten') requiring organizations to permanently delete all personal data upon request.
  • Cross-Border Data Transfers: Restricts transferring EU personal data to third countries lacking an adequacy decision unless protected by Standard Contractual Clauses (SCCs) or binding corporate rules.
• California Consumer Privacy Act (CCPA / CPRA): Grants California consumers rights regarding the collection, sale, and deletion of personal data.

Data Sovereignty, Data Locality, Data Residency & Retention Obligations

CompTIA Cloud+ distinguishes three frequently confused data-governance concepts:

Data retention obligations arrive from three sources, all of which dictate how long cloud data, backups, and logs must be preserved:

1. Regulatory Retention: Statutes and industry frameworks impose minimum retention periods (HIPAA-related documentation for six years, SEC Rule 17a-4 broker-dealer records for three to six years, PCI DSS log retention for twelve months).
2. Contractual Retention: Private customer agreements, Business Associate Agreements, or service contracts requiring data availability for negotiated periods.
3. Litigation Hold (Legal Hold): When litigation or a regulatory investigation is reasonably anticipated, the organization must suspend every routine deletion and retention-expiry policy and preserve potentially relevant data — including cloud snapshots, object versions, and audit logs — indefinitely until legal counsel releases the hold. Failing to disable automated lifecycle deletion during a litigation hold constitutes spoliation of evidence and invites court sanctions.

[!CAUTION] Exam Trap: A recurring scenario shows a company under litigation hold whose object-storage lifecycle policy keeps auto-deleting old versions. The correct remediation is to suspend the lifecycle rule and apply a Legal Hold / Object Lock — not merely to extend the retention window.

Federal Authorizations: FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) standardizes security assessment, authorization, and continuous monitoring for cloud products consumed by U.S. federal agencies, standardizing controls based on NIST SP 800-53 across three baseline authorization levels:

• Low Impact: 125 controls; systems where loss of confidentiality, integrity, or availability has limited adverse effects.
• Moderate Impact: 325 controls; standard baseline for most federal agency applications and non-sensitive PII.
• High Impact: 421 controls; critical federal systems (healthcare, emergency services, law enforcement) where data compromise could result in catastrophic financial or operational harm.

---

2. Cloud Compliance Portals & Continuous Auditing

To prove compliance to external auditors, organizations retrieve provider attestation packages directly from automated hyperscaler compliance management portals:

+-----------------------------------------------------------------------------------------+
|                        NATIVE CLOUD COMPLIANCE REPOSITORIES                             |
|                                                                                         |
|   Provider     Compliance Portal        Primary Deliverables / Functionality            |
|   +----------+------------------------+-----------------------------------------------+ |
|   | AWS      | AWS Artifact           | On-demand access to AWS SOC 1/2/3 reports,    | |
|   |          |                        | ISO certifications, PCI DSS packages, and BAA | |
|   |          | AWS Audit Manager      | Automates evidence collection against mapped  | |
|   |          |                        | compliance frameworks (HIPAA, PCI, CIS)       | |
|   |          |                        |                                               | |
|   | Azure    | Service Trust Portal / | Download SOC/ISO reports; interactive score-  | |
|   |          | Microsoft Compliance   | card tracking regulatory posture improvement  | |
|   |          | Manager                |                                               | |
|   |          |                        |                                               | |
|   | GCP      | Compliance Reports     | Central repository for SOC, ISO, FedRAMP,     | |
|   |          | Manager                | and regional compliance documentation         | |
|   +----------+------------------------+-----------------------------------------------+ |
+-----------------------------------------------------------------------------------------+

---

3. Policy-as-Governance & Multi-Account Guardrails

Modern enterprise cloud architectures deploy multi-account structures (e.g., AWS Organizations, Azure Management Groups, Google Cloud Resource Hierarchy). Programmatic governance enforces guardrails to ensure tenant accounts cannot violate compliance policies.

+-----------------------------------------------------------------------------------------+
|                        MULTI-ACCOUNT POLICY GOVERNANCE HIERARCHY                        |
|                                                                                         |
|   [ Enterprise Organization Root ]                                                      |
|   |                                                                                     |
|   +--> Attached: Service Control Policy (SCP) / Organization Policy                     |
|        - DENY: Any action outside allowed regions (e.g., us-east-1, us-west-2)          |
|        - DENY: Deletion of Centralized CloudTrail / Audit Logs                          |
|        - DENY: Disabling EBS Volume Encryption by default                               |
|        |                                                                                |
|        +--> [ Production Organizational Unit (OU) ]                                     |
|        |    |                                                                           |
|        |    +--> Account A (Prod Web) <=== Guardrails strictly enforced                 |
|        |    +--> Account B (Prod DB)  <=== Even account ROOT user cannot bypass SCP!    |
|        |                                                                                |
|        +--> [ Development Organizational Unit (OU) ]                                    |
|             |                                                                           |
|             +--> Account C (Dev Sandbox) <=== Relaxed permissions, but regional         |
|                                                residency SCP remains absolute!          |
+-----------------------------------------------------------------------------------------+

AWS Service Control Policies (SCPs)

• Guardrails, Not Permissions: SCPs specify the maximum permissions that member accounts in an organization or Organizational Unit (OU) can exercise. SCPs do not grant permissions; they act as a filter. If an SCP explicitly denies an action (Deny), no user or role (even the account root user) in that account can perform the action.
• Enforcing Data Sovereignty via SCP:

Version: '2012-10-17'
Statement:
  - Sid: DenyAllOutsideApprovedRegions
    Effect: Deny
    NotAction:
      - 'iam:*'
      - 'organizations:*'
      - 'route53:*'
      - 'cloudfront:*'
      - 'support:*'
    Resource: '*'
    Condition:
      StringNotEquals:
        'aws:RequestedRegion':
          - us-east-1
          - us-west-2

Azure Policy & Google Cloud Organization Policies

• Azure Policy: Enforces organizational rules across Azure subscriptions and Management Groups. Enforcement effects include Deny (prevents resource deployment if non-compliant), Audit (logs a non-compliance warning), and DeployIfNotExists (automatically deploys required resources, such as diagnostic log forwarding).
• Google Cloud Organization Policies: Provides centralized programmatic control over organization cloud resources, restricting resource location constraints (e.g., constraints/gcp.resourceLocations), disabling service account key creation, or restricting public IP attachment.

CompTIA Cloud+ Exam Traps & Real-World Gotchas

1. The Inheritance Fallacy: Deploying an application on a HIPAA-compliant or FedRAMP-certified cloud provider does NOT automatically make the customer's application compliant! The customer remains responsible for securing application code, encrypting database tables, managing IAM roles, and executing a formal BAA.
2. SOC 2 Type I vs. Type II: For regulatory audits and vendor risk reviews, a SOC 2 Type I report (a snapshot of design at one moment) is rarely accepted as sufficient proof of sustained operational effectiveness; auditors require a SOC 2 Type II report covering 6 to 12 months of live operational evidence.
3. SCPs Do Not Grant Access: An SCP attached to an AWS OU with Allow *:* does NOT grant any user access to anything; an IAM policy attached to a user or role inside the account must still explicitly grant Allow permissions.