Defines requirements for establishing, operating, and continually improving an ISMS. The foundational standard — certification requires an external audit. Everything in the 27000 series extends or supports it. 27001 sets requirements; 27002 gives the how.
Implementation guidance organised by domain (e.g. Asset Management, Access Control, Cryptography). Included as an appendix in 27001. The two work together: 27001 sets requirements, 27002 provides detailed control guidance and implementation advice.
Extends ISO 27002 with cloud-specific guidance for both CSPs and cloud customers. Added 35 new controls and extended 7 existing ones — covering VM hardening, cloud admin segregation, customer data isolation, and virtual network security.
Code of practice for protection of PII where the CSP acts as a PII processor. Supplements 27002 with 14 new controls and extensions to 25 existing ones. Covers consent, transparency, customer data control, and audit. Relevant for GDPR and PIPEDA alignment.
Extends 27001/27002 to implement a PIMS. Relevant whenever an organisation handles PII as a data owner or processor. Helps satisfy privacy regulatory requirements (e.g. GDPR) within an existing ISMS structure.
Guidance on incident management — planning, detection, assessment, response, and lessons learned. Relevant to cloud incident response plans and breach notification obligations.
Four-part series covering security in outsourcing and supply chain relationships, including cloud services. Addresses supplier agreements, risk in ICT supply chains, and how to manage security across the full cloud service lifecycle.
Guidance on identifying, collecting, and producing electronically stored information (ESI) in legal proceedings. Important for cloud forensics, legal holds, and data preservation obligations.
Specifies requirements for a BCMS. Defines how organisations prepare for, respond to, and recover from disruptive incidents. Used alongside BC/DR planning in cloud environments.
Requirements for ITSM. Aligned with ITIL. Relevant to cloud operations management, SLA management, change management, and continual service improvement.
Generic risk management guidelines — design, implementation, and review of risk management processes. Not cloud-specific or security-specific; applicable to any risk type. Complemented by IEC 31010 (assessment techniques) and ISO Guide 73 (vocabulary).
Companion to ISO 31000. Provides guidance on risk assessment techniques — quantitative, qualitative, and semi-quantitative methods for identifying and analysing risk.
Standardised risk management vocabulary. Ensures consistent language when implementing ISO 31000 and related standards across an organisation.
International standard for certifying security of hardware/software products. Assigns Evaluation Assurance Levels (EAL 1–7). Primarily used by government agencies. See Government Standards section for EAL detail.
A system lifecycle approach to managing security and privacy risk. Replaced the old Certification & Accreditation model with continuous monitoring rather than periodic reviews. Foundation for FedRAMP.
Comprehensive catalogue of security and privacy controls for federal information systems. Organised into control families (e.g. Access Control, Audit & Accountability, Configuration Management). Used as the control baseline for FedRAMP. Free for any organisation to use.
Originally for private-sector critical infrastructure, now widely adopted by all sectors. Organises controls into five functions: Identify › Protect › Detect › Respond › Recover. Lightweight, free, and maps cleanly to ISO 27001 and other frameworks.
The canonical cloud computing definition. Defines 5 essential characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service), 3 service models (IaaS/PaaS/SaaS), and 4 deployment models (public/private/community/hybrid).
Practical guidance on cloud adoption, risk considerations, and security implications for organisations evaluating cloud services. Referenced alongside ISO 31000 and ENISA for cloud risk management.
Covers clearing, purging, and destruction of storage media. Important for cloud data destruction obligations at end-of-life or contract termination, where physical destruction may not always be available.
Defines a four-phase incident response lifecycle: Preparation › Detection & Analysis › Containment, Eradication & Recovery › Post-Incident Activity. Referenced for cloud incident response planning.
Covers log generation, storage, analysis, and protection. Relevant to cloud audit logging requirements, retention policies, and SIEM deployment.
Defines PII, identifies confidentiality safeguards, and provides a risk-based approach to PII protection. Relevant to cloud privacy controls and data classification.
Defines principles of zero trust (never trust, always verify) and provides guidance on designing ZTA deployments. Relevant to microsegmentation, identity-centric security, and software-defined perimeters in cloud.
Covers hardening the hypervisor, VM isolation, virtual network security, and management plane protection — core concerns in IaaS cloud infrastructure security.
Maps security practices to SDLC phases: prepare the organisation, protect software, produce well-secured software, respond to vulnerabilities. Referenced for DevSecOps and cloud application security.
US GSA programme providing a standardised, centralised security authorisation process for cloud services used by federal agencies. Based on NIST SP 800-53 controls. CSPs undergo an Assessment & Authorisation (A&A) process by a third-party assessor (3PAO). One authorisation applies across all federal agencies, avoiding duplicative reviews.
US law requiring all federal agencies to implement information security programmes. Does not itself specify controls — NIST SP 800-53 provides the actual implementation guidance. FedRAMP implements FISMA requirements specifically for cloud environments.
UK government cloud marketplace. CSPs must demonstrate compliance with G-Cloud framework security controls to be listed. Divided into cloud hosting, software, and support categories. Allows public sector bodies to procure pre-approved cloud services without individual competitive tenders.
Certification framework for evaluating security of hardware/software products. Higher EAL = more testing rigour applied — NOT necessarily a more secure product. Vendor selects target level; costs rise steeply at higher levels.
US standard for validating cryptographic modules. FIPS 140-2 is being retired (by 2026) — FIPS 140-3 is the current standard (based on ISO/IEC 19790). Both use the same 4-level scheme. FIPS 140-3 addresses emerging threats and newer technologies.
Specifies approved hash algorithms including SHA-1, SHA-2, and SHA-3 families. Referenced for data integrity verification in cloud environments. Many platforms offer FIPS-compliant modes for hash functions alongside FIPS 140-2/3 encryption.
AICPA standard governing how SOC audits are conducted and reported in the US. Effective May 2017. Used by auditors performing SOC engagements — not directly implemented by service providers or customers.
International equivalent to SSAE 18, issued by the IAASB. Roughly equivalent in scope to SOC 2. The major cloud providers (AWS, Azure, GCP) provide audit reports under both SSAE 18 and ISAE 3402 to serve US and international customers.
SOC 1 = financial reporting controls | SOC 2 = security/availability/processing integrity/confidentiality/privacy | SOC 3 = public summary of SOC 2. SOC 2 is the de facto standard for cloud security assurance.
Cloud Security Alliance cloud-specific security controls framework organised into domains (e.g. Application & Interface Security, Encryption & Key Management, Identity & Access Management). Cross-maps to ISO 27001, NIST SP 800-53, PCI DSS, COBIT, and others — useful for demonstrating compliance across multiple frameworks simultaneously.
CSP evaluation programme using the CCM as its control framework. The STAR registry is publicly available, making CSP security posture transparent to customers. Two levels: Level 1 (self-assessment, free) and Level 2 (third-party audit against CCM; can be combined with SOC 2 or ISO 27001).
ENISA-developed certification scheme for cloud cybersecurity. Structure is similar to Common Criteria — includes assurance levels, self-assessment options, and requirements for conformance assessment bodies (CABs). Still under development as of the CBK.
EU cloud risk assessment tool providing a structured approach to identifying and evaluating cloud-specific risks. Referenced alongside ISO 31000 and NIST 800-37 as a risk management framework, particularly in the EU context.
Applies to any organisation processing personal data of EU residents, regardless of where the organisation is located. Key provisions: lawful basis for processing; data subject rights (access, rectification, erasure, portability); 72-hour breach notification to supervisory authority; DPIAs required for high-risk processing; cross-border transfers require adequacy decisions, SCCs, or BCRs.
Applies to covered entities (healthcare providers, insurers, clearinghouses) and their business associates. Separate rules for Privacy, Security, and Breach Notification. CSPs storing PHI on behalf of covered entities must sign a Business Associate Agreement (BAA). PHI in cloud must be adequately protected.
Strengthened and extended HIPAA (2009). Breach notification rules: notify affected individuals within 60 days; notify HHS; notify media if >500 individuals affected in a state. Extended HIPAA obligations directly to business associates.
Applies to financial institutions. Three key rules: Financial Privacy Rule (regulates collection and disclosure of private financial info); Safeguards Rule (requires a security programme); Pretexting Provisions (prohibits obtaining info under false pretences). Explicitly requires access controls, encryption, monitoring, and testing.
Applies to publicly traded US companies. Key cloud provisions: Section 802 — criminal offence to destroy/alter documents to prevent use in legal proceedings; Section 804 — audit-related records must be retained for a minimum of 5 years. Requires internal control reports and formal data security policies. Enforced by the SEC.
Governs privacy of student educational records. Applies to educational institutions receiving federal funding. Students (or parents of minors) have rights to access, amend, and control disclosure of their records.
Canadian federal private-sector privacy law. Governs collection, use, and disclosure of personal information in commercial activities. Includes breach notification obligations. Similar in spirit to GDPR but predates it.
Mandatory cybersecurity requirements for the bulk electric system in North America. Relevant to cloud security in critical infrastructure contexts.
Voluntary framework guiding cross-border data flows in the Asia-Pacific region. Basis for the APEC Cross-Border Privacy Rules (CBPR) system, which serves a similar role to GDPR SCCs for intra-APEC data transfers.
Applies to NY-licensed financial services companies. Requires a cybersecurity programme, designated CISO, annual certification of compliance, and incident reporting. Example of how cloud security requirements can arise from regional regulators.
Contractually required by card brands (Visa, Mastercard, etc.) for any organisation that accepts, processes, stores, or transmits cardholder data. 12 core requirements covering network security, access control, monitoring, and testing. Cloud-relevant provisions include isolating the cardholder data environment (CDE), least privilege access, logging, and forensic support.
Published jointly by the AICPA and CICA. 10 principles: (1) Management, (2) Notice, (3) Choice & Consent, (4) Collection, (5) Use/Retention/Disposal, (6) Access, (7) Disclosure to Third Parties, (8) Security for Privacy, (9) Quality, (10) Monitoring & Enforcement. Now incorporated as an optional Trust Services Criterion in SOC 2.
EU Commission-approved contractual clauses providing an adequate safeguard for transferring personal data from the EU/EEA to third countries without an adequacy decision. Currently the primary mechanism used by most organisations (including major CSPs) for EU-to-US data transfers post-Privacy Shield invalidation.
Internal codes of conduct approved by EU supervisory authorities, allowing multinational corporate groups to transfer personal data between group entities across borders. More complex to obtain than SCCs but more durable for large organisations with ongoing intra-group transfers.
Former EU-US data transfer framework. Invalidated by the Court of Justice of the EU in 2020 (Schrems II decision) due to concerns about US government surveillance. Replaced in practice by SCCs. Its predecessor Safe Harbor was similarly invalidated in 2015 (Schrems I).
Predecessor to Privacy Shield for EU-US data transfers. Invalidated by the CJEU in 2015 (Schrems I). Both Safe Harbor and Privacy Shield are now defunct — awareness of this history is exam-testable.
The most widely referenced list of critical web application security risks (e.g. Injection, Broken Access Control, Security Misconfiguration, Cryptographic Failures). Key reference for secure coding, code review, and API security in cloud applications. Updated periodically by OWASP.
OWASP framework for evaluating and improving the security of a software development organisation. Organised into business functions (Governance, Design, Implementation, Verification, Operations) with maturity levels. Used to assess and roadmap DevSecOps maturity.
Specifies approved hash algorithms including SHA-1, SHA-2, and SHA-3 families. Referenced for data integrity verification in cloud environments. Many platforms offer FIPS-compliant modes for hash functions, just as they do for encryption under FIPS 140-2/3.