ISO/IEC 27001 is an international standard for Information Security Management Systems (ISMS). It specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS. Organizations can be certified by an accredited third-party auditor.

Key components:

• Annex A: 93 control categories (ISO 27001:2022) covering organizational, people, physical, and technological controls
• Risk-based: Organizations select controls based on a risk assessment, not all controls are mandatory
• Plan-Do-Check-Act (PDCA): Continuous improvement cycle

Cloud-specific extensions:

• ISO 27017: Additional controls specifically for cloud service providers and cloud customers
• ISO 27018: Controls for protection of PII in public cloud services

• SOC 2 Type I: Auditor assesses whether security controls are suitably designed at a single point in time. Tests control design only — not whether they actually worked over time.
• SOC 2 Type II: Auditor assesses whether controls operated effectively over an observation period (typically 6–12 months). Much stronger assurance — proves controls actually worked.

Enterprise buyers almost always require SOC 2 Type II. Type I is useful when starting the compliance journey or as a quick interim report.

Trust Service Criteria (TSC): Security (required), Availability, Confidentiality, Privacy, Processing Integrity (optional — chosen based on scope).

PCI-DSS (Payment Card Industry Data Security Standard) v4.0 has 12 requirements:

1. Install and maintain network security controls (firewalls)
2. Apply secure configurations (no vendor defaults)
3. Protect stored account data (encrypt at rest)
4. Protect cardholder data in transit (TLS)
5. Protect all systems against malware (AV/EDR)
6. Develop and maintain secure systems and software (patching, SDLC)
7. Restrict access by business need (least privilege)
8. Identify users and authenticate (strong passwords, MFA)
9. Restrict physical access to cardholder data
10. Log and monitor all access (audit logs)
11. Test security regularly (penetration testing, vulnerability scans)
12. Support information security with organizational policies

The Cardholder Data Environment (CDE) is the set of people, processes, and technology that store, process, or transmit cardholder data (Primary Account Number, cardholder name, expiry, CVV) or that are connected to systems that do.

All PCI-DSS requirements apply within the CDE. Reducing CDE scope is the most effective way to reduce PCI compliance burden:

• Tokenization: Replace the PAN with a non-sensitive token. The real PAN is stored in a token vault (often a third-party payment processor). Your systems only ever see the token — dramatically reducing scope.
• Network segmentation: Isolate CDE from non-CDE systems using firewalls, VLANs, or separate cloud accounts. Systems that cannot reach the CDE are out of scope.
• Use a PCI-certified payment processor: Stripe, Braintree, Adyen handle the CDE entirely — you redirect users to their hosted payment page.

GDPR (General Data Protection Regulation) is EU law governing how personal data of EU/EEA residents is collected, stored, processed, and transferred. It applies to any organization worldwide that processes EU citizen data.

Cloud-specific implications:

• Data residency: Must understand where data is stored (AWS region, Azure datacenter). Some GDPR interpretations require EU data to stay in EU.
• Data transfers: Transferring EU personal data outside EU/EEA requires safeguards: Standard Contractual Clauses (SCCs), adequacy decisions, or Binding Corporate Rules
• DPA with CSP: Must have a Data Processing Agreement (DPA) with your cloud provider — AWS, Azure, GCP all provide DPAs
• Breach notification: Must notify supervisory authority within 72 hours of discovering a personal data breach
• Data subject rights: Right of access, rectification, erasure (right to be forgotten), portability, restriction, objection — must be technically implementable

Fines: up to €20 million or 4% of global annual revenue (whichever is higher).

HIPAA (Health Insurance Portability and Accountability Act) requires that covered entities (hospitals, insurers, healthcare providers) sign a Business Associate Agreement (BAA) with any vendor or partner (Business Associate) that handles Protected Health Information (PHI) on their behalf.

A BAA is a legal contract that:

• Defines how the BA will safeguard PHI
• Specifies permitted uses and disclosures of PHI
• Requires the BA to report security incidents and breaches
• Ensures the BA implements HIPAA Security Rule safeguards

Cloud context:

• AWS, Azure, and GCP all offer BAAs for HIPAA-eligible services
• Not all cloud services are HIPAA-eligible — AWS has a specific list of HIPAA-eligible services
• Without a signed BAA, you cannot store PHI in that cloud service — period

FedRAMP (Federal Risk and Authorization Management Program) is a US government program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies.

Who needs it: Any cloud service provider (CSP) that wants to sell to US federal government agencies MUST obtain FedRAMP authorization. Without it, agencies cannot use the service to process government data.

Process:

• Security baselines: Low, Moderate, High (based on NIST 800-53 control levels)
• 3PAO: Third-Party Assessment Organization performs the security assessment
• ATO: Authorization to Operate — issued by the sponsoring agency or FedRAMP PMO (Joint Authorization Board)
• Continuous monitoring: Monthly vulnerability scans, annual assessments, ongoing reporting

AWS GovCloud, Azure Government, GCP Government Cloud are FedRAMP-authorized cloud environments.

The CSA Cloud Controls Matrix (CCM) v4 is a cybersecurity control framework developed by the Cloud Security Alliance (CSA) specifically for cloud environments. It contains 197 control objectives organized across 17 domains (e.g., Identity & Access Management, Data Security, Infrastructure & Virtualization Security).

Primary value: CCM maps each control to multiple compliance frameworks simultaneously:

• ISO/IEC 27001:2013
• SOC 2 Trust Service Criteria
• PCI-DSS v3.2.1
• HIPAA
• NIST 800-53
• GDPR

This allows a single set of controls to demonstrate compliance across multiple frameworks — reducing audit fatigue and redundant work. The companion CAIQ (Consensus Assessment Initiative Questionnaire) is a self-assessment questionnaire that cloud customers use to evaluate CSP security.

This is a critical distinction often tested in interviews:

• Compliance means meeting the minimum requirements of a specific regulation or standard at a point in time. It's binary: compliant or not. It looks backward (did we meet the standard during the audit period?).
• Security is the ongoing practice of identifying and mitigating risks to protect systems and data. It looks forward — is the organization resilient against emerging threats?

Key insight: A compliant organization is not necessarily secure, and a secure organization may not be compliant.

• An org can pass a PCI-DSS audit but still be breached through an unscoped system the next day
• An org may have excellent security practices that don't map to a specific compliance framework

Best approach: use compliance as the floor, security as the ceiling. Compliance sets minimum requirements; actual security goes beyond what's audited.

AWS Control Tower is a managed service that automates the setup of a multi-account AWS environment (Landing Zone) following AWS best practices. It provides:

• Landing Zone: Pre-configured multi-account structure (Management account, Log Archive account, Audit account)
• Guardrails: Pre-built governance rules — Mandatory (always enforced), Strongly Recommended, Elective. Implemented as SCPs and AWS Config Rules.
• Account Factory: Account vending machine — provision new accounts with security baseline automatically
• Dashboard: Compliance status of all accounts in one view

Security benefits:

• Every new account automatically gets centralized logging (CloudTrail to Log Archive), IAM baseline, and mandatory guardrails
• Prevents non-compliant account configurations from day 1
• Scales governance to hundreds of accounts

In cloud compliance audits, responsibility is split between what the Cloud Service Provider (CSP) covers and what the customer must demonstrate:

What the CSP provides (their responsibility):

• SOC 2 Type II reports for their infrastructure
• ISO 27001 / 27017 / 27018 certifications
• FedRAMP authorizations (for eligible services)
• PCI-DSS attestations (Attestation of Compliance / AOC)

These CSP reports can be included as evidence in your audit to cover the physical, hypervisor, and managed service layers.

What the customer must demonstrate:

• IAM configuration (who has access to what)
• Data encryption configuration
• Logging and monitoring setup
• Application-level controls
• Security policies and training
• Incident response procedures

Auditors want to see: CSP's compliance reports + your configuration + your policies/procedures = combined evidence package.

A cloud risk assessment identifies, analyzes, and evaluates risks to cloud assets to prioritize mitigation efforts. Process:

1. Asset Inventory: What cloud services, accounts, regions, and data types are in scope?
2. Threat Identification: What threats are relevant? (Misconfiguration, credential theft, insider threat, CSP outage, etc.)
3. Vulnerability Assessment: What weaknesses exist? (CSPM findings, missing controls, over-privilege)
4. Risk Analysis: Likelihood × Impact = Risk Level for each threat/vulnerability pair
5. Risk Register: Document all risks with owner, likelihood, impact, current controls, residual risk
6. Risk Treatment: Accept, Mitigate, Transfer (cyber insurance), or Avoid each risk
7. Review Cycle: Reassess periodically or after significant changes

Cloud-specific risks to assess: vendor lock-in, data sovereignty, CSP region outage, API key compromise, misconfigured storage, supply chain risk from third-party integrations.

A Landing Zone is a pre-configured, secure, multi-account cloud environment that provides a governance foundation for workloads. It establishes guardrails, accounts structure, networking, logging, and identity before any workloads are deployed — ensuring everything built on top starts from a secure baseline.

Typical Landing Zone components:

• Account structure: Management account, Security/Audit account, Log Archive account, Sandbox accounts, Production accounts (in separate OUs)
• Networking: Hub VPC, shared services, DNS, Direct Connect/VPN connectivity
• Security baseline: CloudTrail in all regions, Config rules, Security Hub enabled, GuardDuty enabled
• IAM: SSO setup, federated identity, break-glass accounts
• Compliance: SCPs enforcing guardrails across all accounts

Implementations: AWS Control Tower, Azure Landing Zone (Enterprise-Scale), GCP Foundation (terraform-example-foundation).

SCPs are policy documents attached to AWS Organizations OUs (Organizational Units) or accounts that define the maximum permissions any IAM identity in those accounts can have — regardless of what IAM policies grant.

Key characteristics:

• SCPs do NOT grant permissions — they set ceilings (guardrails). Actual permissions still require IAM policies.
• Applied hierarchically: Management Account → OUs → Member Accounts → IAM identities
• Cannot restrict the Management (root) account itself

Common SCP use cases:

• Deny access to non-approved AWS regions: Deny * unless region in [us-east-1, eu-west-1]
• Prevent disabling CloudTrail: Deny cloudtrail:StopLogging
• Require MFA for sensitive actions: Deny DeleteBucket unless MFA is present
• Prevent leaving the Organization
• Restrict to approved services only (allowlist)

COBIT (Control Objectives for Information and Related Technologies) 2019 is a governance framework for enterprise IT published by ISACA. It provides a comprehensive framework for IT governance and management across five governance objectives: Evaluate, Direct, Monitor (Board-level) and Align, Plan, Organize, Build, Acquire, Implement, Deliver, Service, Support, Monitor, Evaluate (Management-level).

Cloud relevance:

• Provides governance processes for cloud strategy decisions (make vs buy, multi-cloud vs single cloud)
• Defines IT risk management processes applicable to cloud risk assessment
• Maps to ISO 38500 (IT Governance standard)
• Used by GRC teams and CIOs to align IT governance with business objectives

COBIT vs NIST CSF vs ISO 27001:

• COBIT = IT governance (broader than security)
• ISO 27001 = information security management
• NIST CSF = cybersecurity risk management framework

• ISO/IEC 27001: The main ISMS standard. Framework for establishing, implementing, and maintaining an information security management system. Certifiable. Applies to all organizations.
• ISO/IEC 27017: Code of Practice providing additional guidelines and controls specifically for cloud services — both for cloud service providers AND cloud customers. Not separately certifiable (extends 27001).
• ISO/IEC 27018: Code of Practice for protection of personally identifiable information (PII) in public cloud computing — the "cloud data privacy" standard.

Practical difference: ISO 27001 covers the full ISMS. ISO 27017 adds cloud-specific guidance like: who is responsible for cloud service administration, how to handle multi-tenant environments, transparency about subcontractors, monitoring of cloud services.

Standard Contractual Clauses (SCCs) are pre-approved model contract clauses published by the European Commission that provide legal safeguards for transferring personal data from the EU/EEA to third countries (countries without an EU adequacy decision).

Why needed:

• GDPR restricts transfer of EU personal data to countries outside the EU/EEA unless adequate protection exists
• Only a handful of countries have adequacy decisions (UK, Japan, Canada, etc.)
• For transfers to the US (where most cloud providers are based): No adequacy decision exists post-Schrems II (2020) — SCCs are the primary mechanism

Practical use:

• AWS, Azure, GCP include SCCs in their Data Processing Agreements (DPAs)
• Customer must still conduct a Transfer Impact Assessment (TIA) to verify SCCs provide sufficient protection

Updated 2021 SCCs replaced the old SCCs and added four modules for different transfer scenarios (controller→controller, controller→processor, etc.).

The AWS Well-Architected Tool is a free AWS service (available in the AWS Console) that helps you review your cloud workloads against AWS best practices across six pillars:

1. Operational Excellence
2. Security (identity, detection, infrastructure protection, data protection, incident response)
3. Reliability
4. Performance Efficiency
5. Cost Optimization
6. Sustainability

How it works:

• You answer a series of questions about your workload architecture
• The tool identifies high-risk issues (HRIs) and medium-risk issues (MRIs)
• Provides prioritized recommendations with links to detailed guidance
• Generates a PDF report suitable for sharing with leadership

For security reviews: the Security Pillar questions cover IAM, detective controls, infrastructure protection, data protection, and incident response.

Multi-framework control mapping (also called "compliance as code" or unified GRC) avoids duplicating work for each framework. Approaches:

• CSA CCM as a meta-framework: CCM maps 197 controls to ISO 27001, SOC 2, PCI-DSS, HIPAA, NIST. Implement controls once, demonstrate compliance to many.
• GRC platforms: Drata, Vanta, Secureframe, ServiceNow GRC — automate evidence collection, map controls to frameworks, provide real-time compliance dashboards
• Control families: Group similar requirements (e.g., "MFA for privileged accounts" satisfies: ISO 27001 A.9.4, SOC 2 CC6.1, PCI-DSS Req 8, NIST 800-53 IA-5). Implement once, map to all.
• NIST 800-53 as a superset: NIST 800-53 is one of the most comprehensive control sets — mapping to it effectively covers most other frameworks

Process: Build a control library → Map each control to all applicable frameworks → Automate evidence collection → Use tool to generate reports per framework from common evidence.

Azure Policy is a governance service that allows you to create, assign, and manage policies that enforce specific rules on Azure resources — ensuring resources remain compliant with organizational standards.

Policy effects:

• Deny: Prevents non-compliant resource creation/modification
• Audit: Flags non-compliant resources without blocking (good for assessment)
• DeployIfNotExists: Automatically deploys a related resource if it doesn't exist (e.g., auto-enable diagnostics on VMs)
• Modify: Adds/replaces properties on non-compliant resources

Key features:

• Policy Initiatives (Policy Sets): Group related policies for a compliance framework (built-in: CIS, NIST, ISO 27001, PCI-DSS)
• Regulatory Compliance Dashboard: Visual compliance status mapped to CIS, NIST, ISO 27001, PCI-DSS
• Remediation tasks: Fix existing non-compliant resources automatically

Applied at: Management Group → Subscription → Resource Group → Resource levels (inheritance).