CCSP Certified Cloud Security Professional ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ COMPREHENSIVE EXAM

PREPARATION GUIDE All 6 Domains · Technical Deep Dives · Feynman Explanations · Scenario Walkthroughs ·
75 Key Points Based on ISC² Official Syllabus · Effective October 2025 Sources: ISC² CCSP Official Study Guide
(Chapple & Seidl, Sybex) + CCSP All-in-One Exam Guide (Carter) · Validated May 2026 against NIST, ISO, OWASP, PCI
SSC, HHS, EC, NSA, FedRAMP, and ISC² authoritative sources

CCSP Exam Overview

Term / Concept Explanation / Detail
Exam Format Computerized Adaptive Testing (CAT) — item difficulty adapts in real time based on
your performance. Questions become harder as you answer correctly, easier if you
struggle. You must reach statistically reliable performance before the minimum 100
items. Exam ends at 100 items (if statistically clear pass/fail) or continues to 150
items.
Item Types Multiple-choice single-answer (most common), Drag-and-drop, Hotspot (click on
correct part of image), Ordering (arrange steps in correct sequence). The adaptive
engine adjusts based on ALL item types.
Duration 3 hours (180 minutes). Pace at approximately 72 seconds per question. Do not
spend more than 3 minutes on any single question — mark for review and return.
Passing Score 700 out of 1000 scaled score. Scaled scoring accounts for question difficulty
differences across exam versions — not a simple 70% correct.
Experience Requirement 5 years cumulative paid work in IT, including 3 years in information security and 1
year in at least one of the 6 CCSP domains. OR: Hold CISSP to waive the entire
experience requirement. Hold CSA CCSK to waive 1 year. Hold qualifying degree
(computer science, IT, cybersecurity) to waive 1 year.
Associate Path Pass the exam first, then earn required experience within 6 years. No experience
needed to take the exam.
Current Syllabus October 2025 version applies until July 31, 2026. NEW exam outline effective August
1, 2026. If you are taking the exam before August 2026, this guide covers your exam.

Term / Concept Explanation / Detail

Domain 1 — 17% Cloud Concepts, Architecture and Design
Domain 2 — 20% Cloud Data Security — HIGHEST WEIGHT. Deep study required.
Domain 3 — 17% Cloud Platform and Infrastructure Security
Domain 4 — 17% Cloud Application Security
Domain 5 — 16% Cloud Security Operations
Domain 6 — 13% Legal, Risk and Compliance

PRO TIP: CCSP questions are scenario-based and test judgment, not memorisation. Every question has a
business context (what does the organisation need?), a regulatory/compliance context (what law or standard
applies?), a technical context (what service model, deployment model?), and a responsibility question (who —
CSP or customer — owns this control?). Train yourself to identify all four before choosing an answer.
 D1 17% of exam CLOUD CONCEPTS, ARCHITECTURE AND DESIGN Foundation
domain — master this first; every other domain builds on
these concepts

1.1 Cloud Computing Fundamentals

FEYNMAN EXPLANATION | What Is Cloud Computing? — The Utility Analogy
Think of electricity. Before public power grids existed, every factory had to build and operate its own generator
— buying equipment, hiring engineers, maintaining it 24/7, and hoping it would not fail during peak production.
The entire burden of power generation sat on the factory owner's desk. Then commercial power companies
emerged. Factories unplugged their generators and plugged into the grid. They paid only for kilowatts
consumed, nothing more. The power company handled generation, transmission, and maintenance. The
factory's core competency — making goods — was no longer encumbered by being a power company. Cloud
computing did exactly the same thing for information technology. Instead of buying servers, storage arrays,
networking equipment, and hiring full data centre operations teams, organisations simply connect to a cloud
provider's infrastructure over the internet and pay only for the compute, storage, and bandwidth they actually
consume. The NIST SP 800-145 definition (the authoritative exam definition): 'Cloud computing is a model for
enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing
resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and
released with minimal management effort or service provider interaction.' This definition contains the key
phrase 'minimal management effort' — the customer does not need to call someone to provision a server. They
click a button (or run an API call) and it is done. This self-service model is what distinguishes cloud from
traditional managed hosting.

The Five NIST Essential Characteristics — Detailed

Term / Concept Explanation / Detail
On-Demand Self-Service The consumer can unilaterally provision computing capabilities — such as server
time and network storage — as needed automatically without requiring human
interaction with each service provider. The key word is 'unilaterally': no phone calls,
no purchase orders, no waiting for a vendor to configure hardware. You open the
AWS console, click 'Launch Instance', and a server is running in 60 seconds. This self-
service model dramatically changes the security paradigm: employees can now
provision entire cloud environments without involving IT, creating the shadow IT
problem that cloud governance programmes must address.
Broad Network Access Capabilities are available over the network and accessed through standard
mechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,
mobile phones, tablets, laptops, workstations). The cloud is not accessed via a
proprietary dedicated circuit but over standard TCP/IP networks using standard
protocols (HTTPS, REST APIs). Accessibility from any device, anywhere, at any time is
the defining characteristic. Security implication: the attack surface extends to every
device anywhere in the world that can reach the internet — there is no 'inside the
perimeter' assumption in cloud security.
Resource Pooling The provider's computing resources are pooled to serve multiple consumers using a
multi-tenant model, with different physical and virtual resources dynamically
assigned and reassigned according to consumer demand. There is a sense of
location independence in that the customer generally has no control or knowledge
over the exact location of the provided resources but may be able to specify location
at a higher level of abstraction (e.g., country, state, data centre). Resources include
storage, processing, memory, and network bandwidth. This is the economic engine
of cloud: by pooling resources across thousands of customers with different peak
periods, the provider achieves utilisation rates that would be impossible for any
 single customer.
Rapid Elasticity Capabilities can be elastically provisioned and released, in some cases automatically,
to scale rapidly outward and inward commensurate with demand. To the consumer,
the capabilities available for provisioning often appear to be unlimited and can be
appropriated in any quantity at any time. The 'automatically' qualifier is critical —
true elastic scaling does not require a human to notice high load and manually add
capacity. Auto-scaling groups (AWS) and virtual machine scale sets (Azure)
automatically add and remove instances based on CPU, memory, or custom metrics.
Elasticity is bidirectional: scale OUT when demand spikes, scale IN when demand
drops to save cost.
Measured Service Cloud systems automatically control and optimise resource use by leveraging a
metering capability at some level of abstraction appropriate to the type of service
(e.g., storage, processing, bandwidth, and active user accounts). Resource usage can
be monitored, controlled, and reported, providing transparency for both the
provider and consumer of the utilised service. This is the utility billing model: you
receive an itemised bill showing exactly what resources were consumed, when, and
at what cost. Security implication: the billing data itself is a security signal —
anomalous charges may indicate compromised accounts spinning up crypto-mining
instances.

EXAM ALERT: EXAM DISTINCTION — Elasticity vs Scalability: Scalability means a system CAN be expanded to
handle more load (the capability exists). Elasticity means the system AUTOMATICALLY expands AND contracts in
real time based on actual demand — without human intervention. A system is scalable if you can add servers
manually. It is elastic if it adds AND removes servers automatically based on demand metrics. All elastic systems
are scalable, but not all scalable systems are elastic. When exam scenarios mention 'variable, unpredictable
workloads' the answer almost always involves elasticity.

Sixth Characteristic: Multitenancy (ISO/IEC 17788)

ISO/IEC 17788 (Cloud Computing Vocabulary) adds multitenancy as a sixth characteristic not present in the NIST
definition but critical for understanding cloud security:
Term / Concept Explanation / Detail
Multitenancy Multiple customers (tenants) share the same physical infrastructure while having
logically isolated environments. The same physical server, storage array, or network
switch may simultaneously serve hundreds of different organisations. This is the
source of cloud's economic advantages — and its most significant security challenge.
Tenant isolation must be absolute: Tenant A must never be able to access Tenant B's
data, configurations, or network traffic. Isolation is achieved through: hypervisors
(compute isolation), VLANs and VPCs (network isolation), object store bucket
policies and IAM (storage isolation), and key management boundaries
(cryptographic isolation).
Multi-tenancy Security The attack category specific to multitenancy is the 'noisy neighbour' effect
Implications (performance) and cross-tenant data leakage (security). The Spectre and Meltdown
CPU vulnerabilities demonstrated that carefully crafted timing attacks could extract
data from adjacent VMs sharing the same physical CPU. VM escape attacks target
the hypervisor boundary. Side-channel attacks exploit timing differences in shared
caches. These threats do not exist in single-tenant dedicated infrastructure.

Cloud Computing Roles and Responsibilities (ISO/IEC 17788 / 17789)

FEYNMAN EXPLANATION | Who Does What in Cloud — The Ecosystem of Actors
Cloud computing is not just a technical arrangement — it is a web of relationships among organisations with
distinct roles, responsibilities, and liabilities. Understanding who is responsible for what security control is
fundamental to the CCSP exam. Think of building a commercial office block. The property developer (Cloud
Service Provider) builds and maintains the building — structure, lifts, electrical systems, common areas. Each
tenant (Cloud Service Customer) is responsible for the security within their leased space — locking their doors,
controlling who has access, and what they do inside their offices. A facilities management company (Cloud
Service Partner) might provide cleaning or security guard services to multiple tenants. A Cloud Service Broker is
like a commercial real estate broker — they help tenants find the right space, negotiate terms, and might
bundle services from multiple buildings. The Cloud Auditor is the building inspector — an independent party
who verifies the structure meets safety codes and the tenant spaces meet their specific requirements. The
critical security question in cloud: 'Who is responsible for THIS specific security control?' The answer depends on
the service model (IaaS/PaaS/SaaS) and the role of the party in question.

Term / Concept Explanation / Detail

Cloud Service Customer (CSC) The organisation (or individual) that purchases cloud services and uses them for
business purposes. In B2B cloud: the CSC is a company, not an end user.
Responsibilities: configuring cloud resources securely, managing identities and
access controls within their tenant environment, encrypting their data (in most
models), and ensuring their usage complies with applicable regulations. The CSC is
almost always the Data Controller under GDPR — they determine WHY and HOW
personal data is processed. Key roles within CSC: Cloud Service User (uses the
service), Cloud Service Administrator (manages cloud resources), Cloud Service
Business Manager (handles commercial relationship with CSP).
Cloud Service Provider (CSP) The organisation that builds, operates, and maintains the cloud infrastructure and
services. Responsible for: physical security of data centres, hypervisor security and
patching, network infrastructure, the availability and reliability of the service. In
SaaS: also responsible for the application. In PaaS: also responsible for the OS and
runtime. In IaaS: responsible only for the physical layer and hypervisor. The CSP is
typically a Data Processor under GDPR — they process data on the customer's
instructions. Major CSPs: Amazon Web Services (AWS), Microsoft Azure, Google
Cloud Platform (GCP), Alibaba Cloud, Oracle Cloud.
Cloud Service Partner Third parties that build on or enhance cloud services. Types: Independent Software
Vendors (ISVs) who sell software through CSP marketplaces, System Integrators who
connect cloud services to enterprise environments, Managed Service Providers
(MSPs) who operate cloud environments on behalf of customers, Value-Added
Resellers (VARs) who bundle and resell cloud services with additional services.
Partners often create their own security responsibilities — if an MSP manages your
AWS environment, they bear responsibility for the operational security of that
management.
Cloud Service Broker (CSB) An entity that manages use, performance, and delivery of cloud services and
negotiates relationships between CSPs and customers. Three categories of
brokerage: Service Intermediation (value-added services on top of a CSP offering),
Service Aggregation (combine multiple cloud services into a single offering), Service
Arbitrage (choose from multiple CSPs opportunistically based on price, performance,
location). Security consideration: a broker has elevated access to multiple cloud
environments — must be carefully vetted and the data they can access clearly
scoped.
Cloud Auditor An independent party that audits cloud services, assessing controls, security
practices, and compliance. Provides assurance reports that customers rely on
instead of conducting their own audits (because customers cannot physically inspect
CSP infrastructure). Types of audit outputs: SOC 2 reports, ISO 27001 certifications,
FedRAMP authorisations, PCI DSS Reports on Compliance (ROC), CSA STAR
certifications. The auditor must be independent of both the CSP and the customer.
Auditor independence is a key requirement — an internal audit team cannot provide
the same level of assurance as an external accredited auditor.
Cloud Service User The individual human who actually uses a cloud application. Note the distinction:
the Cloud Service Customer is the ORGANISATION (the company that signed the
contract and pays the bill). The Cloud Service User is the PERSON who uses the
 application (an employee of that company, or a consumer using a SaaS application).
This distinction matters for GDPR — users are often data subjects; customers are
often data controllers.

1.2 Cloud Service Models and Shared Responsibility

FEYNMAN EXPLANATION | The Pizza Analogy — Shared Responsibility Made Memorable
The cloud shared responsibility model determines who is responsible for each layer of security. It changes
completely depending on which service model you are using. The pizza analogy (from Microsoft) makes this
intuitive. On-Premises: You make everything from scratch. You buy the raw ingredients (hardware), make the
dough (OS), add the sauce and toppings (applications), and bake it yourself (operations). You are responsible for
EVERY layer. If the oven breaks — your problem. If you burn the pizza — your problem. IaaS — Infrastructure as
a Service: You rent the kitchen (compute, storage, network). You still bring your ingredients and cook. You are
responsible for what you cook (OS, applications, data). The landlord is responsible for the oven working and the
building having power. AWS EC2 is a kitchen — they give you a server, you install the OS, middleware, and
applications. PaaS — Platform as a Service: You get a pre-made pizza base from the restaurant. You choose and
add your own toppings (application code). The restaurant provides and maintains the base, the oven, and the
cooking environment. Azure App Service — Microsoft manages the OS, runtime, and platform; you deploy your
application code. SaaS — Software as a Service: You order a fully-made pizza from Domino's. All you do is
choose from the menu (configure user preferences) and eat it (consume the service). Domino's is responsible
for ingredients, cooking, everything. Salesforce — Salesforce runs the entire application; you configure settings
and manage your users. The critical exam insight: As you move from IaaS to SaaS, MORE responsibility shifts to
the CSP. But one responsibility NEVER shifts — data classification and data ownership always remains with the
customer. YOU always remain accountable for YOUR data under regulatory frameworks.

Term / Concept Explanation / Detail

IaaS — Infrastructure as a NIST SP 800-145 definition: 'The capability provided to the consumer is to provision
Service processing, storage, networks, and other fundamental computing resources where
the consumer is able to deploy and run arbitrary software, which can include
operating systems and applications. The consumer does not manage or control the
underlying cloud infrastructure but has control over operating systems, storage, and
deployed applications; and possibly limited control of selected networking
components.' CSP Responsible For: Physical security, hardware, hypervisor, network
infrastructure. Customer Responsible For: OS and its patches, middleware, runtime
environment, application code, application security, data classification and
protection, identity and access management configuration, network security groups,
encryption of data. Examples: AWS EC2, Azure Virtual Machines, GCP Compute
Engine.
PaaS — Platform as a Service NIST SP 800-145 definition: 'The capability provided to the consumer is to deploy
onto the cloud infrastructure consumer-created or acquired applications created
using programming languages, libraries, services, and tools supported by the
provider. The consumer does not manage or control the underlying cloud
infrastructure including network, servers, operating systems, or storage, but has
control over the deployed applications and possibly configuration settings for the
application-hosting environment.' CSP Responsible For: Physical security, hardware,
hypervisor, network infrastructure, OS patches, runtime environment, middleware,
platform services. Customer Responsible For: Application code, application security,
data, user access management. Critical exam point: IN PaaS, THE CSP PATCHES THE
OS. The customer has NO access to the OS and cannot patch it themselves.
Examples: AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku.
SaaS — Software as a Service NIST SP 800-145 definition: 'The capability provided to the consumer is to use the
provider's applications running on a cloud infrastructure. The applications are
accessible from various client devices through either a thin client interface, such as a
web browser (e.g., web-based email), or a program interface. The consumer does
 not manage or control the underlying cloud infrastructure including network,
servers, operating systems, or storage, or even individual application capabilities,
with the possible exception of limited user-specific application configuration
settings.' CSP Responsible For: Everything — physical, network, compute, OS,
middleware, application, application security, availability. Customer Responsible
For: User account provisioning and deprovisioning, access controls within the
application, data the customer puts into the application, client device security.
Examples: Salesforce, Microsoft 365, Google Workspace, Workday, ServiceNow.
FaaS — Function as a Service A PaaS sub-model for event-driven serverless computing. The customer writes small,
focused functions that execute in response to events (HTTP requests, queue
messages, file uploads). No server management whatsoever — the CSP handles all
infrastructure, scaling, and maintenance. Billed per execution and per millisecond of
execution time. Security implications unique to FaaS: Functions are ephemeral —
they start, execute, and stop. Security agents may not fully initialise before the
function completes. Logs may not be captured. Cold start gap: the first execution
after idle may take longer, creating a window where monitoring may not have fully
attached. The function execution context is shared (though isolated) — function-
level IAM is critical. Examples: AWS Lambda, Azure Functions, Google Cloud
Functions, Cloudflare Workers.
CaaS — Container as a Service CSP provides a managed container orchestration platform. Customer deploys
containerised applications. CSP manages the Kubernetes control plane, worker node
OS, and underlying infrastructure. Customer manages: container images,
Kubernetes workload configurations, network policies, RBAC for the K8s API.
Security responsibility: the container image is the customer's responsibility — if it
contains vulnerable libraries, that is a customer problem regardless of the managed
platform. Examples: AWS EKS (Elastic Kubernetes Service), Azure AKS, Google GKE.

Shared Responsibility Matrix — Who Patches What?

Security Layer On-Premises IaaS PaaS SaaS
Physical Security Customer CSP CSP CSP
Network Infrastructure Customer CSP CSP CSP
Hypervisor Customer CSP CSP CSP
Guest OS Patching Customer CUSTOMER CSP CSP
Middleware / Runtime Customer Customer CSP CSP
Application Code Customer Customer Customer CSP
Application Config Customer Customer Customer Customer*
Data Classification Customer Customer Customer Customer
Identity & Access Mgmt Customer Customer Customer Customer
Encryption Keys Customer Customer Customer Customer
* SaaS customers typically manage user-specific application configuration settings only. | CUSTOMER in capitals = most commonly tested on
exam.

EXAM ALERT: The single most common question type about service models: 'Who is responsible for patching
the operating system?' IaaS = CUSTOMER. PaaS = CSP. SaaS = CSP. This distinction also determines who is
responsible for OS-level vulnerabilities. In IaaS, an unpatched OS vulnerability is 100% the customer's liability. In
PaaS, it is 100% the CSP's liability.

1.3 Cloud Deployment Models

Term / Concept Explanation / Detail
Public Cloud Infrastructure owned and operated by the CSP, made available to the general public
or a large industry group. All customers share the same underlying physical
hardware (with logical isolation). Characteristics: Multi-tenant, shared hardware,
CSP manages all physical infrastructure, lowest unit cost, highest elasticity. Security
profile: Strong logical isolation implemented by CSP, but customers share physical
hardware — side-channel attacks are theoretically possible. Customers have limited
visibility into underlying security controls and must rely on third-party attestations
(SOC 2, ISO 27001). Vendors: AWS, Microsoft Azure, Google Cloud Platform, Alibaba
Cloud, Oracle Cloud.
Private Cloud Cloud infrastructure provisioned for exclusive use by a single organisation
comprising multiple consumers (e.g., business units). May be owned, managed, and
operated by the organisation, a third party, or some combination of them. May exist
on or off the organisation's premises. Not multi-tenant with external parties — no
sharing of physical resources with other organisations. Characteristics: Single tenant,
dedicated hardware (or dedicated portions), organisation retains greater control,
higher cost per compute unit, limited to the organisation's own capacity. Security
profile: Greater control over physical security, network architecture, and
configuration. Organisation is responsible for all layers. No concern about co-
resident tenant attacks. Best suited for: Highly regulated industries (financial
services, healthcare, government), organisations with data sovereignty
requirements, organisations with predictable, high-utilisation workloads.
Community Cloud Infrastructure provisioned for exclusive use by a specific community of consumers
from organisations that have shared concerns (e.g., mission, security requirements,
policy, compliance considerations). May be owned, managed, and operated by one
or more of the organisations in the community, a third party, or some combination.
Shared costs and infrastructure among a defined group with common requirements.
Examples: G-Cloud (UK government agencies sharing HIPAA-equivalent
requirements), Defence Community Cloud (US DoD member organisations sharing
security classification requirements), Healthcare community cloud for hospital
groups sharing HIPAA requirements, Financial services community cloud meeting
FINRA/SEC requirements. Security: Intermediate between public and private —
hardware shared only within the defined community, all members have similar
security profiles and regulatory requirements.
Hybrid Cloud Composition of two or more distinct cloud infrastructures (private, community, or
public) that remain unique entities, but are bound together by standardised or
proprietary technology that enables data and application portability. Use cases:
Cloud Bursting — run normal workloads in private cloud, overflow seasonal peaks to
public cloud (e.g., retail organisation runs order processing in private cloud but
bursts to AWS during Black Friday). Data Sovereignty — keep sensitive regulated
data in private cloud while running non-sensitive workloads in public cloud for cost
efficiency. DR/BC — primary operations in private/co-location, secondary region in
public cloud for disaster recovery. Development and Testing — use private cloud for
production, public cloud for cheaper dev/test environments. Security challenge:
Consistent security controls must span both environments — the weakest link (often
the connectivity between environments) becomes the most critical attack vector.
Multi-Cloud Use of services from two or more different cloud service providers. NOT an official
NIST deployment model but increasingly common and tested on the exam.
Motivations: Avoid vendor lock-in (no single CSP dependency), Best-of-breed
selection (use AWS for compute, Azure for Office 365 integration, GCP for ML/AI),
Geographic coverage (CSP A has better presence in Asia, CSP B has better EU data
sovereignty), Regulatory compliance (some regulations require multiple
independent providers for systemic risk management), Resilience (if one CSP has a
major outage, other CSP continues). Security challenges: Inconsistent security
tooling and APIs across CSPs, Governance complexity (separate IAM, logging,
compliance reporting per CSP), Network complexity (inter-CSP connectivity and
latency), Cost management difficulty. Security architecture must account for the
 'lowest common denominator' — apply the strictest controls that all CSPs can
support.

SCENARIO: A healthcare organisation processes patient medical records (PHI) and provides patient-facing
appointment scheduling and billing. They face stringent HIPAA requirements but also experience 10x load spikes
during open enrollment periods. They want to reduce infrastructure costs. What deployment model and service
model combination best fits?
HOW TO THINK: Break down the requirements: (1) PHI requires HIPAA controls including BAA with any cloud provider
— public cloud is possible but requires CSP HIPAA eligibility. (2) Data sovereignty: PHI should remain within controlled
environments. (3) Variable load: 10x spikes suggest elasticity benefit. (4) Cost reduction: cloud economics. Best fit:
HYBRID CLOUD — PHI and core medical records systems in PRIVATE cloud (or HIPAA-eligible public cloud with BAA)
ensuring data residency and full control; patient-facing appointment scheduling and billing in PUBLIC cloud (cheaper,
elastic for spikes) with data classification ensuring only non-PHI flows to the public side, or with
tokenisation/pseudonymisation before public cloud storage. Service model: IaaS or PaaS for the medical records
system (need OS-level control for HIPAA audit logging), SaaS for commodity functions like email and HR.

1.4 Cloud Reference Architecture and Shared Considerations

Term / Concept Explanation / Detail
Interoperability The ability of systems, applications, or components from different sources to work
together and exchange data using standard protocols and interfaces. In cloud: the
ability to connect cloud services to other cloud services, to on-premises systems,
and to services from other CSPs. Achieved through: Open standards (REST/HTTP,
OAuth, OIDC), Standard data formats (JSON, XML, YAML), Common APIs
(OpenAPI/Swagger specifications), Container portability (OCI-compliant container
images run on any compliant runtime). Interoperability challenges: CSPs use
proprietary services that have no standard equivalent (AWS Lambda, Azure
Cognitive Services). Once your application depends on proprietary services,
portability and interoperability are constrained.
Portability The ability to move applications, workloads, and data between different cloud
providers or between cloud and on-premises without significant re-engineering
effort. Data portability: the ability to export your data in a standard, usable format
(CSV, JSON, SQL dump) without data transformation or loss. Application portability:
designing applications to avoid CSP-specific APIs and services, using containers
(Docker images are portable across OCI-compliant runtimes), using infrastructure as
code tools that support multiple CSPs (Terraform). Vendor lock-in is the enemy of
portability. Examine contracts for data portability provisions before signing — what
format is data exported in, and what is the cost of export?
Reversibility The ability to completely remove all applications, data, and configurations from a
CSP environment and return to a prior state (on-premises or another CSP).
Reversibility planning includes: export procedures, data deletion confirmation,
contract terms for data destruction after contract termination, transition timeline
(how long does the CSP give you to migrate data?), testing of export procedures
before you need them. Reversibility is particularly important when: contract terms
are unfavourable, CSP changes pricing or service terms, CSP is acquired by a
competitor, CSP experiences reliability problems. Always define the exit strategy
BEFORE signing. A provider that makes exit difficult is creating vendor lock-in by
design.
Availability The ability to access resources and services when needed. Cloud SLAs define uptime
commitments: 99.9% = 8,760 hours × 0.001 = 8.76 hours of acceptable downtime
per year. 99.95% = 4.38 hours/year. 99.99% = 52.6 minutes/year. 99.999% = 5.26
minutes/year. Critical nuance: SLA downtime windows are often measured monthly,
not annually. Review what 'downtime' means in the SLA — many CSPs exclude
'scheduled maintenance windows' from SLA calculations. Financial remedies for SLA
breach (service credits) are typically limited to a small percentage of monthly fees —
 they rarely compensate for actual business impact of outages.
Security Protection of data, applications, and infrastructure against threats. In cloud: security
must be implemented at every layer the customer controls, and the CSP must be
vetted for the layers they control. Fundamental principle: security is a shared
responsibility that shifts depending on service model. Neither CSP nor customer can
secure the environment alone. The customer's security programme must extend
into the cloud — cloud-native security tools (AWS Security Hub, Azure Defender,
GCP Security Command Centre) must be deployed alongside or instead of traditional
on-premises security tools. Key cloud security domains: Identity and Access
Management, Data Protection, Network Security, Application Security, Incident
Response, Compliance.
Privacy Protection of personal data and respect for individual privacy rights. In cloud:
privacy challenges arise because data may be stored in multiple geographic
locations, processed by multiple parties (CSP and their sub-processors), and subject
to multiple legal regimes simultaneously. Privacy considerations in cloud
architecture: Data minimisation — collect only what you need. Data residency —
specify regions/zones to enforce geographic data boundaries. Purpose limitation —
only process data for the stated purpose. Data subject rights — ensure mechanisms
exist to fulfil rights (access, deletion, portability) even for data in cloud systems.
Privacy by design — build privacy controls into system architecture from the start.
Resiliency The ability to provide and maintain acceptable service levels in the face of faults and
adverse operational conditions. Resiliency is achieved through: Redundancy
(multiple independent instances of each component), Fault tolerance (system
continues operating when individual components fail), Graceful degradation (system
provides reduced functionality rather than complete failure), Automatic failover (no
human intervention required to switch to backup capacity), Chaos engineering
(deliberately introducing failures to test resilience — popularised by Netflix's Simian
Army). In cloud: leverage multiple availability zones within a region (isolated failure
domains), multiple regions for geographic redundancy.
Performance Speed and responsiveness of cloud services. Affected by: Network latency (physical
distance between users and cloud), Compute capacity (instance type selection),
Storage I/O performance (SSD vs HDD, IOPS provisioning), Database query
performance, CDN (Content Delivery Network) for geographically distributed users.
Performance SLAs: CSPs define acceptable latency, throughput, and transaction
processing rates in SLAs. Performance must be monitored continuously and tested
under realistic load (load testing, performance testing) before and after deployment.
Governance Policies, processes, procedures, and decision frameworks for managing cloud service
usage across an organisation. Cloud governance addresses: Shadow IT prevention
(employees using unapproved cloud services without IT oversight), Cost
management (preventing cloud sprawl and runaway spending), Security policy
consistency (same security controls applied regardless of which CSP or service
model), Compliance management (all cloud usage meets regulatory requirements),
Vendor management (CSP relationships, SLA monitoring, contract management).
Governance structures: Cloud Centre of Excellence (CCoE) — cross-functional team
providing cloud standards, guidance, and oversight. Cloud governance policies must
be enforceable — use technical controls (AWS SCPs, Azure Policy, GCP Organisation
Constraints) not just document policies.
Auditability The ability to track, record, and review all activities in the cloud environment. Audit
logging requirements: all API calls (CloudTrail, Activity Log), all resource changes, all
authentication events, all data access events, all network flows (VPC Flow Logs).
Audit log integrity: logs must be protected from modification (S3 Object Lock, write-
protected log account, cryptographic log signing). Log retention: comply with
regulatory requirements — typically 1 year accessible, 7 years archived. Cloud-
specific audit challenge: the CSP's own administrative actions on your environment
are not typically visible to you in logs (CSP employees have physical access and root-
level access to infrastructure). Rely on CSP contractual commitments and third-party
 audits (SOC 2) for assurance about CSP insider actions.
Regulatory Compliance with applicable laws, regulations, and industry standards. Cloud-specific
regulatory challenges: Data sovereignty — data must reside in specific countries or
jurisdictions. Breach notification — GDPR (72 hours), HIPAA (60 days), various state
laws (faster timelines). Industry-specific regulations — HIPAA (healthcare), PCI DSS
(payments), SOX (financial reporting), NERC CIP (electrical grid), FERPA (educational
records). Cross-border data transfers — GDPR restricts transfers outside EEA.
Contractual requirements — regulated organisations must ensure cloud contracts
include appropriate provisions (BAA for HIPAA, DPA for GDPR).
SLA Definition Service Level Agreement — a contractual commitment between CSP and customer
defining quantitative performance expectations. Critical SLA elements: Uptime
percentage (with explicit definition of what constitutes 'downtime'), Measurement
period (monthly vs annual), Exclusions (scheduled maintenance, force majeure,
customer-caused issues), Financial remedies (service credits — typically 10-30% of
monthly fees, not actual damages), Support response times by severity, Escalation
procedures, Notice requirements for planned maintenance. Watch for:
'Commercially reasonable efforts' language — this is NOT an SLA, it is a best-effort
commitment with no financial accountability.

1.5 Impact of Related Technologies on Cloud Security

FEYNMAN EXPLANATION | How Emerging Technologies Multiply Cloud's Attack Surface
Cloud computing does not exist in isolation. It is the infrastructure substrate that powers an expanding array of
new technologies, each of which introduces its own security requirements and attack surface. IoT devices
connect to cloud backends via APIs — billions of resource-constrained devices that cannot run full security
software. Each device is a potential entry point. A compromised thermostat can become an attacker's foothold
into the corporate cloud environment. Machine learning pipelines run in cloud compute clusters, training on
data that may include sensitive personal information. Model files can be reverse-engineered to extract training
data. Poisoned training data can corrupt model behaviour in ways that are difficult to detect. Blockchain
promised immutability and transparency. But smart contracts are code, and code has bugs. The DAO hack in
2016 resulted in $60M stolen via a smart contract reentrancy bug — the contract was immutable on the
blockchain so the bug could not be patched. Quantum computing is 10-20 years from broad deployment but
'harvest now, decrypt later' attacks are happening TODAY. Adversaries are capturing encrypted data now,
planning to decrypt it with quantum computers when they become available. This means data encrypted today
with RSA or ECC that must remain secret for more than 10 years should already be considered at risk.

Term / Concept Explanation / Detail

Artificial Intelligence / AI/ML workloads in cloud: training (compute-intensive, batch), inference (real-time,
Machine Learning latency-sensitive), MLOps (model deployment, versioning, monitoring). Security
threats specific to AI/ML: Model Poisoning (attacker contaminates training data to
manipulate model outputs — e.g., spam filter trained to classify spam as legitimate),
Model Inversion (query the model to infer training data — can reconstruct faces
from facial recognition models), Membership Inference (determine whether specific
data was in training set — privacy violation if training data is sensitive), Adversarial
Examples (craft inputs specifically designed to cause model misclassification —
autonomous vehicle misidentifies stop sign), Model Stealing (query model
extensively to reconstruct a local copy — IP theft). Privacy: ML models trained on
personal data may retain that data in their weights — subject to GDPR 'right to
erasure' concerns. Data minimisation for ML training sets is a privacy best practice.
Internet of Things (IoT) Billions of connected devices: smart home devices, industrial sensors, medical
devices, vehicles, infrastructure. IoT security challenges in cloud context: Resource
constraints (IoT devices cannot run full OS, cannot run security agents, cannot
receive complex patches), Weak authentication (many IoT devices use default
credentials or no authentication — Mirai botnet exploited this), Infrequent patching
 (devices in the field for years without security updates), Heterogeneity (thousands
of different manufacturers, firmware versions, protocols), Massive scale (one breach
of a device type affects millions of units). Cloud IoT security architecture: API
gateways with strong authentication (X.509 certificates, mTLS) for device-to-cloud
communication, Device identity management (each device has a unique identity),
Anomaly detection (baseline normal device behaviour, alert on deviations), Network
segmentation (IoT devices on separate network segment, unable to reach sensitive
systems directly).
Containers and Kubernetes Containers provide process-level isolation (lighter than VMs). They share the host OS
kernel — a kernel vulnerability affects all containers on the host. Container security
attack surface: Image vulnerabilities (base images often contain outdated packages
with known CVEs), Misconfigured containers (privileged containers have root access
to host), Secrets in images (API keys, passwords embedded in container images),
Container escape (kernel exploit allowing process to break out of container
namespace), Lateral movement (compromised container used to attack adjacent
services). Kubernetes security: The K8s API server is a high-value target — if
compromised, attacker controls all workloads. Protect with: RBAC (role-based access
control for K8s API), Network policies (whitelist pod-to-pod communication), Pod
Security Standards (prevent privileged pods), Admission controllers
(OPA/Gatekeeper for policy enforcement), etcd encryption (K8s configuration
database contains secrets), Image signing and verification (Cosign, Notary v2).
Serverless / FaaS Event-driven execution: Lambda function runs for milliseconds. Security
implications: Cold start security gap (function starts fresh — security tooling may not
be fully initialised), Dependency injection (attacker controls event data that triggers
function — injection attacks against function code), Over-permissive IAM (each
function should have only the permissions it needs for its specific task — never give
functions admin permissions), Secret management (environment variables visible in
Lambda console — use Secrets Manager instead), Third-party library risk (function
dependencies may contain malicious code — SCA is critical), Vendor-specific
(moving from AWS Lambda to Azure Functions is not trivial). Attack patterns: Event
injection, function-level privilege escalation, denial-of-wallet (cause enormous billing
by triggering excessive function invocations), data exfiltration via function egress.
Blockchain Distributed immutable ledger. Smart contracts: self-executing code deployed on the
blockchain. Cloud use of blockchain: Identity management (self-sovereign identity —
users control their own identity without relying on a central IdP), Supply chain
provenance (track goods from origin to consumer — unalterable audit trail), Smart
contracts for automated agreements. Security risks: 51% attack (if an attacker
controls >50% of network hashrate, they can rewrite recent transaction history —
practical for smaller blockchains), Smart contract bugs (reentrancy, integer overflow
— code is immutable after deployment so bugs cannot be patched), Private key loss
(lose the private key, lose access to all associated assets — permanent), Oracle
problem (smart contracts cannot access external data securely — 'oracles' that feed
data to contracts are centralised trust points). Exam focus: blockchain is NOT a silver
bullet — it has specific use cases and specific limitations. Not all 'distributed data'
problems benefit from blockchain overhead.
Quantum Computing Quantum computers use quantum mechanical phenomena (superposition,
entanglement) to perform certain calculations exponentially faster than classical
computers. Cryptographic threat: Shor's algorithm (quantum) can efficiently factor
large integers — breaks RSA, Diffie-Hellman, and ECC (all based on computational
hardness of factoring). Grover's algorithm (quantum) reduces symmetric key
effective key length by half — AES-256 effective becomes AES-128. Post-Quantum
Cryptography (PQC): NIST standardised algorithms in 2024: ML-KEM (CRYSTALS-
Kyber) for key encapsulation, ML-DSA (CRYSTALS-Dilithium) for digital signatures,
SLH-DSA (SPHINCS+) as backup. 'Harvest now, decrypt later' (HNDL) attacks:
adversaries are capturing encrypted internet traffic today, planning to decrypt when
quantum computers are available. Data with >10 year secrecy requirements should
consider transitioning to PQC NOW. TLS 1.3 with PQC hybrid key exchange is
 emerging as the forward-looking standard.
Edge Computing Processing data close to where it is generated — factory floor, retail store, vehicle,
hospital bedside. Reduces latency and bandwidth usage. Security challenges:
Physical exposure (edge devices in accessible locations — airports, factories, remote
installations), Inconsistent patch management (diverse device ecosystem, field
deployment makes patching difficult), Limited monitoring visibility (security tools
designed for data centres may not run on resource-constrained edge devices),
Complex trust model (edge is 'trusted' infrastructure but physically exposed), Data
leakage risk (sensitive data processed at edge may be stored locally before
transmission). Edge security architecture: Zero Trust applied to edge (do not trust
edge devices implicitly even though they are 'our' devices), Attestation (verify device
integrity before trusting its data — TPM-based measurement), Minimal attack
surface (edge devices run only required software), Encrypted communications (TLS
for all edge-to-cloud communication, mTLS for high-security edge environments).
Confidential Computing Protects data IN USE through hardware-based Trusted Execution Environments
(TEEs). Addresses the limitation that traditional security protects data at rest and in
transit but leaves data exposed in plaintext in memory during processing.
Technologies: Intel Trust Domain Extensions (TDX), AMD Secure Encrypted
Virtualisation (SEV), ARM TrustZone, IBM Secure Execution. Use cases: Machine
learning on sensitive data (train on medical data without the CSP seeing the data),
Multi-party computation (combine sensitive datasets from multiple organisations
without any party seeing the others' raw data), Blockchain confidential transactions,
Remote attestation (prove to a remote party that computation occurred in a trusted
environment). CCSP exam note: Confidential Computing is an emerging technology
mentioned in the CCSP body of knowledge as an important trend — understand the
concept and use cases.
DevSecOps Integration of security into every phase of the DevOps CI/CD pipeline. The 'security
as code' model. DevSecOps tools by pipeline phase: Commit (pre-commit hooks run
SAST, secrets scanning — detect hardcoded API keys before they reach the
repository), Build (SAST scanning of compiled code, SCA scanning of dependencies
for CVEs, container image scanning), Test (DAST against deployed staging
environment, automated security test cases, compliance checks), Stage (manual pen
testing, security review for major features), Deploy (IaC security scanning — tfsec,
Checkov, cfn-nag — ensure infrastructure template is secure before deploying),
Production (DAST in prod, runtime security monitoring, CSPM for cloud posture).
Organisational model: Security engineers are 'embedded' in development teams,
not a separate gate at the end. Security responsibilities are defined as code (policy
as code, compliance as code). Security failures block deployment — the pipeline is
the enforcement mechanism.

1.6 Cryptography and Key Management in Cloud

FEYNMAN EXPLANATION | The Three States of Data and Their Defences
Data exists in three states: at rest, in transit, and in use. Historically, security focused on the first two.
Confidential computing is beginning to address the third. Data at Rest: Sitting on disk — a database server, an S3
bucket, a backup tape. Protected by encryption: AES-256 encrypts the data before it is written to storage. The
key must be stored separately from the encrypted data — storing the key in the same database as the
encrypted data is like hiding a door key under the mat. Data in Transit: Moving across a network — from client
browser to web server, from application server to database, from on-premises to cloud. Protected by TLS
(Transport Layer Security): TLS 1.3 is the current standard. It provides confidentiality (encryption), integrity
(MAC — message authentication code that detects tampering), and authentication (certificates verify the
server's identity). Data in Use: Being actively processed in CPU registers and RAM. This is the hardest state to
protect. While a computation is happening, the data exists in plaintext in memory. An attacker with access to
the host (a malicious CSP insider, or an attacker who has escaped a VM) can read memory. Confidential
Computing uses hardware-based TEEs to create an encrypted memory region that even the CSP cannot read.
Key management is the hardest part. The algorithm (AES-256, TLS 1.3) is the easy part — these are
mathematically sound and publicly known. The key is the secret. A leaked key = compromised data. A lost key =
permanently lost data. The HSM (Hardware Security Module) exists specifically to solve the key management
problem: keys are generated inside the HSM and never exported in plaintext.

Term / Concept Explanation / Detail

AES (Advanced Encryption Symmetric block cipher specified in FIPS 197. Current standard for data-at-rest
Standard) encryption. Key sizes: AES-128 (128-bit key — NSA-approved for SECRET-level
classified information per CNSSP-15), AES-192, AES-256 (256-bit key — NSA-
approved for TOP SECRET-level classified information; the only publicly available
cipher approved for TOP SECRET by NSA). Mode of operation matters: ECB
(Electronic Codebook) is insecure — same plaintext block always produces same
ciphertext block, revealing patterns. CBC, CTR, GCM are secure modes. AES-GCM
(Galois/Counter Mode) is preferred — provides both encryption AND authentication
(AEAD: Authenticated Encryption with Associated Data). Cloud storage encryption:
All major CSPs use AES-256-GCM for default encryption at rest. Under NSA's CNSA
2.0 (2022), AES-256 is mandated across all classification levels to provide a security
margin against future quantum computing attacks via Grover's algorithm.
TLS (Transport Layer Security) Successor to SSL. Provides: Confidentiality (symmetric encryption, negotiated during
handshake), Integrity (HMAC — detects packet tampering), Authentication (server
presents X.509 certificate — client verifies chain of trust). Versions: SSL 2.0/3.0
(deprecated — broken), TLS 1.0/1.1 (deprecated — BEAST, POODLE attacks), TLS 1.2
(acceptable — widely deployed), TLS 1.3 (current standard — eliminated legacy
cipher suites, 0-RTT option, faster handshake). PCI DSS 4.0.1 requires TLS 1.2
minimum; TLS 1.3 strongly recommended. Exam: never allow TLS 1.0 or 1.1 for
sensitive systems.
RSA (Rivest-Shamir-Adleman) Asymmetric (public-key) cryptographic algorithm. Based on the mathematical
difficulty of factoring the product of two large primes. Key sizes: RSA-2048
(minimum acceptable), RSA-4096 (recommended for long-term security). Uses:
Digital signatures, key encapsulation (encrypting a symmetric key using recipient's
public key). Performance: RSA is ~1000x slower than AES — use RSA to encrypt only
small amounts of data (typically a symmetric session key), then use AES for bulk
data. Quantum vulnerability: Shor's algorithm on a sufficiently powerful quantum
computer could factor RSA keys efficiently — motivating the move to post-quantum
cryptography.
ECC (Elliptic Curve Asymmetric algorithm based on algebraic structure of elliptic curves. Provides
Cryptography) equivalent security to RSA with much smaller key sizes: ECC-256 ≈ RSA-3072 in
security strength. Advantages: Smaller keys, faster operations, lower power
consumption (important for IoT). ECDSA (Elliptic Curve Digital Signature Algorithm)
widely used for TLS certificates. ECDH (Elliptic Curve Diffie-Hellman) for key
exchange in TLS handshake. Quantum vulnerability: Also vulnerable to Shor's
algorithm.
PKI (Public Key Infrastructure) Framework for managing digital certificates and public-private key pairs.
Components: Root CA (Certificate Authority): The ultimate trust anchor. Signs
Intermediate CA certificates. Root CA private key is kept offline and physically
secured — if compromised, the entire PKI is compromised. Intermediate CA:
Operationally issues end-entity certificates. Root CA signs Intermediate CA;
Intermediate CA signs end-entity certs. Using intermediates protects the Root CA.
End-Entity Certificate: The certificate for a specific server, user, or application.
Contains the public key and identifying information, signed by an Intermediate CA.
RA (Registration Authority): Verifies identity of certificate requestors before
certificate issuance. CRL (Certificate Revocation List): A periodically published list of
certificates that have been revoked before their expiry. CRL checking can fail 'open'
(accept cert if CRL unavailable) — security risk. OCSP (Online Certificate Status
Protocol): Real-time certificate revocation checking via HTTP. OCSP stapling: Server
includes signed OCSP response in TLS handshake, eliminating client OCSP round-trip.
HSM (Hardware Security Tamper-resistant, tamper-evident, tamper-responsive dedicated hardware device
Module) for cryptographic key generation, storage, and operations. Architectural principle:
cryptographic keys are GENERATED INSIDE the HSM and NEVER EXPORTED IN
PLAINTEXT. The key only ever exists within the secure boundary of the HSM.
Operations: Generate random keys (using hardware random number generator),
Perform cryptographic operations (encrypt, decrypt, sign, verify) on data passed in,
Wrap (encrypt) keys for storage or transport, Unwrap (decrypt) keys for use. FIPS
140 levels (apply to both FIPS 140-2 and FIPS 140-3): Level 1 (basic security
requirements — software may implement), Level 2 (tamper-evident physical
security — must show evidence of tampering, identity-based operator
authentication), Level 3 (tamper-resistant — physical security mechanism prevents
access to CSPs, zeroises keys if tampered), Level 4 (tamper-responsive — zeroises
keys in response to environmental attacks including temperature, voltage,
radiation). IMPORTANT TRANSITION: FIPS 140-3 superseded FIPS 140-2 on
September 22, 2019. CMVP stopped accepting new FIPS 140-2 submissions in 2022.
All existing FIPS 140-2 certificates will be moved to the CMVP Historical List on
September 21, 2026. For new federal procurements after that date, only FIPS 140-3
validated modules will satisfy compliance requirements. Cloud HSMs: AWS
CloudHSM (dedicated single-tenant HSM hardware in AWS), Azure Dedicated HSM
(Thales Luna Network HSM 7 in Azure), GCP Cloud HSM. Use cases: Root CA private
keys, code signing keys, payment HSM (ANSI X9.24 compliant), encryption key roots
of trust.
Key Hierarchy and Key Hierarchy: Root Master Key (RMK) → Customer Master Key (CMK) → Data
Management Encryption Keys (DEKs). Data Encryption Key (DEK): Encrypts actual data. Changes
frequently. Generated by KMS or application. Customer Master Key (CMK): Encrypts
(wraps) the DEK. Stored in KMS. Customer controls access. Root Master Key: Stored
in HSM. Never leaves HSM. Wraps CMKs. Why hierarchy? If a DEK is compromised,
only data encrypted with that specific DEK is exposed — not all data. The CMK limits
blast radius. Key wrapping: Encrypting one key with another key for secure transport
or storage. The encrypted (wrapped) DEK is stored alongside the data. To decrypt
data: (1) Authenticate to KMS → (2) KMS unwraps DEK using CMK → (3) Application
uses DEK to decrypt data → (4) DEK discarded after use. At no point is the CMK
visible to the application.
Key Rotation The process of regularly replacing cryptographic keys. Benefits: Limits the blast
radius of a key compromise (data encrypted with old key remains secure even if new
key is compromised), Reduces the window of exposure for a compromised key,
Required by some compliance frameworks (PCI DSS requires annual key rotation).
Implementation: Generate new key → Re-encrypt (re-wrap) existing encrypted data
with new key → Retire old key (keep in disabled state to decrypt legacy data).
Automated rotation: AWS KMS and Azure Key Vault support automatic key rotation
— the CMK material is rotated but the CMK ID remains the same, so applications
need no changes.
BYOK vs HYOK vs CSP- CSP-Managed Keys (Server-Side Encryption with CSP Keys — SSE-S3/SSE-AWS): CSP
Managed Keys generates and manages all keys. Simplest for customer. CSP has full access to
plaintext data and to keys. Appropriate for non-sensitive data. BYOK (Bring Your
Own Key): Customer generates key material outside the CSP (in a customer-
controlled HSM or KMS) and imports the key into the CSP's KMS. Customer controls
key generation and initial key material. CSP stores the key in their KMS and performs
encryption/decryption operations — CSP technically has access to the key during
operations. HYOK (Hold Your Own Key / Customer-Managed Key with External Key
Manager): Key NEVER leaves the customer's premises. Customer operates an
external key management server (Thales CipherTrust, Fortanix, etc.). CSP calls out to
customer's key manager to get a key wrapping permission before each
encryption/decryption operation. Highest security — CSP CANNOT decrypt customer
data without the customer's real-time cooperation. Trade-off: If the customer's key
manager is unavailable, cloud data is inaccessible. Latency impact.
1.7 Data and Media Sanitisation
Term / Concept Explanation / Detail
Overwriting (Clearing) Writing patterns of data over every storage location to render original data
unrecoverable. Standards: DoD 5220.22-M (3 passes: zeros, ones, random),
Gutmann method (35 passes). Effectiveness: Reliable for HDDs (spinning disk).
Unreliable for SSDs (solid state drives) — SSDs use wear-levelling algorithms that
write to different physical locations than the logical location you are overwriting.
Data may persist in unmapped blocks. Also unreliable for flash storage, hybrid
drives. Cloud applicability: CANNOT be performed by the customer in public cloud —
you do not control the physical storage device. The CSP performs overwriting when
decommissioning hardware, but you cannot verify this independently.
Cryptographic Erasure Destroy the encryption key, making all data encrypted with that key permanently
(Crypto-Shredding) and mathematically unreadable — even if the raw ciphertext remains on storage
media. Process: All data is encrypted with a dedicated key → Destroy the key (delete
all copies, including all backups of the key) → Data is now irreversibly rendered
unreadable. Requirements: Data MUST have been encrypted before this method
works. The key must be truly deleted — not just marked as deleted in software, but
actually overwritten in the HSM. Advantages: Works regardless of storage medium
(HDD, SSD, tape, distributed cloud storage), Works even when you cannot access the
physical media, Instantaneous (deleting a key takes milliseconds — effective
immediately), Verifiable (can demonstrate that the key no longer exists by
attempting a decryption operation, which should fail). The ONLY reliable sanitisation
method in cloud environments where you do not own the hardware.
Degaussing Exposing magnetic storage media to a strong alternating magnetic field that
randomises the magnetic domains, destroying recorded data. Effective for: Spinning
HDDs (magnetic), Magnetic tape. Completely ineffective for: SSDs, Flash memory,
Optical media (CDs, DVDs), Non-magnetic media. Cloud applicability: ZERO — cloud
customers cannot degauss CSP hardware. The CSP handles media disposal at end-of-
life. The customer has no visibility into this process. For assurance, look for CSP
certifications and policies for media destruction (e.g., NIST 800-88 compliance
certification, ISO 21964 media sanitisation certification).
Physical Destruction Physically destroying the storage medium so data cannot be recovered. Methods:
Shredding (paper shredder for media — industrial shredders for HDDs),
Disintegration (reducing to fine particles), Incineration, Drilling/Punching (defeating
specific platters), Crushing/Bending (renders device inoperable — may not destroy
all data on SSDs). Verification: Certificate of Destruction from a NAID AAA Certified
data destruction provider. Cloud applicability: ZERO for cloud customers — you
cannot physically destroy CSP hardware. Relevant for on-premises hardware at end
of life.
Cloud Sanitisation Best Given that physical methods are unavailable in cloud, the correct architecture is to
Practices ENCRYPT ALL DATA from the moment it enters cloud storage. If data is always
encrypted with customer-controlled keys (BYOK or HYOK), then cryptographic
erasure of the key effectively sanitises all data without any physical media access.
Additionally: Request contractual commitments from CSP about media sanitisation
procedures at end of life. Review CSP certifications for media destruction (look for
NIST 800-88 compliance in CSP documentation). Understand data residency — if
your data is spread across regions, deletion must be confirmed in all regions.

1.8 Virtualisation and Cloud Infrastructure Security

Term / Concept Explanation / Detail
Type 1 Hypervisor Type 1 (Bare Metal) hypervisors run directly on the physical hardware with no
Architecture underlying OS layer. The hypervisor IS the first software to run on the hardware.
Architecture: Hardware → Type 1 Hypervisor → Virtual Machines (each with their
 own OS). Examples: VMware ESXi, Microsoft Hyper-V (in bare-metal mode), KVM
(Kernel-based Virtual Machine — embedded in Linux kernel), Xen (used by AWS
Nitro is a Xen successor). Advantages: Smaller attack surface (no host OS to
compromise), Better performance (no OS layer overhead), Better isolation between
VMs. Used in: All major cloud providers, enterprise data centres. AWS Nitro System
is Amazon's custom Type 1 hypervisor architecture — designed to offload
virtualisation functions to dedicated Nitro cards (security processing, storage,
networking), making the hypervisor itself extremely thin and reducing the attack
surface dramatically.
Type 2 Hypervisor Type 2 (Hosted) hypervisors run as applications within an existing host operating
Architecture system. Architecture: Hardware → Host OS → Type 2 Hypervisor application →
Virtual Machines. Examples: VMware Workstation/Fusion, Oracle VirtualBox,
Parallels Desktop. The Host OS vulnerability is a shared risk for all VMs — a kernel
exploit in the host OS can compromise all VMs regardless of hypervisor isolation.
Used for: Desktop virtualisation, development environments, testing. NOT used in
production cloud data centres. Security implication: The host OS represents
additional attack surface that does not exist in Type 1 architectures.
VM Escape — The Critical VM escape is the attack category where code executing inside a virtual machine (a
Multi-Tenancy Threat tenant's workload) exploits a vulnerability in the hypervisor to gain execution
context OUTSIDE the VM — either in the hypervisor itself, in the host OS (for Type
2), or in another VM. Impact: Total isolation violation. An attacker who escapes their
VM can access: the hypervisor's memory (may contain other tenants' data), other
VMs' memory (cross-tenant data leakage), the host OS (full system compromise),
network infrastructure (pivoting to other physical hosts). Historical examples: CVE-
2018-3646 (L1TF — L1 Terminal Fault, Intel side-channel), CVE-2019-18420 (Xen VM
escape), CVE-2021-22543 (KVM VM escape). Mitigations: Apply hypervisor patches
IMMEDIATELY (critical severity, highest priority), Hardware isolation features (Intel
VT-d/IOMMU — prevents DMA attacks from VMs to host memory), Hardware
memory encryption (Intel TME, AMD SME — encrypts all memory, so even if one
VM reads another's memory pages, the data is ciphertext), Micro-architecture
mitigations (Spectre/Meltdown kernel patches — KPTI, Retpoline), Monitoring for
anomalous behaviour (unexpected process creation at hypervisor level, unexpected
network connections from VMs).
Container Isolation vs VM Containers and VMs provide different levels of isolation: VM Isolation: Each VM has
Isolation its own kernel, its own memory space, its own network stack. The hypervisor
enforces a hard boundary. Cross-VM communication requires network traffic that
traverses hypervisor-managed virtual switches. Container Isolation: Containers
share the HOST OS KERNEL. They are isolated using Linux kernel features:
namespaces (PID, mount, network, IPC namespaces give each container its own
view of system resources), cgroups (limits CPU, memory, I/O consumption per
container), seccomp (filters system calls — reduces kernel attack surface). Container
escape requires a kernel vulnerability or misconfiguration (e.g., privileged container,
dangerous capability, or mounted Docker socket). Container security tools: Falco
(runtime security monitoring for containers), gVisor (Google's container sandbox —
inserts a user-space kernel proxy between container and host kernel, reducing host
kernel exposure), Kata Containers (lightweight VMs as container runtime —
combines container interfaces with VM-level isolation).
Ephemeral Computing Ephemeral computing: resources exist only for the duration of a task and are
Security destroyed afterwards. Examples: AWS Lambda functions (milliseconds),
spot/preemptible instances (hours), containers in a Kubernetes pod (minutes to
hours). Security implications: Forensics challenge — evidence disappears when the
ephemeral instance is destroyed. Solution: ensure all logs are shipped to persistent
storage BEFORE the instance terminates (CloudWatch Logs, Splunk, Elasticsearch).
Patch management irrelevance — ephemeral instances are often launched from
golden AMIs and destroyed before patches are needed. Instead, update the base
image and redeploy. Immutable infrastructure: never patch running instances;
instead, update the image and replace instances. State management: stateless
 services work well with ephemeral compute; stateful services require careful
handling of persistent data (database, object storage, caches outside the ephemeral
boundary).
Snapshot and Image Security VM snapshots capture the state of a VM at a specific point in time, including disk
and (optionally) memory. Security risks: Secrets in snapshots — API keys, passwords,
certificates that existed in the running environment are captured in the snapshot.
Stale patches — snapshot of a VM taken before a critical patch was applied contains
the unpatched vulnerability. Snapshot propagation — sharing a snapshot with
another account or making it public shares all data including secrets. Best practices:
Encrypt all snapshots with CMKs (not default CSP-managed keys), Audit snapshot
sharing permissions regularly (no public snapshots for sensitive workloads), Scan
snapshots/AMIs for known vulnerabilities before deployment (AWS Inspector can
scan AMIs), Rotate secrets after creating snapshots, Do not share development
snapshots (may contain test credentials).

1.9 Secure Cloud Design Principles and Patterns

Term / Concept Explanation / Detail
Cloud Secure Data Lifecycle — CREATE: Data is first generated or acquired. Security controls: Classify data at point
6 Phases in Detail of creation (this is the most important moment — once data is classified, controls
can be applied automatically). Assign data owner. Apply classification label.
Determine what personal data is collected (minimise to what is necessary). STORE:
Data is written to persistent storage. Security controls: Encryption at rest (AES-256).
Access controls (who can read/write/delete). Appropriate storage tier for
classification (restricted data should not go to lowest-cost unencrypted archive).
Backup and replication policy. USE: Data is accessed and processed. Security
controls: Encryption in use (confidential computing where feasible).
Masking/tokenisation to limit exposure in application layer (show only last 4 digits of
card). Role-based access — only users/processes that need the data for their role
get access. Logging of all access events. SHARE: Data is transmitted to other parties
(internal or external). Security controls: Encryption in transit (TLS 1.3). IRM controls
— rights travel with the data to external recipients. DLP at egress — detect and
block unauthorised sharing. Approval workflow for sharing restricted data
externally. Data sharing agreements for external recipients. ARCHIVE: Data is moved
to long-term cold storage. Security controls: Encryption maintained (do not decrypt
for archiving). Key management — archive keys must be preserved for the life of the
archive (if you lose the archive key, archived data is permanently unreadable).
Retention schedule documented. Retrieval procedure tested. DESTROY: Data
reaches end of retention period or is no longer needed. Security controls: Check for
legal holds (a legal hold overrides any destruction policy). Verify retention period
has been met. Cryptographic erasure (cloud) or physical destruction (on-premises).
Document destruction with timestamp. Certificate of destruction if required by
compliance.
Zero Trust Architecture (NIST Principle: Never trust, always verify. No implicit trust based on network location, IP
SP 800-207) address range, or previous authentication. Core tenets from NIST: All resources are
accessed securely regardless of network location (no distinction between 'inside'
and 'outside' the perimeter — even internal network is treated as hostile). Access is
granted on a per-session basis (do not grant long-lived access — authenticate and
authorise each request or session). Access to resources is determined by dynamic
policy, including client identity, application/service, device state (is it patched? does
it have endpoint security?), and other behavioural and environmental attributes. All
assets and resource owners assume compromise — design systems to detect and
respond to compromise, not just prevent it. Implementation components: IdP
(identity provider) for strong authentication, PEP (Policy Enforcement Point)
between every user/device and resource, PA (Policy Administrator) evaluating
access decisions in real time, Comprehensive logging of all access decisions and
activities, Microsegmentation of networks (eliminate flat networks where
 compromise of one host enables lateral movement to all others).
NIST Cloud Security NIST SP 800-144 (Guidelines on Security and Privacy in Public Cloud Computing):
Guidelines Framework for organisations deciding on cloud adoption and for managing cloud
security. Key topics: Governance, compliance, trust, architecture, identity, data,
software, and operations. NIST SP 800-146 (Cloud Computing Synopsis and
Recommendations): Practical guidance for planning cloud adoption decisions. NIST
SP 800-190 (Container Security Guide): Specific guidance for securing containerised
applications — image security, registry security, orchestration security. NIST SP 800-
204 (Microservices Security): Security strategies for microservices architectures.
NIST CSF (Cybersecurity Framework): Five functions — Identify, Protect, Detect,
Respond, Recover — applicable in cloud as in traditional environments.
Defence in Depth for Cloud Layered security: no single control relied upon exclusively. If one layer fails, others
compensate. Cloud defence-in-depth example for a web application: Layer 1: CDN
with DDoS protection (Cloudflare, AWS Shield) — absorbs volumetric attacks. Layer
2: WAF (Web Application Firewall) — filters OWASP Top 10 attacks before reaching
application. Layer 3: API Gateway — authentication, authorisation, rate limiting,
request validation. Layer 4: Application code security — input validation,
parameterised queries, output encoding. Layer 5: Container/OS hardening —
minimal base image, read-only filesystem, non-root process. Layer 6: Network
security groups — only required ports open from only required sources. Layer 7:
IAM — least privilege, MFA, short-lived credentials. Layer 8: Encryption at rest — all
data encrypted with customer-managed keys. Layer 9: Logging and monitoring —
SIEM with anomaly detection, alerting. Layer 10: Incident response — prepared,
tested, practiced plan for responding to security events. An attacker must defeat ALL
layers sequentially — increasing cost and likelihood of detection.
Immutable Infrastructure Principle: servers and infrastructure are NEVER modified after deployment. Instead
of patching a running server, you update the image it was built from and replace the
old server with a new one. Benefits: Eliminates configuration drift (servers stay in
the known secure state they were built to), Eliminates patch management on
running systems (patches are in the new image), Enables consistent, repeatable
deployments (same IaC template always produces the same infrastructure),
Simplifies forensics (if a server is compromised, the state before compromise is
exactly known — it is the image it was built from), Enables rapid recovery (destroy
compromised server, launch new one from verified image). Implementation: Golden
AMI/container image pipeline: Source code → Build → Security scan (SAST, SCA,
container scan) → Bake AMI → Test → Approved AMI used for all deployments.
Blue/green deployments: new 'green' environment deployed alongside old 'blue';
traffic switches; old 'blue' environment destroyed.

1.10 Business Continuity and Disaster Recovery Design in Cloud

FEYNMAN EXPLANATION | BC vs DR vs Resilience — Three Interrelated but Distinct Concepts
Business Continuity (BC): Maintaining critical BUSINESS OPERATIONS during a disruption event. BC is about
keeping the business alive even when IT systems are disrupted. A manual workaround (processing orders by
phone and pen and paper) is a BC measure even if it involves no technology. Disaster Recovery (DR): Restoring
IT SYSTEMS to normal operation AFTER a disruptive event. DR is about getting technology back to its normal
state. DR planning covers: data recovery from backups, system rebuild procedures, application restart
sequences, testing procedures. Resilience: The broader capability to withstand disruption and recover.
Resilience includes BC and DR as components but also includes proactive measures: redundancy, fault
tolerance, chaos engineering (deliberately introducing failures to test and improve resilience), architecture
designed to 'fail gracefully'. In cloud: BC/DR architectures that would require enormous investment on-premises
(hot standby site in another city) become economically accessible. A second-region deployment in AWS costs
exactly the compute and storage consumed — no second data centre lease. But 'we are in the cloud so we are
resilient' is a dangerous misconception — a single-region, single-AZ deployment in AWS is still a single point of
failure. BIA (Business Impact Analysis): The foundation of BC/DR planning. Systematically analyses the impact of
disruption to each business function. Outputs: (1) Critical function list ranked by priority, (2) Maximum Tolerable
Downtime (MTD) for each function, (3) Recovery Time Objective (RTO) derived from MTD, (4) Recovery Point
Objective (RPO) — maximum acceptable data loss, (5) Recovery Service Level (RSL) — minimum capacity needed
during recovery.

Term / Concept Explanation / Detail

MTD / MAD (Maximum The absolute ceiling — the maximum time a business function can be unavailable
Tolerable Downtime / before the organisation suffers irreversible damage: regulatory non-compliance,
Maximum Allowable unrecoverable customer loss, financial crisis, or organisational failure. MTD is
Downtime) determined by business leaders (CEO, CFO, Board) with input from operational
subject matter experts. Security architects use MTD to set the requirements for the
recovery architecture — RTO must be shorter than MTD. If MTD for payment
processing is 4 hours, RTO must be less than 4 hours. Example MTDs: Payment
processing: 4 hours. Patient monitoring systems: minutes to zero. Order entry: 24-
48 hours. HR payroll processing: 72 hours.
RTO (Recovery Time The target time within which a specific IT system or business function must be
Objective) restored after a disruption. RTO must be shorter than MTD (the RTO includes
recovery time AND the time to discover the problem — leave buffer before hitting
MTD). RTO drives architecture decisions: RTO of minutes → Hot site (active-active,
continuous replication), RTO of hours → Warm site (pre-provisioned infrastructure,
data replicated), RTO of days → Cold site (empty facility, restore from backup).
Cloud implementation: Multi-AZ deployment can achieve near-zero RTO for AZ
failures. Multi-region active-passive achieves RTO of minutes to hours depending on
automation. Active-active multi-region achieves near-zero RTO.
RPO (Recovery Point The maximum acceptable amount of data loss measured in time. 'RPO of 1 hour'
Objective) means: in the event of a disaster, we can accept losing up to 1 hour of transactions
— any data created in the last hour before the disaster may not be recoverable. RPO
drives backup and replication frequency: RPO of zero → Synchronous replication
(every write committed at both primary and secondary before acknowledging to
client — highest cost, performance impact, geographic limitation). RPO of minutes
→ Asynchronous replication (continuous replication with small lag). RPO of hours →
Point-in-time backups every hour. RPO of 24 hours → Daily backups. Cloud
implementation: AWS RDS Multi-AZ provides synchronous replication (RPO ≈ zero).
S3 Cross-Region Replication provides asynchronous replication (RPO of minutes).
AWS Backup provides scheduled backups.
RSL (Recovery Service Level) The minimum percentage of normal service capacity that must be available during a
recovery period for the organisation to minimally function. RSL of 60% means:
during DR operation, we need 60% of normal capacity to keep the business running
at an acceptable level. RSL allows for phased recovery rather than all-or-nothing: in
the first hour after a disaster, prioritise recovering the most critical 20% of functions.
Expand to 60% RSL within RTO. Full recovery is a separate, longer-term effort. RSL is
often not specified in BC/DR plans — many organisations focus only on RTO and
RPO. Adding RSL makes recovery planning more realistic.
BC/DR Testing — Types and Testing is non-negotiable — an untested plan is not a plan. Testing types from least
Requirements to most impactful: Tabletop Exercise (discussion-based: 'what would we do if X
happened?' — no systems involved, lowest risk, good for identifying plan gaps and
training staff), Walkthrough Drill (follow plan steps in simulation without activating
actual DR systems — step-through of runbooks), Functional Exercise (test specific
components of the plan — e.g., test the database failover procedure without taking
down production), Parallel Test (activate DR systems in parallel with production —
verify DR systems work without disrupting production — most common
comprehensive test type), Full Interruption Test / Failover Test (actually cut over to
DR site — production is taken offline — highest risk, most realistic, required annually
for critical systems by some regulatory frameworks — PCI DSS, HIPAA Business
Associate Agreements). After every test: document gaps found, update the plan,
assign remediation owners, retest the remediated gaps.
 Cloud BC/DR Architecture Active-Active (Multi-Region): Traffic distributed across multiple regions
Patterns simultaneously. Both regions handle production traffic. No 'failover' — a region
failure causes traffic to route exclusively to the remaining region. RTO: near-zero
(seconds). RPO: near-zero (synchronous or near-synchronous replication). Cost: 2x
or more (full production capacity in two regions). Suitable for: Mission-critical
applications where any downtime is unacceptable. Warm Standby (Active-Passive):
Primary region handles all traffic. Secondary region runs a scaled-down version of
production infrastructure (smaller instances, fewer nodes). If primary fails: scale up
secondary and redirect traffic. RTO: minutes to hours (depending on automation).
RPO: depends on replication configuration. Cost: ~30-50% of full active-active. Pilot
Light: Minimal core infrastructure always running in DR region (databases
replicated, AMIs available, IaC templates ready). Application tier is not running. If
primary fails: launch application tier from IaC, point DNS at DR region. RTO: hours.
RPO: depends on replication. Cost: minimal (just DR database and storage). Backup
and Restore: No infrastructure in DR region. All data in S3/backup storage. If primary
fails: provision infrastructure from IaC, restore data from backup. RTO: hours to
days. RPO: depends on backup frequency. Cost: minimal (just storage). Suitable for:
Non-critical applications with high RTO tolerance.

1.11 Cloud Service Provider Evaluation and Assurance

FEYNMAN EXPLANATION | How to Assess a CSP When You Cannot Inspect Their Data Centre
You cannot walk into AWS's or Azure's data centre and independently verify their security controls. You must
rely on evidence produced by trusted third parties who CAN access those facilities and systems. Third-party
assurance is the mechanism: independent auditors (KPMG, Deloitte, EY, PwC, specialised security audit firms)
are granted access to CSP facilities and systems under strict confidentiality agreements. They audit controls
against recognised standards (AICPA Trust Services Criteria for SOC 2, ISO 27001 requirements) and produce
reports that CSPs share with their customers under NDA. CSP due diligence checklist: (1) Review their most
recent SOC 2 Type II report — the most meaningful assurance document. Focus on: the opinion paragraph
(clean, qualified, or adverse), the description of the control environment, the test results (exceptions found?),
and the complementary user entity controls (what YOU must do). (2) Review ISO 27001 certificate — is it
current? Which scope? (3) Check CSA STAR registry for the CSP's CAIQ submission (self-assessment) or STAR
certification. (4) Review their incident history — how did they communicate? How quickly? Were postmortem
RCAs published? (5) Review their SLA terms carefully — what is actually guaranteed? (6) Assess financial stability
— can they sustain operations long-term? Complementary User Entity Controls (CUECs): A critical section of the
SOC 2 report. CUECs describe the controls that the CUSTOMER must implement for the overall system of
controls to function as intended. Example: 'The CSP controls physical access to servers. The CUSTOMER is
responsible for managing user account creation and deletion.' The auditor will check that YOU have
implemented the CUECs when auditing your use of the CSP. Review CUECs carefully and confirm you have
implemented each one.

Term / Concept Explanation / Detail

ISO/IEC 27001:2022 International standard for Information Security Management Systems (ISMS).
Certification by accredited Conformity Assessment Bodies (CABs — like BSI, Bureau
Veritas, KPMG, SGS). Audit process: Stage 1 audit (document review — does the
ISMS documentation meet requirements?), Stage 2 audit (on-site audit — are the
ISMS controls actually implemented?). Annual surveillance audits (visit to confirm
continued compliance). 3-year recertification cycle (full re-audit every 3 years).
Annex A (2022 edition): 93 controls organised into 4 themes: Organisational controls
(37), People controls (8), Physical controls (14), Technological controls (34). New
2022 controls include: Threat intelligence, ICT readiness for business continuity,
Physical security monitoring, Configuration management, Information deletion, Data
masking, Data leakage prevention, Monitoring activities, Web filtering, Secure
coding. ISO 27001 alone does not prove any SPECIFIC level of security — it certifies
that the organisation has a MANAGED APPROACH to information security. The scope
 matters enormously — a certificate covering only the Sydney office provides no
assurance about the Singapore office.
ISO/IEC 27017:2015 Guidelines for cloud-specific security controls, as an extension of ISO 27001/27002.
Addresses 7 cloud-specific controls not in ISO 27002: CLD.6.3.1 (Shared roles and
responsibilities within a cloud computing environment), CLD.8.1.5 (Removal and
return of assets), CLD.9.5.1 (Segregation in virtual computing environments),
CLD.9.5.2 (Virtual machine hardening), CLD.12.1.5 (Administrator's operational
security), CLD.12.4.5 (Monitoring of cloud services), CLD.13.1.4 (Alignment of
security management for virtual and physical networks). Also provides additional
guidance for 37 existing ISO 27002 controls in a cloud context. Both the CSP and the
CSC have guidance — ISO 27017 is unusual in that it provides controls for both
parties.
ISO/IEC 27018:2019 Code of practice for protection of personally identifiable information (PII) in public
cloud environments. Applicable to CSPs acting as data processors. Principles:
Consent (CSP only processes customer PII on customer's instructions — no
secondary use), Transparency (CSP discloses sub-processors and notifies of
changes), Data subject rights (CSP assists customer in fulfilling data subject
requests), Communication security (PII protected in transit — TLS), Notification (CSP
notifies customer of data breaches involving customer PII). Certification against ISO
27018: Provides customers with evidence that the CSP's PII handling practices are
audited. Particularly relevant for GDPR compliance — ISO 27018 certification
demonstrates CSP alignment with GDPR processor obligations.
SOC 2 (SSAE 18 Standard) System and Organisation Controls Report. AICPA (American Institute of Certified
Public Accountants) attestation standard. Applicable to service organisations that
process data on behalf of customers. Trust Services Criteria (TSC): Security (CC —
Common Criteria, MANDATORY in all SOC 2 examinations), Availability (A — systems
available for operation and use as agreed), Processing Integrity (PI — system
processing complete, valid, accurate, timely, authorised), Confidentiality (C —
information designated as confidential protected), Privacy (P — personal
information collected, used, retained, disclosed, disposed per AICPA privacy
principles). SOC 2 Report Structure: Management Assertion, Independent Service
Auditor's Report (opinion), Description of the system, Criteria and controls, Test
procedures and results, Other information. SOC 2 Type I: Opinion on design of
controls at a specific date. Limited value — shows controls were designed
appropriately but does not test whether they actually work. SOC 2 Type II: Opinion
on design AND OPERATING EFFECTIVENESS of controls over a specified period (the
practical minimum observation window is about 3 months; AICPA guidance indicates
periods shorter than 6 months may not give user entities sufficient assurance, and
12 months is the common enterprise expectation). Shows controls worked
consistently over time — this is what enterprises require. Bridge Letters: If the SOC 2
report is more than 6 months old, ask for a bridge letter (management
representation that no material changes occurred since the report period).
Complementary Subservice Organisation Controls (CSOCs): If the CSP uses sub-
processors (as AWS uses third-party data centre providers in some markets), the
SOC 2 scope must address how those sub-processors are managed.
CSA STAR (Security Trust Cloud Security Alliance's cloud-specific assurance programme. Built on CSA CCM
Assurance and Risk) (Cloud Controls Matrix). Three levels: STAR Level 1 — Self-Assessment: CSP
completes the CAIQ (Consensus Assessments Initiative Questionnaire) — a self-
assessment questionnaire mapped to the CCM controls. CCM v4.0 defines 197
control objectives across 17 domains, and CAIQ v4 translates these into 261 yes/no
questions. Note: CCM v4.1 (released December 2025) expanded this to 207 controls
and CAIQ v4.1 to 283 questions; for the October 2025 CCSP syllabus, CCM v4.0 / 197
controls is the reference figure. Submitted to CSA STAR Registry (public). No third-
party verification. Lowest cost, lowest assurance. STAR Level 2 — Third-Party
Assessment: CSP's CCM controls independently assessed by a third-party auditor.
Two variants: STAR Certification (assessment mapped to ISO 27001), STAR
Attestation (assessment mapped to SOC 2 Type II). Highest cost, highest assurance.
 STAR Level 3 — Continuous Monitoring: Ongoing, automated monitoring of selected
security metrics. Emerging programme. The CAIQ questionnaire is extremely useful
for cloud customer due diligence — it provides standardised answers to detailed
security questions about CSP controls. Request the CAIQ completion from any CSP
you are evaluating.
PCI DSS (Payment Card Current version: PCI DSS 4.0.1 (released June 2024 as a minor revision of 4.0). PCI
Industry Data Security DSS 4.0 was published March 2022; PCI DSS 3.2.1 retired March 31, 2024. The 51
Standard) future-dated requirements in 4.0 became mandatory March 31, 2025. Applies to any
entity that stores, processes, or transmits cardholder data (CHD) or sensitive
authentication data (SAD). Merchant levels: Level 1 (>6M Visa/Mastercard
transactions/year) — annual ROC (Report on Compliance) by QSA (Qualified Security
Assessor) + quarterly ASV (Approved Scanning Vendor) vulnerability scan. Level 2-4
— Self-Assessment Questionnaire (SAQ). 12 PCI DSS Requirements organised in 6
goals: Build and Maintain a Secure Network (firewall, no defaults), Protect
Cardholder Data (encryption), Maintain Vulnerability Management Programme
(anti-malware, patching), Implement Strong Access Control Measures (need-to-
know, unique IDs, physical security), Regularly Monitor and Test Networks (logging,
monitoring, pen testing), Maintain an Information Security Policy. Cloud PCI DSS
challenges: Shared responsibility — CSP controls satisfy some requirements;
customer must address the rest. The QSA must evaluate the cardholder data
environment (CDE) and understand which controls are managed by the CSP
(requires CSP's AOC — Attestation of Compliance — for applicable services).
FedRAMP (Federal Risk and U.S. government programme for authorising cloud services for use by federal
Authorization Management agencies. Mandatory for CSPs selling to U.S. federal agencies. Based on NIST SP 800-
Program) 53 Rev. 5 security controls. Impact levels (control counts per NIST SP 800-53 Rev. 5
baselines): FedRAMP Low (publicly available, non-sensitive data — approximately
156 controls), FedRAMP Moderate (Controlled Unclassified Information —
approximately 323 controls — most commonly required for agency data, ~73-80% of
authorised CSPs), FedRAMP High (highly sensitive data — approximately 410-421
controls). All three baselines share the same 17 control families; the difference is
depth and rigour within each family. Note: exact counts vary slightly across
published baselines and during transitions — focus on relative scale (Low <
Moderate < High) and the underlying NIST SP 800-53 Rev. 5 framework.
Authorization paths: JAB (Joint Authorization Board — DoD, DHS, GSA) Provisional
Authority to Operate (P-ATO): CSP is assessed by independent Third Party
Assessment Organisation (3PAO), JAB grants P-ATO, agencies can leverage P-ATO for
their own use. Agency ATO: Single agency assesses CSP, grants ATO, other agencies
can re-use. FedRAMP Marketplace: Public registry of FedRAMP-authorised CSPs and
services. 'Do once, use many': One FedRAMP authorisation can be reused across
multiple federal agencies, reducing duplicated assessment effort. FedRAMP 20x
(2025) is a modernisation initiative using automated Key Security Indicators to
accelerate Low baseline authorisation. Important: FedRAMP is AUTHORISATION, not
certification — it must be renewed with continuous monitoring.
FIPS 140-2 / FIPS 140-3 U.S. government standard for cryptographic modules. Validated by NVLAP (National
(Federal Information Voluntary Laboratory Accreditation Program) accredited labs. FIPS 140-3 (published
Processing Standard 140) 2019, effective September 22, 2019) SUPERSEDED FIPS 140-2. Critical exam-relevant
transition timeline: NIST stopped accepting new FIPS 140-2 validation submissions in
2022. All existing FIPS 140-2 certificates will be moved to the CMVP Historical List on
September 21, 2026 (just months after the CCSP October 2025 syllabus expires).
After that date, FIPS 140-3 is the ONLY active validation standard accepted for new
federal acquisitions. FIPS 140-3 is aligned with international standard ISO/IEC 19790
(security requirements) and ISO/IEC 24759 (test requirements). Four security levels
(apply to BOTH 140-2 and 140-3): Level 1: Basic security requirements for
cryptographic modules. Software may implement. No specific physical security
requirements. Level 2: Adds tamper-evident physical security — evidence of physical
opening visible. Role-based authentication. Level 3: Tamper-resistant physical
security (hard to open without triggering zeroisation). Identity-based authentication
(must authenticate to use module). Zeroisation upon tampering. Level 4: Most
 stringent. Complete envelope of physical security — protects against environmental
conditions (temperature extremes, voltage variations, radiation). Detects and
responds to any penetration attempt — zeroises all CSPs (Critical Security
Parameters) within specified response time. Use in government: NIST requires
federal agencies to use only FIPS-validated cryptographic modules. HSMs for federal
use must be FIPS 140-2 or 140-3 Level 3 or Level 4 validated. Exam: FIPS 140 applies
to cryptographic MODULES (hardware and software that perform cryptographic
operations), not to algorithms themselves (those are specified in FIPS 197 for AES,
FIPS 186 for DSA, etc.). For the CCSP October 2025 syllabus exam, both 140-2 and
140-3 are valid references — but understanding 140-3 is forward-looking
knowledge.
GDPR and Cloud — Chapter 3 GDPR Article 44: Personal data of EU/EEA residents may only be transferred outside
International Transfer the EEA when adequate protections exist. Mechanisms: Adequacy Decisions (Article
Mechanisms 45): European Commission formally recognises a country as providing equivalent
data protection. Current adequate countries: UK (post-Brexit adequacy decision),
Canada (PIPEDA framework), Japan, South Korea, Switzerland, New Zealand, Israel,
Argentina, and others. U.S.-EU Data Privacy Framework (2023): Replaced Privacy
Shield (invalidated by Schrems II in 2020). Self-certification by U.S. organisations
with Department of Commerce. Standard Contractual Clauses (SCCs, Article 46):
European Commission-approved model clauses embedded in contracts between
data exporters and importers. New SCCs published in 2021 — four modules for
different exporter/importer relationships (controller-controller, controller-
processor, processor-controller, processor-processor). Binding Corporate Rules
(BCRs, Article 47): Approved intragroup policies allowing international data transfers
within a multinational corporate group. Must be approved by a lead EEA data
protection authority. Derogations (Article 49): Explicit consent, contract necessity,
vital interests, public interest, legal claims — limited use, cannot be systematic.

D2 20% — Highest CLOUD DATA SECURITY Data lifecycle, classification, DLP,

Weight Domain encryption, IRM, retention, and auditability — protect data
everywhere

2.1 Cloud Data Concepts

FEYNMAN EXPLANATION | Why Data Security Is the #1 Priority in Cloud
In cloud computing, you are handing your most sensitive asset — your data — to a third party to store on
infrastructure you do not own, in facilities you cannot visit, on hardware you cannot inspect. Everything else in
cloud security ultimately exists to protect that data. The CCSP exam weights Domain 2 at 20% — the highest of
any domain. The exam writers understand that no matter how well you design your cloud architecture, how
mature your operations are, or how thoroughly you understand legal requirements — if you cannot protect the
data, none of the rest matters. Data in cloud has unique characteristics compared to on-premises: Data
dispersion (your single 'file' may be chunked and distributed across dozens of physical drives in multiple
availability zones for redundancy — it is simultaneously in multiple places), Multi-tenancy (your data shares
physical media with other customers' data, separated only by logical controls), Loss of physical control (you
cannot walk into the data centre and see where your data is — you must trust CSP controls), Jurisdictional
complexity (data fragments in multiple countries means multiple legal regimes apply simultaneously), Vendor
lock-in risk (data in proprietary formats is expensive and difficult to move). The data security lifecycle approach
means applying the right controls at the right time. CREATE data → immediately CLASSIFY it. STORE it → encrypt
it. USE it → minimise exposure. SHARE it → control the flow. ARCHIVE it → maintain protection. DESTROY it →
ensure it is unrecoverable. Every security decision maps to a phase in this lifecycle.

Data States and Cloud-Specific Threats

Term / Concept Explanation / Detail
Data at Rest Data stored on persistent storage media: databases, object storage (S3), block
volumes (EBS), file shares. Cloud-specific risks: Misconfigured access controls (public
S3 buckets exposed to the internet), Snapshot exposure (EBS snapshots shared
publicly or with wrong accounts), CSP insider access (CSP administrators have root-
level access to storage hardware — mitigated by customer-controlled encryption),
Insecure defaults (some CSP storage services default to unencrypted without explicit
customer configuration). Mitigations: Enable encryption for all storage resources
(enforce via organisation policy), Use customer-managed keys (BYOK), Audit access
permissions continuously (CSPM), Enable versioning and Object Lock for critical
data, Enable access logging for all storage.
Data in Transit Data moving between systems: client-to-server, server-to-database, service-to-
service within VPC, cross-region replication, on-premises to cloud. Cloud-specific
risks: Man-in-the-middle attacks on API calls (intercepting cloud management API
traffic), Unencrypted inter-service communication within VPC (common
misconception that VPC traffic is automatically secure — it is NOT encrypted by
default), Certificate issues (expired certs, weak cipher suites, TLS 1.0/1.1 still
enabled). Mitigations: TLS 1.2 minimum (TLS 1.3 preferred) for ALL inter-service
communication, Mutual TLS (mTLS) for service-to-service authentication (both
services present certificates), Enforce TLS via security groups / network ACLs (block
port 80 HTTP, allow only 443 HTTPS), Certificate lifecycle management (automated
renewal, monitoring for expiry), Periodic TLS configuration audits (Qualys SSL Labs,
[Link]).
Data in Use Data being actively processed in CPU and RAM. The most difficult state to protect —
data exists in plaintext in memory during computation. Cloud-specific risks:
Malicious CSP insider reading memory of running VMs (mitigated by hardware
memory encryption), VM escape attacks reaching adjacent VM memory, Memory
scraping malware within compromised VM. Emerging mitigations: Intel SGX
(Software Guard Extensions) — creates protected memory regions (enclaves) that
are encrypted with a hardware key that even the CPU's privileged ring 0 (OS,
hypervisor) cannot read, AMD SEV (Secure Encrypted Virtualisation) — encrypts
entire VM memory with per-VM keys, AWS Nitro Enclaves — isolated CPU and
memory environments for processing highly sensitive data, Google Confidential VMs
— AMD SEV-based encrypted VMs.
Data in Motion (Active Data being actively moved/migrated: database migrations, backup transfers, CSP-to-
Transfer) CSP data migrations, disaster recovery replication. Often confused with 'data in
transit' but distinct — data in motion involves large-scale, often unencrypted bulk
transfers for performance reasons. Security risk: migration windows where data may
be temporarily less protected. Best practice: encrypt even bulk data migrations, use
dedicated transfer services (AWS DataSync, Azure Data Box) with built-in encryption.

2.2 Cloud Data Storage Architectures — Technical Deep Dive

Term / Concept Explanation / Detail
Block Storage — Architecture Block storage presents raw storage as virtual disk volumes to VM instances. The
and Security volume appears as a standard block device (like a hard drive) — the operating
system and file system manage how data is laid out on it. Technical operation: Each
block (typically 4KB or 512B) is addressed by its block number. Write operations
commit specific blocks. Read operations retrieve specific blocks. No metadata stored
with the data at the block level — the file system (NTFS, ext4, XFS) built on top of
block storage manages file metadata. Cloud implementations: AWS EBS (Elastic
Block Store): volumes attach to EC2 instances. Types: gp3 (general purpose SSD), io2
(provisioned IOPS SSD for databases), st1 (throughput-optimised HDD for sequential
workloads), sc1 (cold HDD for archival). EBS volumes exist in a single availability
zone — cannot be directly attached across AZs. Azure Disk Storage: Managed Disks
(Premium SSD, Standard SSD, Standard HDD, Ultra Disk). GCP Persistent Disk:
Standard, Balanced, SSD, Extreme. Security controls: Encryption: AWS EBS default
 encryption (AES-256) using CSP-managed or CMK keys. Enforce encryption at
account level using AWS Config rules. Restrict snapshot access: snapshots inherit
volume encryption. Audit snapshot sharing: never share snapshots publicly for
production volumes. IAM: restrict who can create, delete, modify, attach volumes.
Monitor: CloudTrail for EBS API calls.
Object Storage — Object storage stores data as discrete objects (files) with a flat namespace (no
Architecture and Security directory hierarchy — though paths using '/' in key names simulate directory
structure). Each object comprises: data (the file), metadata (key-value pairs:
creation date, content-type, custom metadata), unique key (the object's name/path
within the bucket). Massively scalable: AWS S3 stores trillions of objects, PB-scale
storage. No limit on number of objects; individual object size up to 5TB (AWS S3).
Ideal for: static web assets, media files, data lake storage, ML training datasets, log
archives, backup files. Cloud implementations: AWS S3, Azure Blob Storage
(containers → blobs), GCP Cloud Storage (buckets → objects). S3 Storage Classes: S3
Standard (frequent access), S3 Intelligent-Tiering (unknown access patterns), S3
Standard-IA (infrequent access), S3 One Zone-IA, S3 Glacier Instant Retrieval, S3
Glacier Flexible Retrieval (minutes to hours), S3 Glacier Deep Archive (12 hours
retrieval). Security controls: Bucket policies: JSON-based policies controlling who can
perform what operations on which objects. BLOCK ALL PUBLIC ACCESS setting at
account level — this prevents ANY bucket from being accidentally made public.
Never allow Principal: '*' with s3:GetObject unless intentional CDN distribution.
Object Lock (WORM — Write Once Read Many): Compliance mode (nobody,
including root account, can delete until retention period expires) vs Governance
mode (users with special permission can delete). Used for: regulatory compliance
records, evidence preservation, audit logs. Versioning: maintains all historical
versions of every object. Deleted objects become 'delete markers' — original data
still retrievable. MFA Delete: require MFA to permanently delete versioned objects.
Server Access Logging: log all requests to objects — who accessed what, when, from
where. Replication: S3 Cross-Region Replication (CRR) for disaster recovery and data
residency compliance. Encryption: SSE-S3 (CSP-managed AES-256), SSE-KMS (CMK-
based — audit log of every key usage), SSE-C (customer-provided key — CSP never
stores the key). Client-side encryption: encrypt before uploading (CSP never sees
plaintext).
File Storage — Architecture File storage provides hierarchical shared file systems accessible via NFS (Network
and Security File System) or SMB/CIFS (Server Message Block/Common Internet File System)
protocols. Designed for: shared access (multiple VMs simultaneously read/write the
same filesystem), workloads that expect a filesystem interface (home directories,
application data, content management, shared code repositories, media processing
workflows). Cloud implementations: AWS EFS (Elastic File System): NFS-based,
accessible from multiple EC2 instances simultaneously, automatically grows and
shrinks. AWS FSx for Windows File Server: SMB-based, AD-integrated. AWS FSx for
Lustre: high-performance parallel filesystem for HPC/ML. Azure Files: SMB and NFS
support, integrates with Azure AD. GCP Filestore: NFS service. Security controls:
Network security: mount targets have security groups — restrict NFS access to
required subnets and EC2 security groups. Transport encryption: enforce TLS-in-
transit (available but must be explicitly configured on mount — some clients default
to unencrypted NFS). At-rest encryption: all managed file services encrypt at rest.
Access control: IAM for management operations (create/delete filesystem). POSIX
permissions and NTFS ACLs for file-level access control. Backup and replication: AWS
Backup supports EFS. Audit: Enable access logging to track who accessed which files.
Database Storage — Databases provide structured, queryable storage. Cloud databases: Relational (SQL):
Architecture and Security AWS RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Amazon Aurora
(MySQL/PostgreSQL-compatible, 6-way replication, up to 15 read replicas), Azure
SQL Database, Azure Database for PostgreSQL/MySQL, GCP Cloud SQL, GCP AlloyDB.
NoSQL: AWS DynamoDB (key-value and document), Azure Cosmos DB (multi-
model), GCP Firestore, GCP Bigtable (wide-column). Data warehouse: AWS Redshift,
Azure Synapse Analytics, GCP BigQuery. Security controls: Encryption at rest: TDE
(Transparent Data Encryption) — encrypts data files at storage level without
 application changes. AWS RDS: AES-256 encryption with CMK support. Column-level
encryption for sensitive fields (more granular than TDE). Encryption in transit: Force
SSL/TLS connections — AWS RDS supports ssl_ca parameter for connection string.
Reject unencrypted connections via security group (allow only 5432/5439 from app
servers, not from internet). Network isolation: Deploy databases in private subnets
(no direct internet access). Use VPC security groups to restrict access to only
application server security groups. Never expose database ports to [Link]/0.
Database Activity Monitoring (DAM): Monitor all SQL queries in real time. Alert on:
SQL injection patterns, unusually large result sets (data exfiltration indicator), access
outside business hours, access to sensitive tables by unexpected users. IAM
database authentication: Use IAM roles for database authentication instead of static
passwords (AWS RDS IAM authentication). Secrets rotation: Automatically rotate
database credentials using AWS Secrets Manager. Audit logging: Enable audit logs
for all database operations (query logging, authentication events, schema changes).
Log to S3 or CloudWatch Logs.
Ephemeral Storage — Ephemeral storage exists only for the lifetime of the compute instance — lost when
Security Implications the instance stops, terminates, or crashes. AWS: Instance store volumes (NVMe
SSDs physically attached to the host server). Azure: temporary disk. GCP: local SSD.
Performance characteristics: Extremely high performance (NVMe SSDs with
microsecond latency) because they are physically local to the compute. Data loss
scenarios: Instance stop/start (instance store volumes are cleared), Instance
termination (all data lost), Host failure (physical host failure = permanent data loss).
Security implications: NEVER store data in ephemeral storage that needs to persist
beyond the instance lifecycle. Ephemeral storage has lower access control surface
(no separate IAM policies, access controlled by OS permissions within the instance).
For security benefits: ephemeral data is harder to exfiltrate because it doesn't
persist — useful for processing highly sensitive data that should not be retained.
Also used for: scratch space during data processing, temporary working files during
image processing, caching for performance.
Archive Storage — Security Long-term, low-cost storage for data that is rarely or never accessed but must be
and Compliance retained for regulatory compliance, business continuity, or historical reference. AWS
S3 Glacier Flexible Retrieval: Expedited (1-5 minutes), Standard (3-5 hours), Bulk (5-
12 hours) retrieval options. AWS S3 Glacier Deep Archive: 12-hour standard
retrieval, 48-hour bulk. Azure Archive: lowest cost tier, hours to retrieve. Security
controls: Encryption: Archive storage should be encrypted with CMKs (not CSP-
managed default keys) — archive data may be retained for decades during which
CSP key management practices may change. Vault Lock (Glacier): WORM compliance
— immutable vault policy that prohibits deletion for specified retention period. Even
root account cannot delete locked vault data before retention period expires. Access
control: Archive data should be accessible to even fewer principals than active data
— restrict to DR/compliance team only. Key management: Critically important for
archives — the encryption keys must be preserved for the ENTIRE retention period.
If keys are rotated, old keys must be retained to decrypt data encrypted with them.
Document key-data mapping for archive data. Verify retrievability: Test restoration
procedures annually. A backup that has never been tested is not a backup — it may
be corrupted, incomplete, or encrypted with a key that no longer exists.

2.3 Data Security Technologies

Encryption Deep Dive — Implementation Specifics
FEYNMAN EXPLANATION | Why Implementation Details Matter as Much as the Algorithm
Security professionals sometimes think: 'We use AES-256, so we are secure.' This is wrong. The algorithm is the
easy part — mathematically unbreakable with current technology. The implementation details determine
whether your encryption actually provides security. Example 1 — Mode of operation: AES-128-ECB (Electronic
Codebook mode) is INSECURE despite using AES-128. ECB encrypts each 16-byte block independently with the
same key. The same plaintext block always produces the same ciphertext block. If you encrypt a bitmap image
with ECB, the encrypted image still shows the pattern of the original (famously demonstrated with the 'ECB
penguin' — you can clearly see the penguin outline in an ECB-encrypted image). AES-256-GCM (Galois/Counter
Mode) provides authenticated encryption — it proves the data was not modified as well as encrypting it.
Example 2 — Key storage: An application that stores its encryption key in the same database table as the
encrypted data provides zero additional security. An attacker who gets the ciphertext also gets the key. The key
must be in a SEPARATE system with separate access controls — ideally an HSM or cloud KMS. Example 3 — IV
reuse: GCM mode requires a random, unique Initialisation Vector (IV/Nonce) for every encryption operation.
Reusing the same IV with the same key completely breaks GCM — allows recovery of the key. This is a
programming error (not a cryptographic weakness in GCM itself) but has been the cause of real-world
vulnerabilities. The exam tests conceptual understanding, not cryptographic mathematics. Know: which
algorithms are appropriate, why (not broken, appropriate key length, appropriate mode), how keys should be
stored and managed, and what the CSP's tools (KMS, HSM) provide.

Term / Concept Explanation / Detail

Encryption at Rest — Option 1 — CSP-Managed Keys (SSE with CSP keys): Simplest. CSP generates,
Implementation Options manages, and rotates keys. Customer has zero key management overhead. CSP has
full access to both keys and data — they could technically decrypt data. Appropriate
for: non-sensitive data, development/test environments, data where CSP access is
acceptable. Option 2 — Customer Master Key in CSP KMS (SSE-KMS / BYOK):
Customer creates or imports a CMK into AWS KMS/Azure Key Vault/GCP Cloud KMS.
Customer controls: who can use the key (IAM policies), when the key is used
(CloudTrail audit log for every use), key rotation schedule. CSP performs
encryption/decryption operations on customer's behalf using the CMK. CSP
technically has access to the CMK during operations but cannot use it without
customer's IAM permissions. Appropriate for: sensitive regulated data where audit
trail of every key usage is required. Option 3 — External Key Manager (HYOK):
Customer maintains a key management server outside the CSP. Thales CipherTrust,
Fortanix Data Security Manager, Hashicorp Vault. CSP calls out to customer's key
manager to authorise each encryption/decryption operation. Key NEVER leaves
customer's environment. Most secure: CSP cannot access plaintext data without
customer's cooperation. Trade-off: availability risk (if key manager is down, cloud
data is inaccessible), latency impact (each operation requires network call to
customer's key manager). Option 4 — Client-Side Encryption: Application encrypts
data BEFORE sending it to cloud storage. CSP receives and stores only ciphertext —
never sees plaintext. Customer manages keys entirely. Most privacy-preserving: not
even a compromised CSP employee can access data. Trade-off: CSP cannot index,
search, or process the data. Client-side encryption SDKs: AWS Encryption SDK,
Google Tink, Azure Key Vault with client-side libraries.
TLS — Versions, TLS 1.3 improvements over 1.2: Eliminated weak cipher suites (no more RSA key
Configuration, and Certificate exchange, no more CBC mode, no more MD5/SHA-1), Reduced handshake from 2
Management round-trips to 1 (faster connection establishment), 0-RTT (zero round-trip time)
resumption (data sent in first packet — risk: replay attacks, use carefully), Forward
Secrecy mandatory (ephemeral key exchange — compromise of long-term key does
not compromise past sessions). Cipher suites in TLS 1.3: Only 5 allowed (all AEAD):
TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256,
TLS_AES_128_GCM_SHA256, TLS_AES_128_CCM_8_SHA256,
TLS_AES_128_CCM_SHA256. TLS configuration best practices: Minimum TLS 1.2
(disable TLS 1.0, 1.1, SSL), TLS 1.3 preferred, Disable weak cipher suites (RC4, 3DES,
NULL, EXPORT), Enable HSTS (HTTP Strict Transport Security) with long max-age,
Certificate transparency (all certificates logged to public CT logs), OCSP stapling
(include OCSP response in TLS handshake). Certificate Management: Automated
certificate management prevents expiry incidents (Let's Encrypt ACME protocol,
AWS ACM, Azure App Service Managed Certificates). Monitor certificate expiry (90
days warning, 30 days alert, 14 days critical). Test TLS configuration: Qualys SSL Labs
([Link]/ssltest), [Link].
mTLS (Mutual TLS) Standard TLS: Only the SERVER authenticates with a certificate. The client is
 unauthenticated at the TLS layer (clients may authenticate at the application layer
with passwords/tokens). mTLS (Mutual TLS): BOTH client and server present X.509
certificates during the TLS handshake. Each party cryptographically verifies the
other's identity before transmitting any data. Use cases: Service-to-service
authentication in microservices (each service has a certificate representing its
identity), API authentication for machine clients (replace API keys with certificates),
IoT device authentication (each device has a unique certificate), Zero Trust network
access. Benefits over API keys: Certificates can be short-lived (auto-renewed by
service mesh), Certificates are not 'stolen' and reused as easily as API keys (private
key never transmitted), Mutual authentication (both parties verified),
Cryptographically enforced (not just a header check). Implementation: Service mesh
(Istio, Linkerd) handles mTLS automatically for microservices — generates short-
lived certificates for each service identity, rotates them automatically, enforces
mTLS between all mesh-enrolled services. SPIFFE (Secure Production Identity
Framework for Everyone) and SPIRE provide standardised service identity for
microservices.
Homomorphic Encryption Allows mathematical computations to be performed on ENCRYPTED data without
decrypting it first. The computation happens entirely on ciphertext, and the result
(when decrypted) is identical to what would have been obtained by performing the
same computation on the plaintext. Use case: A hospital wants a cloud ML service to
analyse patient records to detect disease patterns, but cannot share unencrypted
PHI with the cloud provider. With homomorphic encryption: hospital encrypts
patient records → sends encrypted data to cloud → cloud ML service runs analysis
on encrypted data → returns encrypted results → hospital decrypts results. Cloud
provider never sees plaintext patient data. Current state: Fully Homomorphic
Encryption (FHE) is computationally expensive (100,000x+ overhead compared to
plaintext computation). Microsoft SEAL, IBM HElib, Google FHE libraries are available
for research. Practical uses today: Partial FHE (supporting limited operations) is
practical for specific use cases (private set intersection, privacy-preserving ML
inference). FHE is primarily a future technology — the CCSP exam covers it as an
emerging concept.

Data Obfuscation — Complete Technical Reference

FEYNMAN EXPLANATION | Why These Four Techniques Are NOT Interchangeable
Masking, tokenisation, anonymisation, and pseudonymisation are all called 'data protection techniques' but
they achieve fundamentally different goals and have fundamentally different reversibility characteristics. Using
the wrong technique for your compliance requirement is a serious error. The reversibility question: Can you get
back the original data? Masking: YES (original is still in the database — masking only changes the display).
Tokenisation: YES (original is in the vault — token maps to it). Pseudonymisation: YES (mapping table maps
pseudonym to original). Anonymisation: NO (irreversible — that is the whole point). Hashing: NO (one-way
function — you cannot un-hash). The GDPR question: Is the data still 'personal data' under GDPR after the
technique is applied? Masking: YES (original personal data still exists in the database). Tokenisation: YES (original
exists in vault, token links to it). Pseudonymisation: YES (mapping table allows re-identification — explicitly
stated in GDPR Recital 26). Anonymisation: NO (if truly irreversible, not personal data — GDPR Recital 26).
Hashing without salt: possibly yes (if original values are in a small search space, can be re-identified by hashing
all possibilities — e.g., hash of a date of birth). Hashing with salt: depends on whether re-identification is
possible. PCI DSS scope reduction: Tokenisation is the primary PCI DSS scope reduction technique. A system that
stores, processes, or transmits only tokens (not the original PAN) is potentially out of PCI DSS scope — the token
is meaningless without the vault. The vault and the detokenisation system ARE in scope. This allows retailers to
process payment tokens throughout their systems while only exposing the actual card number in the narrow
payment processing window.

Term / Concept Explanation / Detail

Data Masking — Technical Static Data Masking (SDM): Creates a permanently masked copy of the dataset for
Implementation use in non-production environments. Process: copy production database → apply
 masking rules to the copy → masked copy used for dev/test. The production
database is unmasked; only the masked copy is used for non-sensitive purposes.
Rule types: Substitution (replace with similar but fake value — 'John Smith' →
'Robert Jones'), Shuffling (rearrange values within a column across rows), Number
variance (add/subtract random percentage), Nulling (replace with NULL — simplest,
potentially useful), Format-preserving masking (replace with value in same format
— replace 16-digit card with different valid-format 16-digit string). Dynamic Data
Masking (DDM): Real-time masking at the database query level. Database itself
stores unmasked data; the masking is applied when specific user roles run queries.
Example: Customer service representative runs a query → sees XXXX-XXXX-XXXX-
1234. Database administrator → sees full card number. The same query to the same
database returns different results based on caller identity. Azure SQL DDM built-in.
Oracle Data Masking, IBM InfoSphere Optim. Use case: Call centre — agents see last
4 digits of card for customer identification but cannot see full card number for fraud
protection.
Tokenisation — Technical Tokenisation replaces sensitive data with a meaningless, randomly generated
Architecture surrogate value (token) that has no mathematical relationship to the original. Vault
architecture: The original sensitive value is stored in a secure, isolated token vault (a
database with extremely restricted access). The token is the key into this vault.
Token types: Reversible (vault maps token to original — can get original back by
querying vault with token). Format-preserving tokens (token has same format as
original — 16-digit card token vs 16-digit original — systems need no modification to
handle token). Non-reversible (one-way tokens — no vault, cannot recover original
— used for analytics where original is not needed). Tokenisation vs encryption:
Tokenisation stores the original in a vault (centralised) and replaces it everywhere
else with a token. There is no mathematical way to get from token to original
without vault access. Encryption replaces data with mathematically related
ciphertext — the ciphertext is mathematically related to the plaintext through the
key. If you have the key, you can decrypt. Tokenisation security: the token vault is
the crown jewel. Protect it with: strict access controls (fewer people should have
vault access than have access to encrypted data), HSM-stored vault keys,
comprehensive audit logging of all vault queries, physical and logical isolation from
tokenised systems. PCI DSS guidance: PCISSC has published tokenisation guidance
(PCI DSS Tokenisation Guidelines). Tokens that meet the criteria are out of PCI
scope.
Anonymisation — Technical True anonymisation: data from which individuals cannot be identified directly or
Requirements and Limitations indirectly, taking into account all means reasonably likely to be used (GDPR Recital
26). Techniques: Data suppression (remove high-cardinality identifiers: name, email,
SSN, phone). Generalisation (replace specific values with ranges: age 34 → age range
30-40, precise location → postcode). Perturbation (add statistical noise to numerical
values — individual values inaccurate but population statistics preserved). Data
aggregation (replace individual records with aggregate statistics — 'patients in
postcode X with condition Y = 45' rather than individual records). K-anonymity:
ensure each record is indistinguishable from at least k-1 other records. L-diversity:
extension of k-anonymity ensuring sensitive attributes are diverse within each
equivalence class. T-closeness: extension ensuring attribute distribution within each
class is close to overall distribution. Anonymisation failure modes: Re-identification
attacks: The AOL search data release (2006) — 'anonymous' search logs re-identified
individuals by combining searches. Netflix Prize dataset (2006/2008) — 'anonymous'
ratings re-identified by cross-referencing with public IMDb ratings. Researchers at
MIT showed 4 data points (location, time) re-identify 95% of individuals in
'anonymous' mobile phone datasets. Practical guidance: True anonymisation is
extremely difficult to achieve and maintain as datasets grow and additional external
data sources become available for correlation. For regulatory compliance,
pseudonymisation (reversible) with strong governance is often more achievable
than anonymisation (irreversible).
Pseudonymisation — GDPR- GDPR Article 4(5) defines pseudonymisation: 'the processing of personal data in
Specific Treatment such a manner that the personal data can no longer be attributed to a specific data
 subject without the use of additional information, provided that such additional
information is kept separately and is subject to technical and organisational
measures to ensure that the personal data are not attributed to an identified or
identifiable natural person.' Key points: Personal data is still personal data after
pseudonymisation (Recital 26). GDPR does NOT exempt pseudonymised data from
GDPR obligations. However, GDPR provides INCENTIVES for pseudonymisation:
reduces likelihood of harm in breach notification assessment (breach of
pseudonymised data less likely to require individual notification), may facilitate
certain research, statistics, and archive purposes, demonstrates privacy by design
(Article 25). Pseudonymisation techniques: Consistent replacement (same person
always gets same pseudonym — allows linking records across datasets). Random
replacement (different pseudonym each time — prevents linkage, but also prevents
analysis). Deterministic pseudonymisation (hash of identifier → pseudonym —
deterministic but one-way). Best practice: Maintain mapping table in a separate
system with stricter access controls than the pseudonymised data. Access to
mapping table should require additional authorisation beyond access to
pseudonymised data.
Hashing — Security Cryptographic hash functions: SHA-256, SHA-384, SHA-512, SHA-3. Properties
Requirements and Failure required: Preimage resistance (given hash H, computationally infeasible to find input
Modes M such that H(M) = H), Second preimage resistance (given M, computationally
infeasible to find M' ≠ M such that H(M) = H(M')), Collision resistance
(computationally infeasible to find any M, M' where H(M) = H(M')). MD5: BROKEN
— collisions found (2005). Do NOT use for security purposes. SHA-1: BROKEN for
collision resistance (2017). Do NOT use for digital signatures. SHA-256+: Secure. Use
for data integrity, digital signatures, commitment schemes. Password hashing
(different from data hashing): Do NOT use SHA-256/SHA-512 for password storage
— they are designed to be FAST, which makes brute-force attacks fast. Use
dedicated password hashing functions: Argon2 (winner of Password Hashing
Competition 2015 — memory-hard), bcrypt (work factor tunable), scrypt (memory
and CPU hard). Always add a unique random SALT per user before hashing: H(salt ||
password). Salt prevents rainbow table attacks (precomputed hash tables for
common passwords) and ensures identical passwords produce different hashes.
Pepper: Server-side secret added to all password hashes — provides additional
protection if database is leaked but pepper is not. HMAC (Hash-based Message
Authentication Code): H(K || M) where K is a secret key. Provides both integrity AND
authentication — proves both that the data was not modified AND that it came from
a party with knowledge of the key.

Data Loss Prevention (DLP) — Comprehensive Coverage

Term / Concept Explanation / Detail
DLP Architecture Patterns Enterprise DLP systems consist of three components: (1) Central Management
Server: policy definition, alert management, reporting, incident workflow. (2)
Detection Engines: inspect content for policy violations — pattern matching,
fingerprinting, ML classification. (3) Enforcement Points: where policy is actually
applied — network egress, endpoint, cloud service APIs. DLP must be
comprehensive: data can leave through email, web upload, cloud sync, USB,
printing, photograph of screen. Endpoint DLP covers local data movement; Network
DLP covers transmission; Cloud DLP covers data in cloud services. Without all three,
there are gaps.
Network DLP — Technical Deployment: Inline (agent between internal network and internet — inspect and
Detail block traffic in real time) vs Out-of-band (mirror/tap — inspect copies of traffic,
cannot block without additional mechanism). Inline provides blocking capability but
adds latency. Works by: Intercepting all outbound traffic (SMTP, HTTP/S, FTP, SFTP,
instant messaging, web uploads). Content inspection: Pattern matching for
structured data (credit card regex — word-boundary + union of
Visa/MC/Amex/Discover patterns). Document fingerprinting: hash sensitive
 documents → match hash fragments in outbound traffic. Machine learning: classify
document sensitivity based on trained model. SSL/TLS inspection: required for
HTTPS traffic — DLP cannot inspect encrypted payloads without SSL interception.
SSL inspection introduces a MITM (man-in-the-middle) — the DLP system decrypts,
inspects, re-encrypts. Creates legal and privacy concerns — users should be
informed. Policy actions: Alert (log and notify), Block (prevent transmission), Encrypt
(encrypt before sending), Quarantine (hold for human review), Redact (remove
sensitive content).
Endpoint DLP — Technical Agent installed on endpoint devices (laptops, workstations). Monitors and controls:
Detail File copy to removable media (USB drives, external HDDs), Printing (shadow copy of
printed content, block/alert on sensitive content), Screen capture, Clipboard
operations (detect paste of sensitive data from clipboard), Email composition
(inspect attachments and body before send — before Network DLP can act), File
sharing uploads (OneDrive, Dropbox, SharePoint), Application usage (block copying
from secure application to unsecure one). Works offline: If the laptop is not
connected to the network, Network DLP provides no protection. Endpoint DLP
enforces policies locally. Challenge: Agent management — deploying, updating,
monitoring agents across all endpoints. Agent circumvention — technically
sophisticated users may attempt to bypass (booting from USB, using virtualization,
removing agent). Integration with MDM (Mobile Device Management) for policy
consistency.
Cloud DLP — Technical Detail CSP-native: AWS Macie (ML-based discovery and classification of sensitive data in
S3), Azure Purview Information Protection (scan SharePoint, OneDrive, Exchange,
S3, GCP), GCP Cloud DLP API (inspect and de-identify sensitive data in Cloud Storage,
BigQuery, Datastore). CASB-based: Cloud Access Security Broker sits as a proxy or
API connector between users and cloud services. Scans content going to or stored in
cloud services. Examples: Netskope, Microsoft Defender for Cloud Apps (formerly
MCAS), Zscaler, Symantec CloudSOC. API-based CASB: connects to cloud service APIs
(Microsoft 365 Graph API, Box APIs, Salesforce APIs) to scan content already in the
cloud. Proxy-based CASB: inline between user and cloud service (forward proxy:
device agent routes cloud traffic through CASB; reverse proxy: user authenticates to
cloud service via CASB URL). DLP detection in cloud context: Content classification,
sensitive data discovery in cloud storage, policy-based controls for data sharing (e.g.,
'no document classified Restricted may be shared externally via Google Drive'), real-
time blocking of sensitive uploads to unapproved cloud services.

2.4 Data Discovery and Classification — Complete Framework

Term / Concept Explanation / Detail
Data Discovery Tools and Enterprise data discovery at scale: Agent-based discovery (software agents deployed
Methods on endpoints and servers scan local filesystems and databases), Agentless network
scanning (network-based scans using credentials to authenticate and scan remote
systems), Cloud API-based discovery (CSP APIs to enumerate storage resources and
scan content — AWS Macie uses ML to classify S3 content), Database scanning
(connect to databases and scan schema metadata to identify sensitive tables and
columns). Classification metadata: structured databases can be classified at the
column level (column named 'SSN' is very likely to contain Social Security Numbers).
unstructured documents require content-based classification. Content-based
classification techniques: Regular expressions for structured patterns (SSN: pattern
matching 3-2-4 digit groups, credit card, IBAN, passport). NLP (Natural Language
Processing) for contextual classification (sentences mentioning medical conditions
near patient identifiers = likely PHI). ML-based classification: train a model on
labelled examples of document types. Fingerprinting: hash known sensitive
documents and detect copies/derivatives.
Data Classification Schemes Government/military classification: Top Secret (disclosure could cause exceptionally
grave damage), Secret (damage to national security), Confidential (could harm
 national security), Unclassified (cleared for release). Commercial classification
examples: Restricted/Highly Confidential (board-level data, M&A information,
unpublished financial data, attorney-client privileged), Confidential (personal data of
employees/customers, financial forecasts, strategic plans, legal agreements,
competitive intelligence), Internal (operational policies, internal communications,
project plans), Public (press releases, marketing materials, published research).
Classification criteria: Sensitivity of the data (would unauthorised disclosure harm
the organisation or individuals?), Regulatory requirements (does HIPAA, PCI DSS,
GDPR classify this data type?), Legal privilege (attorney-client communications are a
special category), Business value (trade secrets, patents, proprietary algorithms).
Classification responsibilities: Data Owner: Senior business role (VP, Director)
responsible for specific data assets. Determines classification. Accountable for data
security decisions. Data Custodian: IT role responsible for implementing controls.
Applies technical measures directed by owner. Data Steward: Business role ensuring
data quality, consistency, and usage compliance. Data Subject (GDPR): Individual
whose personal data is processed. Has rights under GDPR.
Data Labelling and Mapping Data labelling applies classification metadata to individual data items: Persistent
labels: embedded in the document itself (MIP sensitivity labels in Microsoft Office
documents), survive copying and format conversion where supported. Non-
persistent labels: stored in a separate metadata system or classification database.
Labels can be applied: Manually (user selects sensitivity from dropdown),
Automatically (ML classifier applies label based on content), Template-based (new
documents in 'Finance' team SharePoint inherit 'Confidential — Finance' label).
Labels trigger automated controls: DLP policies based on label, IRM protection
applied automatically, Cloud storage policies (Restricted-labelled files cannot be
shared externally), Audit and monitoring (access to Restricted data generates
security alerts). Data flow diagrams: Visual representation of how data moves
through systems. Required by: GDPR Article 30 (Records of Processing Activities —
must document all personal data flows), PCI DSS (scope definition — must know
exactly where CHD flows), ISO 27001 (risk assessment requires understanding of
data flows), Incident investigation (need to trace where data went). Data flow
diagram elements: Data stores (databases, file servers, cloud storage), Data flows
(connections between systems — include protocol, port, data types transmitted),
Processes (applications and services that process data), External entities (systems
and people outside the system boundary), Trust boundaries (lines separating
different security zones or ownership boundaries).

2.5 Information Rights Management (IRM) — Technical Detail

Term / Concept Explanation / Detail
IRM Architecture IRM provides persistent, policy-based protection that travels with the data
regardless of location. Core components: Rights Management Server / Policy Server:
Issues licences, validates identities, enforces revocation, provides audit logging.
Certificate Authority: Issues user/device certificates for authentication to IRM
system. Document Encoder/Wrapper: Encrypts document and embeds IRM policy
metadata + encrypted content key. IRM-Aware Application: Enforces licence
permissions when rendering document (Microsoft Office, PDF readers, email
clients). Authentication: Before accessing an IRM-protected document, the user
authenticates to the rights management server, which verifies their identity (via
certificate or SAML assertion from IdP) and then issues a licence specifying their
permissions for that document. Online vs offline: IRM-protected documents can be
configured to require online validation on every open (maximum security, no offline
access) or to cache licences for offline use (offline window of N days). Revocation:
Revoke the licence certificate for a user → that user can no longer access any IRM-
protected documents, even copies already downloaded. Revoke the document's
content certificate → NOBODY can access the document (even current licence
holders). This is the most powerful IRM capability — remotely and instantly disable a
 document globally.
Rights Types and Granularity Full Control: All rights — same as document owner. Can add and remove
permissions. Can save, print, copy, export, modify. View/Read Only: Can see content
but cannot modify, print, or copy. Print: Can print physical copy (number of prints
may be limited). Edit: Can modify content. Save As: Can save to new file. Copy: Can
copy content to clipboard. Forward (email): Can forward email with IRM-protected
content. Reply/Reply All: For IRM-protected emails. Expiry: Access rights expire after
specified date/time — document becomes inaccessible. Watermarking: Dynamic
watermark containing username/email and timestamp overlaid on every printed or
screen-captured page — deters and detects unauthorised disclosure. Screen capture
restriction: IRM-aware applications can attempt to block screen capture (OS-level
API hooks — cannot prevent camera aimed at screen). Programmatic access
restriction: IRM prevents automation tools from extracting content (macros, scripts).
Rights Managed Office documents (RMS/AIP): Microsoft Rights Management Service
/ Azure Information Protection. PDF Rights Management: Adobe Acrobat/Reader
with Adobe LiveCycle Rights Management. SharePoint IRM: Libraries can be
configured so all documents downloaded are automatically IRM-protected.
CASB Integration with IRM Cloud Access Security Broker (CASB) can enforce IRM policies for cloud services that
do not natively support IRM. CASB applies IRM protection: when sensitive
documents are uploaded to cloud services (Box, Dropbox, Google Drive, SharePoint
Online), CASB intercepts the upload, applies IRM protection, and allows the
protected document to be stored in cloud. When the document is downloaded, the
IRM wrapper is already in place — the user must authenticate to the IRM server to
access content. This allows organisations to use cloud storage services while
maintaining data control even after documents leave the organisation.

2.6 Data Retention, Legal Holds, and Deletion

Term / Concept Explanation / Detail
Retention Policy Framework A data retention policy must specify for each data category: Minimum retention
period (regulatory minimum — cannot delete before this), Maximum retention
period (must delete after this — GDPR's storage limitation principle), Format
requirements (must originals be retained or are summaries/derivatives
acceptable?), Storage location requirements (must data be stored on-premises? in a
specific country?), Access controls during retention period (who can access archived
data?), Deletion method (cryptographic erasure, physical destruction, overwriting),
Documentation requirements (what records of deletion are kept?). Conflicting
retention requirements: When multiple regulations apply simultaneously, retain for
the LONGEST applicable period. After the LONGEST retention period expires, delete
unless a legal hold prevents it. Example: A healthcare payment record is subject to
both HIPAA (6 year minimum) and SOX (7 year minimum) — must retain for 7 years
(the longer requirement).
Legal Hold — Technical A legal hold (also called litigation hold or preservation hold) is an instruction that
Implementation certain data must be preserved and not deleted because it is or may be relevant to
legal proceedings or regulatory investigations. Trigger: When litigation is 'reasonably
anticipated' — this is a legal standard, not just when a lawsuit is filed. The duty to
preserve begins as soon as the organisation reasonably anticipates legal
proceedings. Technical implementation: Email Legal Hold: Microsoft 365 Litigation
Hold or In-Place Hold — items cannot be permanently deleted from affected
mailboxes for hold duration. Users can still delete items (they go to Recoverable
Items folder) — hold preserves items in Recoverable Items even after user deletion.
SharePoint/OneDrive Legal Hold: via Microsoft Purview Compliance (formerly
Compliance Centre) — documents preserved even if user deletes them. Cloud
storage: S3 Object Lock Compliance mode — prevents deletion even by root
account. Database: database-level audit trail + restricted access to DELETE
operations for held data. Legal hold management: Legal team identifies relevant
 custodians (employees with relevant data) and data sources. IT implements
technical holds on those systems. Regular audits confirm hold is active. Hold must
cover ALL relevant data — email, files, databases, chat messages, cloud storage.
Failure to preserve: Spoliation of evidence = intentional or negligent destruction of
evidence relevant to litigation. Consequences: Court sanctions (ranging from
adverse inference instruction — judge tells jury to assume the destroyed evidence
was damaging — to dismissal of the organisation's claims or defences, to monetary
sanctions, to criminal contempt). Legal hold overrides every automated retention
and deletion policy — no exceptions.
Secure Deletion Standards NIST SP 800-88 Rev. 1 (Guidelines for Media Sanitisation): The definitive standard for
data destruction. Three sanitisation categories: Clear: Overwriting with defined
patterns. Acceptable for media that will be reused within the same security domain.
Purge: More thorough media-specific techniques (degaussing, Secure Erase for
SSDs). Media can be released for reuse outside the original security domain.
Destroy: Physical destruction (shredding, incinerating). Media cannot be reused.
Cloud application: NIST 800-88 section on Cloud: 'The data owner may be unable to
perform media sanitisation on storage devices owned and operated by a cloud
service provider.' The recommended approach is: ensure data is always encrypted
with keys under customer control → destroy the encryption key when data is to be
disposed of. CMVP-validated cryptographic modules (FIPS 140-2 Level 3+) for key
management provide the highest assurance that key destruction is complete and
verified. Documentation: Maintain records of all data destruction: date, method,
data description, person responsible, witness (for physical destruction). Required by
PCI DSS, HIPAA, and ISO 27001.

2.7 Auditability, Traceability, and Accountability

Term / Concept Explanation / Detail
Comprehensive Cloud Audit AWS CloudTrail: Logs all AWS API calls across all services — who made what API call,
Logging when, from what IP, with what parameters, and what was the result. Covers:
Console actions, CLI commands, SDK calls, cross-account activity. Enable CloudTrail
for ALL regions (including regions you don't use — attackers may use inactive
regions). Enable multi-region trail with log file validation (cryptographic hash chain
— detect log tampering). Store logs in a dedicated, isolated S3 bucket with: Object
Lock (prevent deletion), MFA Delete, separate AWS account (logs not affected by
compromise of main account). CloudTrail log file validation: Each log file has a
corresponding digest file containing hashes. AWS signs the digest file. Verifying the
signature proves logs have not been modified. AWS VPC Flow Logs: Network-level
audit log. Captures: source/destination IP, source/destination port, protocol, bytes
transferred, packets, action (ACCEPT/REJECT). Does NOT capture payload (packet
content). Available for: VPCs, subnets, network interfaces. Ingest into CloudWatch
Logs or S3 for analysis. AWS Config: Continuous monitoring of AWS resource
configurations. Records configuration changes with timestamps. Enables:
compliance monitoring (rules that check configurations against policies),
configuration history (see what changed and when), relationship tracking (which
resource depends on what). AWS Config rules: Managed rules (pre-built by AWS)
and custom rules (Lambda functions). Rules evaluate compliance continuously.
SIEM Architecture and Cloud SIEM (Security Information and Event Management) is the central hub for security
Integration visibility. Architecture components: Log Collection: Collect from all sources — CSP
APIs (CloudTrail, Activity Log, Cloud Audit Logs), Endpoint agents (Windows Event
Logs, Linux syslog, security agent logs), Application logs (web server access logs,
application error logs, authentication logs), Network device logs (firewall logs,
IDS/IPS alerts, VPC Flow Logs), Security tool alerts (WAF, DLP alerts, vulnerability
scanner findings). Normalisation: Convert logs in different formats (CEF, LEEF, syslog,
JSON, XML) to a common schema for consistent querying and correlation. Indexing
and Storage: Time-series indexed storage for fast search. Hot storage (30-90 days —
fast queries). Warm/cold storage (12 months - 7 years — archival). Correlation
 Rules: Rules that detect suspicious patterns across multiple log sources: Failed login
from IP X followed by successful login from IP X (brute force then success), Large
data download from database followed by upload to external IP (data exfiltration),
New admin account created outside business hours (insider threat), API call from
previously unseen country (account compromise). SIEM for cloud: Challenges —
massive volume of cloud API logs, event normalisation across multiple CSPs, cost of
log ingestion (SIEM vendors charge per GB ingested), multi-cloud visibility. Solutions:
Cloud-native SIEMs: Microsoft Sentinel (Azure-native, with AWS connectors), AWS
Security Lake, Google Chronicle. Hybrid: Splunk or Elastic with cloud log connectors.
Chain of Custody in Cloud Chain of custody is the chronological documentation of all custody, control, transfer,
Forensics analysis, and disposition of evidence. Digital chain of custody requirements:
Collection: Document exactly when evidence was collected, who collected it, what
collection method was used, and what the hash of the collected item is.
IMMEDIATELY hash evidence (MD5 + SHA-256): store hashes in a separate system
before any other operation. Preservation: Store evidence in a write-protected
location (S3 Object Lock Compliance mode). Any change to preserved evidence
breaks chain of custody. Transfer: Document every time evidence changes hands —
who received it, when, why. Re-hash upon receipt to confirm integrity. Analysis:
Work only on verified COPIES of evidence, not originals. Hash the analysis copy
before and after. Document all analysis steps. Disposal: Document how and when
evidence is disposed of after legal proceedings conclude. Cloud-specific challenges:
Ephemeral evidence (evidence that existed only in volatile memory or ephemeral
storage may already be gone), Multi-tenancy (CSP cannot always isolate your
evidence from co-tenant data on the same physical device — chain of custody may
be compromised if CSP cannot confirm isolation), Geographic distribution (evidence
in multiple jurisdictions — different legal standards for admissibility in each),
Timestamps (cloud logs use UTC — convert to local time zones carefully, account for
DST).

D3 17% of exam CLOUD PLATFORM AND INFRASTRUCTURE SECURITY Data

centre design, risk analysis, infrastructure hardening, BC/DR
— protect the foundation

3.1 Cloud Infrastructure Components — Technical Reference

FEYNMAN EXPLANATION | The Physical-to-Virtual Stack — Understanding What You Control
Every cloud interaction ultimately runs on physical hardware. Understanding the layers helps you understand
what YOU control vs what the CSP controls — and where the security boundaries are. Physical layer: Servers
(CPUs, RAM, NICs, storage controllers), networking equipment (switches, routers, load balancers, firewalls),
physical media (SSDs, HDDs, NVMe). CSP OWNS and OPERATES this layer. You have ZERO access. Security here is
the CSP's responsibility — physical access controls, hardware security, supply chain integrity of hardware.
Hypervisor layer: Software that creates and manages VMs. Allocates physical resources to VMs. Enforces
isolation between VMs. CSP OPERATES. You CONFIGURE (through APIs — not direct hypervisor access). The
hypervisor is the most critical security boundary in cloud — VM escape attacks target this layer. VM layer: Your
virtual server — virtual CPUs, virtual RAM, virtual NICs, virtual disks. In IaaS: YOU own and operate this layer.
You install the OS, apply patches, configure security. In PaaS: CSP operates the OS layer within the platform. You
only deploy application code. Network layer: Virtual switches, routers, security groups, ACLs, VPCs. CSP provides
the infrastructure. YOU configure the security policy — which ports are open, which subnets can talk to each
other, what traffic is allowed in/out. Management plane: The API control surface — AWS APIs, Azure APIs, GCP
APIs, management consoles. This is the attack surface that is unique to cloud. An attacker who compromises
your management plane (your AWS access keys, your Azure service principal) controls your ENTIRE environment
without touching a single VM.

Term / Concept Explanation / Detail

Compute Layer Security Physical CPU sharing: Multiple VMs share physical CPU cores via time-slicing and
context switching. Modern CPUs have hardware features for VM isolation: Intel VT-x
(Virtualisation Technology for IA-32/64), AMD-V (AMD Virtualisation), Intel
VT-d/AMD-Vi (IOMMU — Input/Output Memory Management Unit: prevents DMA
attacks where a VM could write to another VM's memory by controlling DMA-
capable devices). CPU vulnerabilities unique to cloud: Spectre variants (speculative
execution side channels — can leak data from other processes/VMs sharing the
same core), Meltdown (kernel memory isolation bypass), Foreshadow/L1TF (L1
cache side channels), MDS (Microarchitectural Data Sampling — RIDL, Fallout,
ZombieLoad). All have been mitigated through: CPU microcode updates (from
Intel/AMD), OS kernel patches (KPTI — Kernel Page Table Isolation), Hypervisor
patches, Hardware replacement for the most severe cases.
Memory Security Physical RAM partitioned by hypervisor using Extended Page Tables (EPT for Intel) or
NPT (Nested Page Tables for AMD). Each VM sees only its own 'guest physical
address space' — the hypervisor translates to actual host physical addresses.
Memory security threats: Row Hammer attack (rapidly reading memory to cause bit
flips in adjacent rows — can corrupt other VMs' memory), Cross-VM memory reads
via side channels (Spectre-type attacks measuring cache timing to infer other VMs'
memory contents). Hardware memory encryption: Intel TME (Total Memory
Encryption) — encrypts all DRAM with a random key generated at boot. AMD SME
(Secure Memory Encryption) — similar, per-page granularity. Makes physical
memory attack (cold boot attack, bus snooping) impractical. Azure, GCP, and AWS
offer confidential computing instances using these features.
Storage Layer Security Storage area network (SAN) in CSP data centres: Fibre Channel or iSCSI storage
fabric. Logical unit numbers (LUNs) allocated to hypervisor hosts. Hypervisor
presents storage to VMs as virtual disks. In-flight storage encryption: For NVMe and
SAN — traffic between host and storage may be unencrypted at the hardware level
in the CSP fabric. Application-level encryption (encrypt before writing to block
storage) is the most reliable approach. At-rest encryption: Almost all CSPs encrypt all
data at rest at the storage layer by default. But this is CSP-managed encryption —
the CSP holds the keys. For true protection against CSP access, use customer-
managed keys (BYOK) or client-side encryption. Data isolation: Logical isolation of
storage volumes between tenants. When a volume is decommissioned and
reallocated, CSPs zero or overwrite storage before it is available to new tenants (but
you cannot independently verify this — rely on contractual commitments and SOC 2
evidence).
Management Plane Security The cloud management plane is the control plane: AWS APIs, Azure APIs, GCP APIs,
management consoles, CloudFormation/ARM/Terraform. The management plane is
accessible from the INTERNET — any authenticated request from anywhere can
provision, modify, or destroy infrastructure. This makes it a unique attack surface
with no on-premises equivalent. Management plane attack vectors: Credential
compromise (stolen API keys, phishing of console credentials, leaked credentials in
source code/container images), Privilege escalation (exploiting overly permissive
IAM policies to gain elevated access), SSRF (Server-Side Request Forgery — tricking a
web application server into making requests to the metadata service at
[Link], which returns IAM credentials for the EC2 role — IMDSv2
mitigates this by requiring a PUT request token), Confused deputy attacks (tricking
another account's service into performing actions in your account using trust
relationships). Management plane protection: MFA on all accounts (especially
root/global admin), SCPs (Service Control Policies) or Azure Policy to limit what
actions are even possible, IP allowlisting for console access (restrict to corporate IP
range), Comprehensive logging (ALL API calls — CloudTrail), Anomaly detection
(CloudWatch Alarms or AWS GuardDuty on management API behaviour), Short-lived
credentials (assume role sessions, instance profiles — avoid long-lived static access
keys), Separate management and workload accounts (AWS Organisations —
management account used only for account management, not workloads).
3.2 Secure Data Centre Design — Physical Security in Depth
FEYNMAN EXPLANATION | Concentric Rings of Physical Security
Physical security follows a model of concentric rings — each ring adds another layer of defence. An attacker
must defeat every ring to reach the protected assets. The cost and detection probability increases at each ring.
Ring 1 — Site perimeter: The outermost boundary of the property. Perimeter fencing (typically 2.4-3.6m/8-12ft,
anti-climb, intrusion detection on fence), Vehicle barriers (concrete bollards, K-rated barriers rated for vehicle
impact speed and weight), Security lighting (motion-activated, eliminate dark areas that could provide cover),
CCTV coverage of all perimeter approaches (no blind spots, 30+ day retention), Security guard patrols
(randomised routes to avoid predictable patterns). Ring 2 — Facility exterior: The building itself. Single
controlled access points (all other entry points sealed), Vehicle access barriers (mantrap for delivery vehicles —
one barrier closes before other opens), Package inspection area (deliveries checked before entering facility),
Security personnel at entrance (verify identity, check access list, verify credentials against biometric), Visitor
management (register all visitors, escort requirement, visitor badge with visible expiry). Ring 3 — Data centre
interior: The interior of the data centre building. Mantraps (interlocked doors — first door closes before second
opens, prevents tailgating), Biometric authentication (fingerprint, hand geometry, retina scan, iris recognition —
cannot be shared or stolen like badges), Two-person integrity (in highest security areas, no individual accesses
alone — two authorised persons must enter together and exit together), Badge-accessed door to every data
hall, Security cameras inside data halls monitoring all movement. Ring 4 — Individual cages/cabinets: The
innermost ring. Cage locks for multi-tenant co-location (customer's cage is locked, CSP staff cannot access
without customer presence), Individual rack locks (each rack requires separate access), Cable management
(tidy, documented cabling makes unauthorised insertions detectable), Equipment anchoring (servers bolted to
rails — not trivially removable), Equipment asset tagging (RFID or barcode tracking of every device).

Term / Concept Explanation / Detail

Physical Security Biometric readers: Fingerprint (most common — false acceptance rate 0.001%, false
Technologies rejection rate 0.1%), Retina (highest security — pattern of blood vessels, FAR
0.0001%), Iris (high security — FAR 0.00008%), Hand geometry (3D shape of hand —
FAR 0.1%, used in older systems), Facial recognition (increasingly used, higher FAR,
issues with disguise/lighting). Biometric accuracy: FAR (False Acceptance Rate —
wrongly accepts unauthorised person — security failure). FRR (False Rejection Rate
— wrongly rejects authorised person — availability failure). EER (Equal Error Rate —
the FAR/FRR crossover point — lower is better). Multi-factor physical
authentication: combine biometric + badge + PIN for highest security areas.
Mantraps: Double-door system with lock interlock — both doors cannot be open
simultaneously. Prevents tailgating (following an authorised person through a door).
Some mantraps have weight sensors or camera systems to detect multiple people.
Used at all data centre entry points. CCTV systems: IP cameras with high resolution
(4K for detail at distance), infrared night vision, wide dynamic range (for high-
contrast lighting), 30-90 day retention, digital video recorder with WORM storage
(evidence preservation), remote monitoring capability.
Environmental Controls Power: Utility power from multiple independent feeds (from different substations if
possible). UPS (Uninterruptible Power Supply): Provides bridge power during
generator startup (typically 10-30 seconds). Battery or flywheel-based. N+1
redundancy (one UPS can fail without power loss). Generators: Diesel backup
generators. Start time: 10-30 seconds (hence UPS required for bridge). Fuel storage:
48-72 hours minimum on-site. Fuel supply contracts for extended outages. Power
Redundancy Levels: N+0 (no redundancy), N+1 (one unit can fail — minimum for
production), 2N (full dual infrastructure — required for Tier IV), 2N+1 (dual
infrastructure plus extra unit). Cooling: CRAC (Computer Room Air Conditioning)
units or in-row cooling. Hot aisle / cold aisle configuration: Cold air supplied from
raised floor into cold aisle → enters server front → hot exhaust exits server rear into
hot aisle → returns to CRAC units. Hot aisle containment (caps and curtains around
hot aisle) increases efficiency by preventing hot/cold air mixing. Power Usage
Effectiveness (PUE): Ratio of total data centre power to IT equipment power. PUE
1.0 = perfectly efficient (impossible). PUE 1.2-1.5 = excellent. PUE >2.0 = inefficient.
 Major hyperscale data centres achieve PUE 1.1-1.2. Fire Suppression: Water
(traditional sprinkler — absolutely NOT for server rooms — water damage destroys
hardware and creates electrocution risk), FM-200 (HFC-227ea — chemically
suppresses fire — leaves no residue — electrically non-conductive), Inergen (blend
of N2, Ar, CO2 — reduces oxygen to below combustion level but above human
survival — people can evacuate), NOVEC 1230 (3M proprietary clean agent — most
environmentally friendly), CO2 (effective but dangerous to human life — typically
only for unoccupied rooms or as backup). VESDA (Very Early Smoke Detection
Apparatus): Aspirating smoke detection — continuously samples air from multiple
points, detects combustion particles at parts-per-billion concentration. Can detect
fire before visible smoke — provides 10-15 minutes earlier warning than traditional
smoke detectors. Allows evacuation and suppression before significant damage
occurs.
Data Centre Tier Classification Tier I (Basic): Single path for power and cooling. No redundancy. Susceptible to
(Uptime Institute) disruptions from planned maintenance or unplanned failures. Annual downtime:
28.8 hours (99.671% availability). Tier II (Redundant Components): Single path with
redundant components (N+1). Has UPS and generators. Annual downtime: 22.0
hours (99.749%). Tier III (Concurrently Maintainable): Multiple independent paths
for power and cooling. Equipment can be maintained without taking down IT load.
At least one path is active; others are standby. Annual downtime: 1.6 hours
(99.982%). Certification requires on-site inspection. Tier IV (Fault Tolerant): All
components fully redundant (2N). Any single failure — power, cooling, network —
has no impact on IT load. Multiple active paths simultaneously. Annual downtime:
26.3 minutes (99.995%). Highest cost, highest availability. Exam: 'concurrently
maintainable' = Tier III. 'Fault tolerant' = Tier IV. Any single point of failure eliminates
Tier III and IV status.
Network Connectivity Multiple ISP connections: Diverse physical routes (cables entering facility from
different directions), Different ISPs (avoid single ISP failure), Different bearer
technologies (fibre + microwave as backup), BGP (Border Gateway Protocol) routing
with multiple ASNs. Meet-Me Room (MMR): Shared space in data centre where
customers cross-connect to network providers. Diverse Entry Points: Network cables
enter facility through multiple physically separated entry points — a single backhoe
accident should not cut all connectivity. Dark Fibre: Data centre may own or lease
dedicated fibre capacity for highest bandwidth and security applications. Latency:
Physical distance from data centre affects latency. Latency budget considerations
for: Real-time applications (VoIP, video conferencing: <150ms round-trip for
acceptable quality), Database transactions (synchronous replication constrained by
latency — <10ms between primary and replica for acceptable performance), High-
frequency trading (microseconds matter — co-location required).

3.3 Risk Analysis for Cloud Infrastructure

Term / Concept Explanation / Detail
Quantitative Risk Assessment ALE (Annual Loss Expectancy) = SLE × ARO. SLE (Single Loss Expectancy) = Asset
— Formulas Value (AV) × Exposure Factor (EF). EF is the percentage of asset value lost in a single
incident (0.0-1.0). ARO (Annual Rate of Occurrence) = expected frequency of threat
event per year. Example: Asset value = $500,000 (production database). Exposure
Factor = 0.40 (estimated 40% of data value lost in a breach). SLE = $500,000 × 0.40 =
$200,000. ARO = 0.25 (estimated 1 breach every 4 years = 0.25 per year). ALE =
$200,000 × 0.25 = $50,000 per year. Control evaluation: If a control costs
$30,000/year and reduces ALE from $50,000 to $10,000, the ALE reduction is
$40,000. Since $40,000 > $30,000, the control is cost-justified. ROI of security = ALE
reduction - control cost = $40,000 - $30,000 = $10,000 net benefit. Secondary ALE:
After implementing a control, recalculate ALE with reduced ARO or EF.
Qualitative Risk Assessment When numerical data is unavailable or unreliable, use qualitative assessment.
Common approaches: 5×5 Risk Matrix (5 levels of likelihood × 5 levels of impact = 25
 risk combinations coloured Red/Amber/Green). NIST SP 800-30 Qualitative:
Likelihood (Very High, High, Moderate, Low, Very Low) × Impact (Very High, High,
Moderate, Low, Very Low) → Risk Level (Critical, High, Medium, Low, Info). OCTAVE
Allegra (Operationally Critical Threat, Asset, and Vulnerability Evaluation): risk-based
strategic assessment. Benefits of qualitative: Faster to execute, no false precision
from unreliable numerical inputs, easier to communicate to non-technical
stakeholders. Limitations: Subjective, inconsistent across assessors, cannot directly
calculate ROI for security investments. Hybrid approach: qualitative for initial
assessment and prioritisation, quantitative for detailed ROI analysis of specific
controls.
Cloud-Specific Risk Factors Lock-in risk: Dependency on proprietary CSP services (AWS Lambda, DynamoDB,
Azure Cognitive Services) creates migration risk. Assess: what is the cost and effort
to migrate to another CSP? What if the CSP changes pricing by 2x? Vendor longevity
risk: What happens to your business if the CSP goes bankrupt, is acquired by a
competitor, or exits a market? How long would data recovery take? Supply chain
risk: CSP uses third-party hardware (servers from Dell, HPE; network from Cisco),
third-party software (hypervisors, networking stacks), and third-party facilities (co-
location providers in some markets). A supply chain compromise affecting the CSP's
hardware could impact all customers. Egress pricing risk: Cloud data egress (data
leaving the cloud, especially inter-region) is expensive. This creates perverse
incentives: organisations may avoid moving data out of cloud for DR exercises or
vendor comparison because of cost — this is a risk management problem.
Regulatory change risk: Governments may enact data localisation laws (Russia's
Federal Law 242-FZ requiring personal data of Russian citizens to be stored in
Russia), cross-border transfer restrictions (GDPR adequacy decision revocation), or
CSP-specific restrictions (ITAR-controlled data cannot be on non-US-controlled CSP
infrastructure). Monitor regulatory developments.

3.4 Security Controls for Cloud Infrastructure

Term / Concept Explanation / Detail
Network Security Defence in depth for cloud networks: Internet Edge: CDN (CloudFront, Azure CDN) +
Architecture DDoS protection (AWS Shield Advanced, Azure DDoS Protection Standard — L3/L4
and L7 protection). WAF (Web Application Firewall) — OWASP rule sets, rate
limiting, bot protection. DMZ (Demilitarised Zone): Public-facing resources (load
balancers, API gateways) in dedicated public subnet. Internet-accessible but
firewalled from internal resources. Application Tier: Private subnet. Accessible only
from DMZ load balancers. Security groups: allow only required ports from DMZ
security group. Database Tier: Private subnet, isolated from application tier as much
as possible. Security groups: allow only database port (5432, 3306, etc.) from
Application tier security group only. Management: Dedicated management network,
accessible only via bastion host with MFA. No direct internet access to management
interfaces. East-West Traffic (Service-to-Service): Historically assumed trusted within
VPC — DO NOT assume this. Implement network policies between services (K8s
Network Policies), use security groups to restrict service-to-service communication
to only required ports, consider service mesh (Istio) for mTLS between
microservices.
Endpoint Security for Cloud Cloud-native endpoint security: AWS Systems Manager (SSM): agent-based
Instances management without SSH keys. Patch Manager automates patching. Session
Manager replaces SSH/RDP (no open ports required, fully logged). AWS Inspector:
Agent-based vulnerability scanning. Identifies CVEs in installed packages, network
reachability issues. CIS Benchmark compliance assessment. Azure Defender for
Servers: Microsoft Defender for Endpoint integrated into Azure VMs. Qualys Cloud
Agent: Third-party vulnerability scanning integrated with CSP. EDR (Endpoint
Detection and Response): CrowdStrike Falcon, Microsoft Defender for Endpoint,
SentinelOne — deployed as agents on cloud VMs. Detects: malware execution,
suspicious process chains, lateral movement, credential theft. Behavioural
 detection: baseline normal process behaviour, alert on deviations. Ephemeral
instance challenge: Short-lived instances (spot, auto-scaling) may not have EDR
agent fully operational before they terminate. Consider integrating EDR into
AMI/image bake process — agent is pre-installed and pre-configured.
Configuration Management Immutable infrastructure: build new → don't patch old. Golden AMI/Image Pipeline:
and Compliance Source code repository (Git) → CI/CD pipeline → Security scan (SAST, SCA, container
scan, CIS Benchmark hardening check) → Build golden AMI → Automated testing →
Approved AMI → All instance launches use this AMI → Retire old AMIs after new
AMI is validated. Configuration drift detection: AWS Config rules continuously
monitor resource configurations against defined standards. Azure Policy audits
resources against compliance requirements. GCP Organisation Policy Constraints
enforce guardrails. CSPM (Cloud Security Posture Management): Automated
scanning of cloud configurations against security best practices and compliance
frameworks. Tools: Prisma Cloud (Palo Alto), Wiz, Orca Security, AWS Security Hub
(aggregates findings from Config, Inspector, GuardDuty, IAM Analyser, Macie),
Lacework. CSPM detects: publicly accessible S3 buckets, overly permissive security
groups, unencrypted storage volumes, public-facing databases, IAM
misconfigurations, logging disabled.

3.5 Business Continuity and Disaster Recovery — Implementation Guide

Term / Concept Explanation / Detail
Cloud BC/DR Architecture Step 1: Determine RTO and RPO requirements from BIA. Step 2: Map requirements
Decision Framework to architecture pattern: RTO <minutes + RPO <seconds → Active-Active multi-region.
RTO <1 hour + RPO <minutes → Warm Standby. RTO <4 hours + RPO <30 minutes →
Pilot Light. RTO <24 hours + RPO <24 hours → Backup and Restore. Step 3: Select
replication strategy: Synchronous (zero RPO, performance impact, geographic
constraints — typically <100km between sync replicas), Asynchronous (near-zero to
low RPO, no performance impact, any geographic distance). Step 4: Design
automation: Automated health checks (Route 53 health checks, ALB target group
health checks, Kubernetes liveness probes), Automated failover (Route 53 DNS
failover routing policy, AWS Global Accelerator, Azure Traffic Manager), Auto-scaling
in DR region (use auto-scaling groups to scale up DR capacity when failover is
triggered). Step 5: Define recovery runbooks: Exactly which steps are taken, in which
order, by which team member, with what expected outcome and rollback criteria at
each step. Step 6: Test, test, test: Document test results, gaps, and remediation.
Retest after remediation.
Backup Strategy for Cloud 3-2-1 Rule: 3 copies of data, 2 different storage media, 1 off-site. Cloud adaptation: 3
copies (production in Region A, replica in Region A multi-AZ, backup in Region B).
AWS Backup: Centralised backup service covering EBS volumes, RDS databases,
DynamoDB tables, EFS filesystems, Aurora clusters, EC2 instances, S3 buckets.
Backup plans define: frequency (hourly, daily, weekly), retention period, cold
storage transition (move to Glacier after N days), copy to another region (cross-
region backup). Cross-account backup: Copy backups to a separate AWS account
with its own management controls — compromised main account cannot destroy
backups. WORM backups: S3 Object Lock Compliance mode (even root cannot
delete until retention expires). Azure Backup: Coverage for VMs, SQL Server, SAP
HANA, Azure Files, Blobs. Backup vault with soft delete (14-day recovery after
accidental deletion). Backup immutability (optional — prevents deletion before
retention period). Recovery testing: Automated recovery validation — after each
backup, automatically restore to an isolated environment and run validation checks.
Alert if restoration fails. Untested backups are not backups.
Disaster Recovery Testing — Tabletop Exercise: Convene BC/DR team + IT + business leaders. Present a disaster
Detailed Procedures scenario (e.g., 'Primary AWS us-east-1 region is completely unavailable due to a
major hurricane'). Walk through the DR plan step-by-step in discussion only.
Identify: gaps in the plan, unclear procedures, missing contact information,
 dependencies not accounted for. Document findings and update plan. Frequency:
quarterly. Walkthrough Drill: Same as tabletop but more detailed — follow the
runbook step-by-step in discussion, with each team member actually looking up the
systems and verifying they can access what they need. Duration: half-day.
Frequency: semi-annually. Functional Test: Execute specific DR procedures in a test
environment. Example: actually initiate RDS read replica promotion to standalone
master in DR region, actually redirect a test URL to DR region, verify DNS
propagation, test application functionality in DR region with real team members
using the application. Do NOT use production data. Duration: full day. Frequency:
annually. Parallel Test: Bring up DR environment completely. Run both primary and
DR environments simultaneously. Redirect a subset of test traffic (or internal user
traffic) to DR environment. Validate all functionality. Primary remains active — no
customer impact. Duration: 1-3 days. Frequency: annually for critical systems. Full
Interruption Test: Actually cut over to DR environment. Primary environment is
taken offline. All traffic serves from DR. Most disruptive — schedule during lowest-
traffic window. Highest-value test — proves actual recoverability. Duration: hours.
Frequency: annually or bi-annually for most critical systems. After any test: RCA for
any failures found, update runbooks, assign remediation, retest.

D4 17% of exam CLOUD APPLICATION SECURITY Secure SDLC, threat

modelling, API security, testing methodologies, IAM
solutions

4.1 Training, Awareness, and Security Culture

Term / Concept Explanation / Detail
Developer Security Training Role-specific training: Developers (secure coding in specific language/framework —
Python/Django security, Java/Spring security, [Link] security), DevOps Engineers
(IaC security scanning, CI/CD pipeline security, container security, secrets
management), Security Champions (embedded security advocates within
development teams — bridge between security team and developers — receive
deeper training, provide first-line security review). Training content: OWASP Top 10
with practical lab exercises (not just slides), Language-specific secure API usage (use
parameterised queries for SQL, not string concatenation), Common pitfalls in the
organisation's specific stack, Threat modelling basics (so developers can participate
in threat modelling sessions). Effectiveness measurement: Pre- and post-training
knowledge assessments, Phishing simulation click rates (for all staff), Code
vulnerability rates before and after training (track security finding rates in SAST over
time).
OWASP Top 10 (2021) — EXAM NOTE: For the CCSP October 2025 syllabus exam, OWASP Top 10:2021
Detailed Technical Coverage remains the official reference. OWASP Top 10:2025 was released November 2025
(after CCSP syllabus freeze), introducing two new categories — A03:2025 Software
Supply Chain Failures (expanded from 2021 A06 Vulnerable Components) and
A10:2025 Mishandling Exceptional Conditions — and absorbed 2021's A10 SSRF into
A01 Broken Access Control. For your October 2025 syllabus exam, master the 2021
list below. A01 — Broken Access Control (↑ from #5 to #1): Occurs when users can
act outside their intended permissions. Examples: Insecure Direct Object References
(IDOR/BOLA — change userId=123 to userId=456 in URL to access another user's
data), Missing function-level access control (non-admin user can call admin-only API
endpoints by directly calling the URL), CORS misconfiguration (API allows requests
from any origin with credentials — allows cross-site data theft), Missing access
control check after successful authentication (authenticated but check if user should
access THIS resource). Prevention: Deny by default (if no explicit permission, deny),
Check access control on EVERY server-side request (not just at login), Implement
logging and alerting on access control failures. A02 — Cryptographic Failures:
 Sensitive data transmitted or stored without adequate encryption. Examples: Credit
card numbers stored in plaintext database, TLS 1.0/1.1 still enabled, Weak hash
algorithms (MD5, SHA-1) for password storage, Not enforcing HTTPS (HTTP
accessible, no HSTS). A03 — Injection: Untrusted data sent to an interpreter as part
of a command or query. SQL injection (most common): user input embedded in SQL
query without parameterisation. Example: SELECT * FROM users WHERE username
= '' OR '1'='1'; Command injection: [Link]('ping ' + user_input) — user inputs 'x;
rm -rf /'. Prevention: Parameterised queries/prepared statements (never
concatenate user input into queries), Input validation (allow-list validation — only
permit expected characters), ORM usage (abstracts away raw SQL). A04 — Insecure
Design: Architectural and design flaws that no implementation can fix. Missing
threat modelling, Missing rate limiting by design (cannot bolt-on later), No abuse
case consideration during requirements. A05 — Security Misconfiguration: Insecure
default configurations, unnecessary features enabled, error messages with sensitive
information, missing security hardening. Examples: AWS S3 public access, default
admin credentials not changed, directory listing enabled on web server, detailed
error messages exposing stack traces. A08 — Software and Data Integrity Failures:
Code and infrastructure that does not protect against integrity violations. CI/CD
pipeline security (unsigned updates, auto-updates from untrusted sources), Insecure
deserialization (deserialising untrusted data that can execute code — Java
serialisation vulnerabilities). A10 — SSRF (Server-Side Request Forgery): Application
fetches a remote resource based on user-supplied URL. Attacker provides URL
pointing to internal service: [Link]
credentials/ — retrieves IAM credentials of EC2 instance role. Prevention: Allow-list
of permitted URLs/IPs (deny all internal addresses), Disable HTTP redirects, Use
IMDSv2 (requires token to access metadata service).

4.2 Secure Software Development Lifecycle (SDLC) — Technical Reference

FEYNMAN EXPLANATION | The Cost of Late Security — Why Shift Left Is Not Optional
The IBM System Sciences Institute study found that the relative cost of fixing a defect increases by
approximately 10x at each subsequent phase of development. A defect fixed in requirements: $1. In design:
$10. In code: $100. In testing (internal): $1,500. After release (production): $10,000+. After a public breach:
millions (investigation, regulatory fines, litigation, reputational damage). This exponential cost curve explains
why Shift Left (moving security activities to the left — earlier — in the development process) is not just a
philosophical preference but an economic necessity. A developer finding an injection vulnerability during code
review (SAST) and fixing it in 30 minutes represents $100 of remediation. The same vulnerability found by an
attacker after release represents $1M+ in breach response, regulatory penalties, and lawsuits. DevSecOps
transforms security from a gate (security team reviews and approves before release) to a pipeline (security
checks are automated in every step of the build process). The pipeline enforces security — developers cannot
bypass it without making a policy exception. Security findings in the pipeline stop the build just like failing unit
tests stop the build. Key DevSecOps principle: Security as Code — security policies, compliance requirements,
and security tests are expressed as code, stored in the same repository as application code, versioned,
reviewed, and tested like application code. This makes security auditable, consistent, and automated.

Term / Concept Explanation / Detail

Requirements Phase Security Security requirements elicitation: Conduct threat modelling early (even a
Activities whiteboard session with development team identifies major threats before a line of
code is written). Define security acceptance criteria for every user story. Abuse
stories: For every user story ('As a user, I can view my account balance'), define the
corresponding abuse story ('As an attacker, I could view any user's account balance
by changing the account ID in the URL'). Privacy requirements: Identify all personal
data that will be processed. Apply data minimisation (do we NEED this data?).
Define data retention and deletion requirements. Define who can access what. Legal
and compliance requirements: Map applicable regulations to technical requirements
(HIPAA requires audit logging of all PHI access, PCI DSS requires no CVSSv3 critical
 vulnerabilities in payment applications). Security requirements should be as testable
as functional requirements.
Design Phase Security Threat modelling: Structured analysis of potential security threats to the application.
Activities Performed during design to influence architecture decisions when changes are
cheapest. Threat modelling with STRIDE on data flow diagrams: Create a data flow
diagram showing all data flows, processes, data stores, and external entities. Draw
trust boundaries. For each element, identify STRIDE threats: Spoofing (who could
impersonate this entity/process?), Tampering (who could modify this data flow or
data store?), Repudiation (who could deny performing this action?), Information
Disclosure (who could access this data that should not?), Denial of Service (who
could make this component unavailable?), Elevation of Privilege (who could gain
unauthorised permissions?). For each identified threat: rate it (DREAD or CVSS),
define mitigation control, assign to a developer to implement. Security design
patterns: Input validation at every entry point, Output encoding for every output
context (HTML encoding for HTML context, URL encoding for URL context, etc.),
Error handling (never expose stack traces or internal details in user-facing error
messages — log internally but show generic error to user), Principle of least privilege
for every component, Defence in depth (multiple security controls for each risk),
Secure by default (the default configuration is the secure configuration).
Implementation Phase Secure coding standards: OWASP Application Security Verification Standard (ASVS):
Security Activities Three levels of verification — Level 1 (basic: all apps), Level 2 (standard: apps
handling sensitive data), Level 3 (advanced: high-value/high-risk apps). Covers:
Authentication, Session management, Access control, Input validation,
Cryptography, Error handling, API security. SAFECode Fundamental Practices for
Secure Software Development. Language-specific: CERT C/C++/Java Secure Coding
Standards. SAST integration: SonarQube (supports 30+ languages, integrates with
GitHub/GitLab/Azure DevOps, OWASP rules, custom rules, security hotspots for
human review). Checkmarx (enterprise, accurate, but expensive). Semgrep (open
source rule-based, highly customisable, fast). CodeQL (GitHub's semantic code
analysis — models data flow to find complex vulnerabilities). Pre-commit hooks: Run
lightweight SAST and secrets detection on every commit before it is pushed. Detect-
secrets (Yelp), gitleaks, truffleHog detect API keys, passwords, tokens in code.
Prevent secrets from EVER entering the repository (even if removed later, they
remain in git history — grep through git history for credentials).
Testing Phase Security DAST with OWASP ZAP: Active scanner attacks running web application. Passive
Activities scanner analyses all traffic passing through ZAP (when used as proxy). AJAX Spider
crawls JavaScript-heavy applications. API scanning: import OpenAPI/Swagger spec to
define endpoints. Authentication: configure ZAP with session tokens for
authenticated scanning. Burp Suite Professional: Industry standard for manual and
automated web application testing. Intruder (automated parameter fuzzing),
Repeater (manually craft and replay requests), Scanner (automated vulnerability
scanning). Burp Collaborator (out-of-band interaction detection — useful for
detecting blind SQLi, SSRF, blind XSS). Penetration Testing Methodology: Scoping
(define what is in-scope and out-of-scope, get written authorisation — NEVER test
without authorisation), Reconnaissance (OSINT — LinkedIn, Shodan, certificate
transparency logs, subdomain enumeration), Scanning (port scanning with nmap,
service detection, vulnerability scanning with Nessus or OpenVAS), Exploitation
(attempt to exploit identified vulnerabilities — document each attempt and
outcome), Post-exploitation (if initial access gained, attempt lateral movement to
assess blast radius), Reporting (CVSS-scored findings, reproduction steps, evidence
screenshots, remediation guidance, executive summary). Penetration testing in
cloud: Request written authorisation from CSP (AWS, Azure, GCP all have
penetration testing policies — some require advance notification). Do NOT test CSP
infrastructure (only test your resources). Testing restrictions: some testing types
(DDoS testing, social engineering of CSP employees) may require separate
agreements.
4.3 Threat Modelling — Complete Reference
Term / Concept Explanation / Detail
STRIDE — Applied Example Application: An e-commerce web application with a login page, product catalogue,
shopping cart, and payment processing. Data flow diagram elements: External
entity: Customer browser. Process: Login, Product Catalogue, Cart Service, Payment
Processor. Data stores: User Database, Product Database, Session Store. External
entity: Payment gateway. STRIDE analysis for Login process: Spoofing threat:
Attacker creates a fake login page that looks identical and phishes credentials.
Authentication mitigation: HTTPS (prevent MiTM), domain validation, MFA, security
awareness training. Tampering threat: Attacker modifies login response to bypass
authentication (e.g., change isAuthenticated=false to true in cookie). Integrity
mitigation: Server-side authentication state (never trust client-side authentication
state), signed and encrypted session tokens. Repudiation threat: Attacker performs
brute-force attack and later denies it. Non-repudiation mitigation: Comprehensive
login audit logging (IP, timestamp, username, success/failure, user agent).
Information Disclosure threat: Login error message reveals whether username exists
vs password is wrong ('No account found' vs 'Invalid password'). Confidentiality
mitigation: Generic error message ('Invalid credentials' — does not reveal which
field was wrong). Denial of Service threat: Bot floods login endpoint with requests,
overwhelming the service. Availability mitigation: Rate limiting per IP, CAPTCHA
after N failed attempts, WAF bot protection. Elevation of Privilege threat: SQL
injection in login form allows authentication bypass. Authorisation mitigation:
Parameterised queries, input validation, WAF with SQLi rules.
PASTA — Seven Stages in Stage 1 — Define Objectives: Business objectives (process credit card payments),
Practice compliance objectives (PCI DSS Level 1), technical objectives (prevent account
takeover). Stage 2 — Define Technical Scope: Application architecture diagram,
technology stack (React/[Link]/PostgreSQL/AWS), network boundaries, external
systems (payment gateway, identity provider). Stage 3 — Application
Decomposition: Data flow diagrams, use case analysis, entry points (web browser,
mobile app, admin console, API), data classification (CHD — cardholder data —
highest sensitivity). Stage 4 — Threat Analysis: Threat intelligence (known attacks
against e-commerce: Magecart card skimming, credential stuffing, bot fraud), threat
agents (organised crime groups targeting CHD, competitors, disgruntled employees),
attack scenarios. Stage 5 — Vulnerability and Weakness Analysis: SAST findings,
DAST findings, dependency vulnerabilities, configuration weaknesses, business logic
flaws. Stage 6 — Attack Modelling and Simulation: Attack trees (root = 'steal
cardholder data', branches = 'SQL injection', 'XSS skimmer', 'credential theft', 'insider
theft'). Attack simulation using findings from Stage 4 and 5. Stage 7 — Risk Analysis
and Impact: Map each attack to business risk (financial loss, regulatory fine,
reputational damage). Prioritise remediations by risk level. Define residual risk
acceptance.
Attack Trees A hierarchical diagram representing a security attack. Root node: the attacker's goal
(e.g., 'Exfiltrate customer credit card numbers'). Branches: the methods to achieve
the goal. Leaves: specific atomic attacks. AND nodes: all sub-goals required. OR
nodes: any sub-goal sufficient. Example tree for 'Exfiltrate CHD': Root: Exfiltrate
CHD. Child 1 (OR): Exploit application vulnerability → Child 1.1: SQL injection in
payment form. Child 1.2: XSS to inject card skimmer. Child 1.3: SSRF to access
internal database. Child 2 (OR): Compromise an authorised user → Child 2.1: Phish
credentials of payment system admin. Child 2.2: Brute force weak password. Child
2.3: Session hijacking. Child 3 (OR): Compromise infrastructure → Child 3.1: Exploit
unpatched server. Child 3.2: Misconfigured S3 bucket. Child 3.3: Compromise CI/CD
pipeline (supply chain). Attack trees quantify risk: assign cost and probability to each
leaf node → compute overall attack probability and cost.

4.4 Software Testing Methodologies — Technical Reference

Term / Concept Explanation / Detail
SAST Deep Dive SAST analyses code without executing it. Analysis methods: AST (Abstract Syntax
Tree) analysis: parse source code into a tree structure and analyse patterns.
Identifies: dangerous function calls (gets(), strcpy() in C/C++), SQL concatenation
patterns. Taint analysis: track data flow from 'sources' (user input) through code to
'sinks' (SQL query, system command, HTML output). If tainted data reaches a sink
without sanitisation → vulnerability. Identifies: SQLi, XSS, command injection, path
traversal. Control flow analysis: analyse all possible execution paths. Identifies: null
pointer dereferences, resource leaks. Data flow analysis: track variable values across
functions. Identifies: use-after-free, integer overflows. Integration patterns: IDE
plugin: developers see findings in real-time as they write code (fastest feedback).
Pre-commit hook: before committing, SAST runs on changed files. CI pipeline: on
every PR/merge — results visible in code review. Quality gate: builds fail if new
high/critical findings introduced. Tuning: SAST generates false positives. Tune rules
to eliminate noise — dismiss false positives with documented justification. Track:
false positive rate, true positive rate, time-to-fix. Target: no new CRITICAL or HIGH
findings in merged code.
DAST — Technical DAST configuration for cloud applications: Authenticated scanning: configure with
Configuration valid session cookies or API tokens (scanning without authentication misses 60-70%
of vulnerabilities in authenticated web apps). Scope: define the scope precisely —
which domains, URL paths, parameters are in-scope. Include all entry points: web
interface, REST API endpoints (import OpenAPI spec), mobile app backend APIs.
Active scanning risks: DAST actively probes for vulnerabilities — can cause data
deletion (DELETE requests), trigger email sending (form submissions), or create test
records in databases. Run against staging environment, not production. Throttle
scanning rate to avoid DoS-like effects on staging. API scanning: Import
OpenAPI/Swagger spec into ZAP or Burp. DAST generates requests for every
endpoint with fuzzing payloads. Authentication: configure API key or OAuth token.
DAST detects: Injection vulnerabilities (SQLi, LDAP injection, XSS, XML injection),
Authentication issues (session fixation, missing secure cookie flags), Authorisation
issues (horizontal privilege escalation by modifying user IDs), Information disclosure
(server banners, error messages, debug endpoints), SSL/TLS issues (certificate
validation, weak cipher suites), Business logic issues (only partially — DAST is not
good at understanding business rules).
Software Composition Third-party open-source and commercial components compose 70-90% of modern
Analysis (SCA) application code. SCA identifies: Known CVEs in specific package versions (cross-
referenced against NVD, GitHub Advisory Database, Snyk vulnerability database),
Outdated packages with available updates, License compliance issues (GPL-licensed
library in proprietary product may trigger compliance requirements), Transitive
dependencies (your code depends on Library A which depends on Library B which
has a CVE — SCA catches this). SCA integration: IDE plugin (developer sees CVEs in
dependencies as they add them), CI pipeline (scan on every build — block if critical
CVEs in dependencies), Container image scanning (Trivy, Grype — scan all packages
installed in container). Remediation: most straightforward: update to fixed version.
If no fixed version: virtual patch (WAF rule blocking exploitation), compensating
control, replace with alternative library. Dependency confusion attack: attacker
publishes a malicious package to public npm/PyPI with the same name as an internal
private package — package manager pulls public (malicious) version over private
version. Prevention: Private repository with name reservation, package
scope/namespace enforcement, integrity verification (hash pinning). SBOM
(Software Bill of Materials): complete inventory of all software components. NIST SP
800-161 covers software supply chain security. Executive Order 14028 requires
SBOM for software sold to U.S. federal government.
Penetration Testing in Cloud Cloud pen testing specifics: Pre-testing authorisation: AWS allows penetration
testing of EC2, RDS, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk,
and more without prior approval. Prohibited: DoS/DDoS, DNS hijacking, port
flooding, protocol fuzzing that affects CSP infrastructure. Azure: similar permitted
 testing list. GCP: notify Google before testing. Scope definition: clearly identify all
assets to be tested (IP ranges, domain names, specific services, accounts). Exclude
CSP-owned resources. Cloud-specific attack scenarios: Metadata service exploitation
(SSRF to [Link] to retrieve IAM credentials), IAM privilege escalation
(explore all IAM permissions to find paths to admin), Lateral movement between
cloud accounts (assume-role cross-account pivoting), Supply chain via CI/CD
(compromise build pipeline to inject malicious code), Container escape and lateral
movement in Kubernetes, Serverless function exploitation (event injection, function-
level IAM weaknesses). Cloud pen testing tools: ScoutSuite (multi-cloud security
auditing), Pacu (AWS exploitation framework), ROADtools (Azure exploitation), GCP
exploitation toolkit, CloudMapper (AWS environment visualisation).

4.5 API Security — Comprehensive Technical Reference

FEYNMAN EXPLANATION | API Security — Why Broken Object-Level Authorisation Dominates
BOLA (Broken Object-Level Authorisation) is the #1 API vulnerability for a simple reason: it reflects a
fundamental error in thinking about security. Developers often implement authentication correctly (user must
log in) but forget authorisation (logged-in user can only access THEIR data). Consider an API endpoint: GET
/api/v1/orders/{orderId}. Authentication: the request includes a valid JWT token — the user is authenticated as
User A. The developer checks: is there a valid token? Yes. Returns the order. But never checks: is this order
OWNED by User A? User A, authenticated, calls GET /api/v1/orders/1234 and gets their order. User A then tries
GET /api/v1/orders/1235 — this is User B's order. The API returns it because the user is authenticated and there
is no object-level check. The fix: every time your API returns an object, verify that the authenticated user has
permission to access THAT SPECIFIC OBJECT. Not just that they are logged in. Check ownership on every query.
This is trivially simple to implement but easily forgotten. API Gateway: Your first line of API security.
Authentication enforcement (reject requests without valid credentials), Rate limiting (prevent abuse and DoS),
Schema validation (reject malformed requests before they reach your application — defence in depth), Logging
(every request logged for security monitoring). But the API Gateway cannot prevent BOLA — it has no
knowledge of which objects belong to which user. That business logic check must happen in the application
layer.

Term / Concept Explanation / Detail

OAuth 2.0 — Complete OAuth 2.0 is an AUTHORISATION framework (not authentication). It allows an
Technical Reference application to obtain limited access to a user's account on another service without
the user sharing their password. Core concepts: Resource Owner: the user who
owns the protected resource. Client: the application requesting access. Resource
Server: the API hosting the protected resource. Authorization Server: the server
issuing access tokens. Scopes: define what access is being requested (read:profile,
write:calendar). Grant Types: Authorization Code (most secure — for web apps with
a server-side component): User authenticates at Authorization Server → receives
short-lived auth code → server-side application exchanges code for access token.
The access token never appears in browser URL or logs. Requires client_secret. PKCE
(Proof Key for Code Exchange) — Authorization Code without client_secret for
mobile/SPA: Client generates code_verifier (random string) and code_challenge
(SHA-256 hash of verifier). Sends code_challenge with auth request. Later sends
code_verifier with token request. Authorization server verifies SHA-
256(code_verifier) == code_challenge. Prevents auth code interception attacks.
Client Credentials: Machine-to-machine (no user involved). Client authenticates with
client_id and client_secret → receives access token for the application's own use
(not on behalf of a user). Device Code: IoT devices and CLIs with limited input
capability. Token security: Access tokens should be short-lived (15 minutes). Refresh
tokens for silent re-authentication. Validate on EVERY request: signature (verify JWT
signature using AS public key), issuer (iss claim = expected Authorization Server),
audience (aud claim = your API), expiry (exp claim > current time). Never accept
tokens with 'alg': 'none' (unsigned — trivially forged).
 JWT Security — Attack JWT (JSON Web Token) structure: [Link] (Base64URL encoded).
Vectors and Defences Header: {'alg': 'RS256', 'typ': 'JWT'}. Payload: {'sub': 'user123', 'iss':
'[Link] 'aud': '[Link] 'exp': 1699999999,
'iat': 1699996399, 'roles': ['user']}. Signature: RSA256(base64UrlEncode(header) + '.'
+ base64UrlEncode(payload), private_key). JWT attacks: Algorithm confusion
(alg:none): Attacker modifies JWT, removes signature, sets 'alg': 'none'. If server
accepts unsigned tokens → any claims accepted. Prevention: always explicitly
specify expected algorithms in JWT library, never accept 'none'. Algorithm confusion
(RS256 to HS256): If server uses public key to verify, attacker changes alg from
RS256 to HS256 and signs with the server's PUBLIC KEY as HMAC secret. Server,
expecting HS256, verifies with the public key — signature validates! Prevention:
always use separate key for HMAC vs RSA — never use an RSA public key as HMAC
secret. Claim modification: decode payload (it's just Base64), modify a claim (roles:
['user'] → roles: ['admin']), re-encode. If server doesn't verify signature → elevated
privileges. Prevention: ALWAYS verify signature. Expired token acceptance: if server
doesn't check 'exp' claim, expired tokens remain valid forever. Prevention: check
'exp' on every request. JWK injection: attacker includes a 'jwk' or 'jku' header
pointing to their own key server. If API validates the key from this URL, attacker can
sign with their own key. Prevention: ignore 'jwk' and 'jku' headers, use only pre-
configured trusted keys.
API Gateway — Security Authentication enforcement: API Gateway validates JWT tokens before forwarding
Functions in Detail to backend. Eliminates the need for every backend service to implement token
validation. Backend assumes all requests from API Gateway are authenticated. Rate
limiting: Per-client (API key or IP): limit requests per second/minute/hour. Per-
endpoint: critical endpoints (login) get stricter limits. Burst limiting: allow short
bursts (10 req/s for 10 seconds) but enforce sustained rate limits (2 req/s average).
Adaptive rate limiting: machine learning-based detection of bot patterns even at low
rates. Return 429 Too Many Requests with Retry-After header. Schema validation:
validate request body against OpenAPI schema before forwarding to backend.
Reject requests with: unexpected fields (prevents mass assignment), invalid data
types (prevents type confusion attacks), missing required fields, values outside
expected range. Logging: log all requests (requestId, timestamp, source IP, method,
path, status code, response time, user identity). Do NOT log: request body
containing passwords or secrets, authentication headers, PII in query parameters.
Forward requestId to backend so end-to-end tracing is possible. WAF integration:
many API gateways integrate WAF rules (OWASP CRS — Core Rule Set) for injection
attack detection.

4.6 Cloud Application Architecture Security

Term / Concept Explanation / Detail
Microservices Security Service identity: Each microservice has a unique identity (SPIFFE SVID — Secure
Architecture Vector ID, expressed as an X.509 certificate or JWT with specific claims). Services
authenticate using their identity when calling other services. Service mesh: Istio or
Linkerd handles service-to-service security automatically: mTLS: auto-provisions
certificates for each service, rotates automatically, enforces mTLS between all mesh-
enrolled services. Traffic management: define which services can communicate with
which (service-level ACLs). Observability: all service-to-service traffic observable
(latency, error rates, traffic volume). Policy enforcement: use OPA (Open Policy
Agent) in the mesh for fine-grained authorisation policy (service A can call service
B's /read endpoints but not /write endpoints). API design for microservices: Internal
APIs (service-to-service): use mTLS for transport, JWT or certificate-based service
identity for authorisation. These should not be exposed to the internet. External
APIs (client-facing): use API gateway as the single entry point. All external traffic
enters through API gateway — never expose internal service endpoints directly.
Circuit breaker pattern: if a downstream service is failing, the circuit breaker 'trips'
and fast-fails requests to it (returning an error or cached response) rather than
 queuing requests and cascading failures. Resilience is a security property —
availability under failure is part of the CIA triad.
Container and Kubernetes Container security in depth: Image security: Use official or verified base images
Security (from Docker Official Images or verified publishers). Minimal base images (Alpine,
Distroless, Scratch) — fewer packages = fewer vulnerabilities. Multi-stage builds: use
full build environment to compile, then copy only the compiled artifact to a minimal
runtime image. Image scanning: scan every image before deployment (Trivy, Grype,
Docker Scout). Block images with CRITICAL CVEs from production deployment. Sign
images (Cosign/Sigstore) and enforce signature verification at deployment (K8s
admission controller). Runtime security: Non-root containers: never run container
processes as root (UID 0). rootless containers prevent container-breakout-to-root
attacks. Read-only root filesystem: mount filesystem as read-only. If attacker writes
malware to filesystem, it disappears when container restarts (ephemeral =
immutable). Drop Linux capabilities: containers start with many default Linux
capabilities. Drop all (--cap-drop=ALL) and add back only what is required (--cap-
add=NET_BIND_SERVICE). Never use --privileged (gives full host access). seccomp
profiles: restrict system calls available to container process (filter system calls not
needed by the application). Kubernetes security: RBAC: define ClusterRoles and
Roles with precise permissions. No wildcards (*) in rules. Separate service accounts
per application (never use default service account). Admission controllers: OPA
Gatekeeper, Kyverno — policy enforcement before resource creation. Network
policies: whitelist pod-to-pod communication (deny all, then allow required paths).
Pod security standards: Baseline or Restricted profiles (prevent privileged pods, host
namespaces, unsafe volume mounts). Etcd encryption: encrypt K8s secrets at rest in
etcd (not just base64 encoded — actually encrypted).
Serverless Security (FaaS) Lambda/Function security: IAM role per function: each Lambda function should
have an IAM role with ONLY the permissions it needs for its specific task. If the
function reads from one S3 bucket and writes to DynamoDB, the role should allow
ONLY s3:GetObject on THAT bucket and dynamodb:PutItem on THAT table. No
admin permissions, ever. Event validation: functions are triggered by events (HTTP
requests, SQS messages, S3 events). Validate and sanitise ALL event data — treat it
as untrusted input. An attacker who can control the event data can inject into your
function. Secrets: never use environment variables for secrets (visible in Lambda
console, potentially logged). Use AWS Secrets Manager or Parameter Store.
Dependency management: Lambda packages include all dependencies — scan them
with SCA. Keep dependencies minimal. Timeout and memory limits: set appropriate
timeout (prevents resource abuse). VPC deployment: place Lambda functions in VPC
with security groups if they need to access VPC resources. Use VPC endpoints for
AWS service access (don't route through internet). Cold start security gap: on cold
start, Lambda initialises from scratch. Security telemetry (EDR agents) may not be
fully active for the duration of a very short function. Compensate with Lambda
Insights, Datadog serverless, or other monitoring. Logging: ALL Lambda invocations
should log to CloudWatch Logs. Log requests, responses (redact sensitive fields), and
errors. Structured logging (JSON) enables better querying.

4.7 Identity and Access Management (IAM) Solutions

Term / Concept Explanation / Detail
Identity Federation Trust model: Service Providers (SPs) trust Identity Providers (IdPs) because: SAML:
Architecture The SP has the IdP's public key (in metadata). The IdP signs assertions with its
private key. SP verifies signature. OIDC: The SP validates the ID token's signature
against the IdP's published JWKS (JSON Web Key Set). The JWKS is fetched from the
IdP's discovery endpoint (.well-known/openid-configuration). Trust establishment:
SAML: Exchange metadata files containing entity IDs, X.509 certificates, and
endpoint URLs. The metadata from each party is configured in the other — a one-
time setup. OIDC: SP registers with IdP (receives client_id and client_secret).
Configures IdP's discovery endpoint URL. Multi-tenant federation: Large enterprises
 may have multiple IdPs (one per business unit or acquired company). Federation
brokers (Okta, Ping, Azure AD B2B) aggregate multiple upstream IdPs and present a
single IdP interface to downstream SPs. JIT (Just-In-Time) provisioning: When a
federated user logs in for the first time, their account is automatically created in the
SP from the attributes in the IdP assertion. No manual account creation. Account
attributes (name, email, department) synced from IdP.
CASB — Technical CASB (Cloud Access Security Broker) sits between enterprise users and cloud
Architecture Deep Dive services. Deployment modes and trade-offs: Forward Proxy (inline proxy): Users'
cloud-bound traffic is intercepted by CASB proxy (typically via PAC file or VPN that
routes cloud traffic to CASB). CASB can inspect and enforce policies in real time.
Challenge: must be on the traffic path — devices not on corporate network (home
workers without VPN) bypass CASB. Requires SSL inspection certificate deployed to
all devices. Reverse Proxy (API proxy): Cloud service's login URL is modified to route
through CASB (e.g., [Link] → [Link]). After
authentication, user's session routes through CASB. Works for unmanaged devices
(BYOD) without a client-side agent. Limited to web-based access (doesn't intercept
desktop application sync). API mode: CASB connects to cloud service APIs directly
(Microsoft Graph API for M365, Box APIs, Salesforce APIs). Scans content already in
the cloud (not inline). Cannot block real-time uploads but can quarantine files after
the fact and apply DLP retrospectively. Best for: scanning existing cloud repositories,
user behaviour analytics in cloud apps. Hybrid: most enterprise deployments use API
+ proxy combination. CASB use cases: Shadow IT discovery: CASB logs all cloud
service access — identify unsanctioned cloud applications (e.g., employees
uploading sensitive files to personal Dropbox). DLP for cloud: scan uploads and
shared files for sensitive content (credit card numbers, SSNs, source code). Threat
protection: detect compromised accounts (login from impossible location — logged
in from London at 9:00am, logged in from Tokyo at 9:05am), anomalous download
volumes (potential data exfiltration). CASB vendors: Microsoft Defender for Cloud
Apps (formerly MCAS), Netskope, Zscaler, Symantec CloudSOC.
Zero Trust Access — Zero Trust: 'Never trust, always verify.' Every access request verified regardless of
Implementation source. ZTA components: Identity: Strong authentication (MFA +
passwordless/phishing-resistant preferred). Continuous authentication (risk signals
evaluated continuously — if risk increases, re-authentication required). Device:
Device health verification before access (MDM enrolment, OS patch level, presence
of EDR agent, disk encryption, no jailbreak/root). ZTNA clients check device posture
at each connection. Network: ZTNA (Zero Trust Network Access) replaces VPN.
Instead of connecting to the entire corporate network, user connects to specific
applications. Brokered access: ZTNA service evaluates identity, device, and context
→ grants access to specific application. No network-level lateral movement (user
only has connectivity to permitted applications, not the entire network segment).
Application: Application-level access control (not network-level). Micro-
segmentation within applications. Data: Data classification drives access controls.
Sensitive data accessible only to users/devices meeting higher security bar. UEBA
(User and Entity Behaviour Analytics): baseline normal user behaviour (typical hours,
typical location, typical data volumes accessed). Alert on anomalies. ZTA maturity
stages (CISA ZTM): Stage 1 (Traditional): Users and groups, multi-factor auth for
remote access. Stage 2 (Advanced): Attribute-based access, limited device
compliance. Stage 3 (Optimal): Continuous validation, dynamic authorisation,
comprehensive logging.

D5 16% of exam CLOUD SECURITY OPERATIONS Build, run, monitor, harden,

respond — the daily practice of cloud security management

5.1 Building and Implementing Physical and Logical Infrastructure

Term / Concept Explanation / Detail
 Hardware Security Module HSM operations lifecycle: Initialisation: HSM is factory-reset, administrator
(HSM) — Operations authentication (M-of-N quorum — requires M out of N total administrators to
authenticate — prevents single person from compromising HSM). Master Key
generation inside HSM using TRNG (True Random Number Generator — hardware-
based, not PRNG). Backup: HSM state can be backed up (encrypted with master
backup key). Backup stored in secure offline storage. Backup is encrypted — safe
from theft but must be protected from loss. Recovery: restore from backup onto
replacement HSM. Key ceremony: Critical key generation events (CA root key
generation, master HSM initialisation) conducted as a formal ceremony with
multiple witnesses, documented steps, video recording, and independent
verification. HSM network security: Cloud HSMs are accessible over TLS from
authorised network segments. Security groups restrict access to HSM to only
required IP ranges (application servers that need cryptographic operations).
Monitor: all operations logged. Alert on: failed authentication attempts, key import
events, policy changes. HSM Clustering: multiple HSMs clustered for high
availability. Keys replicated across cluster members (encrypted). If one HSM fails,
others serve operations. AWS CloudHSM clusters: minimum 2 HSMs in different AZs
for HA.
TPM — Use Cases and TPM (Trusted Platform Module) — an international standard (ISO/IEC 11889) for a
Security secure cryptoprocessor, specified by the Trusted Computing Group (TCG). Related
NIST guidance on platform integrity includes SP 800-147 (BIOS Protection
Guidelines), SP 800-155 (BIOS Integrity Measurement Guidelines, draft), and SP 800-
193 (Platform Firmware Resiliency Guidelines). Primary security functions: Measured
Boot (UEFI Secure Boot with TPM measurement): Each boot stage measures
(hashes) the next stage before loading it. Measurements stored in PCR (Platform
Configuration Registers) — tamper-evident registers in TPM. Remote Attestation:
TPM signs PCR values with endorsement key → relying party can verify that the
system booted into a known-good state. Cloud use: confidential VMs use virtual
TPM (vTPM) — software emulation of TPM that provides same interface. Azure
Confidential VMs use vTPM for VM attestation. Disk encryption with TPM: BitLocker
(Windows) uses TPM to seal disk encryption key to PCR values. Key is only released
when system boots into correct known-good state (measured by TPM). If boot state
changes (attacker modifies bootloader), TPM refuses to release key — disk remains
encrypted. Preventing cold boot attacks: if attacker removes disk and boots from
external device, TPM in original machine won't be present → encryption key not
released.
Hypervisor Security VMware ESXi hardening: Apply VMware vSphere Security Configuration Guide.
Configuration Specific settings: Disable SSH access to ESXi hosts (use vCenter for management).
Enable host-based firewall. Lock down DCUI (Direct Console User Interface) access.
Enable secure boot for ESXi. Configure NTP (time synchronisation — required for log
integrity and certificate validation). Disable unnecessary services (CIM server, SNMP
if not used). Enable log shipping to centralised syslog server. Network isolation:
Management network on dedicated VLAN with access controls. VM network on
separate VLANs with no route to management network. Storage network isolated.
Disable MAC spoofing, forged transmits, and promiscuous mode on virtual switches.
Host profiles: VMware Host Profiles enforce consistent configuration across all ESXi
hosts. Alert on configuration drift. AWS Nitro System: AWS's custom hypervisor
architecture. Key security feature: Nitro card handles all I/O (networking, storage) in
dedicated hardware — the hypervisor itself does almost nothing (thin hypervisor).
The reduced hypervisor attack surface means fewer vulnerabilities. Nitro Enclaves:
Isolated CPU and memory partitions for processing highly sensitive data. No
persistent storage, no network connectivity (except a local secure channel to the
parent instance). Cannot be accessed even by operators of the EC2 host.

5.2 Cloud Infrastructure Hardening — Technical Reference

FEYNMAN EXPLANATION | CIS Benchmarks — The Standard Reference for Cloud Hardening
The Centre for Internet Security (CIS) publishes detailed hardening guides called CIS Benchmarks for every major
operating system, cloud platform, database, and application. These are THE reference documents for system
hardening in the CCSP context. CIS Benchmarks are developed through a consensus process involving security
experts, vendors, and practitioners. Each recommendation includes: the rationale (why this matters), the audit
procedure (how to check compliance), and the remediation procedure (how to fix non-compliance). CIS
Benchmark Level 1 recommendations are 'sensible default security' — they should not significantly impact
normal operations or functionality. Level 2 recommendations are for high-security environments where the
additional security is worth potential operational trade-offs. For cloud: CIS Amazon Web Services Foundations
Benchmark (checks IAM, logging, networking, monitoring). CIS Microsoft Azure Foundations Benchmark. CIS
Google Cloud Platform Foundations Benchmark. CIS Docker Benchmark. CIS Kubernetes Benchmark. In practice:
use AWS Security Hub to continuously evaluate your AWS environment against CIS AWS Foundations
Benchmark. Failed checks become findings with severity ratings and remediation guidance. Target: no CRITICAL
findings; LOW findings documented with accepted risk.

Term / Concept Explanation / Detail

OS Hardening Checklist Minimal installation: install ONLY required packages and services. Every installed
package is attack surface. Remove: unnecessary compilers, development tools, X
Window System (on servers), FTP servers, Telnet servers, finger, rsh, rlogin, rcp
(replaced by SSH). Account management: Remove or disable all unnecessary default
accounts (guest, lp, news, games). Lock system accounts (nologin shell). Require
strong passwords. Set password expiration. File permissions: Set correct permissions
on sensitive files: /etc/passwd (644), /etc/shadow (000 or 640), /etc/group (644).
Set sticky bit on world-writable directories (/tmp). Find SUID/SGID files and remove
unnecessary ones. Network hardening: Disable IPv6 if not used. Configure host-
based firewall (firewalld/iptables/nftables on Linux, Windows Firewall). Block ICMP
redirects. Enable TCP SYN cookies (SYN flood protection). Disable source routing.
Enable RPF (Reverse Path Filtering). Audit logging: Enable auditd (Linux audit
framework). Configure rules: log all privileged command execution (sudo, su), log all
authentication events, log file access to sensitive files (/etc/shadow, /etc/sudoers).
Patch management: Subscribe to vendor security advisories. Test patches in staging.
Deploy using configuration management (Ansible, Puppet, Chef, SaltStack) —
consistent, documented, auditable. Measure: patch coverage percentage and time-
to-patch metrics.
Remote Access Security — Bastion Host (Jump Server) Architecture: Single hardened server as the ONLY
Technical Detail authorised entry point for administrative access. Architecture: Admin workstation →
MFA → Bastion host → (SSH/RDP) → Internal server. Bastion host hardening:
Minimal OS, only SSH service enabled, fail2ban (auto-block IPs with repeated failed
logins), AllowUsers whitelist (only specific accounts can SSH to bastion),
ForceCommand (restrict what commands can be run), session recording
(terminalised video recording of all sessions — Teleport, CyberArk). Network access:
Security group allows SSH (22) only from corporate IP range to bastion. Internal
servers allow SSH only from bastion security group — never from internet. AWS
Systems Manager Session Manager: Eliminates bastion host requirement. Admin
authenticates via IAM (MFA) → SSM opens interactive shell to EC2 instance over
SSM API (HTTPS/443). No SSH ports (22) required. No SSH keys to manage. All
sessions logged to CloudWatch Logs and S3. Session recording available. RBAC for
session access via IAM policies. PAM (Privileged Access Management): Full
enterprise PAM solution (CyberArk, BeyondTrust Privileged Remote Access,
Delinea). Capabilities: Credential vaulting (admin never sees the root password —
PAM injects it), Session recording (video and keystroke recording of all privileged
sessions), Just-in-time access (provision elevated permissions for specific task, auto-
revoke), Approval workflows (all privileged access requires approval from a manager
or security team), Session analytics (detect anomalous behaviours in privileged
sessions using ML).
Patch Management — Patch prioritisation framework: CVSS Base Score: 9.0-10.0 (Critical) → 24-48 hours.
Process and Metrics 7.0-8.9 (High) → 7 days. 4.0-6.9 (Medium) → 30 days. 0.1-3.9 (Low) → 90 days. EPSS
 (Exploit Prediction Scoring System): probability score (0-1) that a CVE will be
exploited in the next 30 days. Use EPSS alongside CVSS: a CVSS Medium with high
EPSS may be more urgent than a CVSS High with low EPSS (because CVSS is based on
theoretical impact, not actual exploitation likelihood). CISA KEV (Known Exploited
Vulnerabilities catalogue): CVEs with confirmed exploitation in the wild. KEV CVEs
get immediate priority regardless of CVSS score. Patching process: CVE identified →
Assess applicability (is this package installed in our environment?) → Assess risk
(CVSS, EPSS, KEV) → Test patch in staging (verify application continues to function)
→ Deploy to production (blue/green or rolling update) → Verify patch applied →
Close ticket. Immutable infrastructure: instead of patching, rebuild from base image
with updated packages. Eliminate the patching process for stateless services —
replace instances rather than patching. Patch SLA compliance metric: percentage of
critical vulnerabilities remediated within SLA. Target: 100% for Critical and High.
Report monthly to CISO.
IaC Security — Technical Terraform security: tfsec: open-source static analyser for Terraform. Checks:
Implementation unencrypted storage, public access enabled, missing logging, overly permissive IAM,
insecure network rules. Integrate in CI/CD: tfsec --format sarif → upload to GitHub
Advanced Security → findings appear in pull request. Checkov: multi-framework
(Terraform, CloudFormation, ARM, K8s, Docker). 2,000+ built-in policies. Custom
policies in Python or YAML. Open source. cfn-nag: CloudFormation specific. ARM
TTK: Azure Resource Manager Template Toolkit. KICS (Keeping Infrastructure as
Code Secure): Checkmarx's open-source IaC scanner. Policy as code with OPA (Open
Policy Agent): Define security policies in Rego language. OPA can enforce policies in
CI/CD (pre-deployment check), Kubernetes admission controller (prevent non-
compliant resource creation), API authorisation (fine-grained access control
decisions). Example Rego policy: 'Deny any Terraform plan that includes an S3
bucket without server-side encryption enabled.' This policy is code — versioned,
reviewed, tested, automatically enforced. Drift detection: after applying IaC,
continuously compare deployed infrastructure state against IaC definition. Alert on
drift (manual changes outside IaC process). AWS Config + CloudFormation drift
detection. Terraform state monitoring.

5.3 Operational Controls — ITIL and Cloud Service Management

FEYNMAN EXPLANATION | ITIL v4 — Value Creation in Cloud Service Management
ITIL (Information Technology Infrastructure Library) v4 is the dominant framework for IT Service Management.
Its core principle is co-creating value between service providers and consumers. For cloud security
professionals, ITIL provides the operational processes that ensure cloud services are managed securely and
reliably. The four dimensions of ITIL v4: Organisations and People (who does what — roles, responsibilities,
culture), Information and Technology (tools, data, information required), Partners and Suppliers (CSP
relationships, SLA management), Value Streams and Processes (how work is done). The Service Value System
(SVS): everything that contributes to service value creation. The Service Value Chain (SVC): six activities from
demand to value — Plan, Improve, Engage, Design and Transition, Obtain and Build, Deliver and Support. For
the CCSP exam, the most frequently tested ITIL processes are Incident Management vs Problem Management
(commonly confused) and Change Management (particularly the types of changes and the CAB). Know these
cold.

Term / Concept Explanation / Detail

Incident Management — Goal: RESTORE SERVICE AS QUICKLY AS POSSIBLE. A workaround is acceptable. Root
Technical Process cause analysis is NOT the goal of incident management — that is Problem
Management's job. Incident prioritisation: Priority = Urgency × Impact. Urgency:
how quickly must this be resolved? (business criticality, user count affected,
regulatory deadline). Impact: what is the business impact? (revenue loss per minute,
regulatory exposure, customer count affected, data at risk). P1 (Critical): Service
completely unavailable or major data breach. Immediate response. Dedicated
 bridge/war room. Executive communication within 30 minutes. Status updates every
15-30 minutes. P2 (High): Major service degradation or significant functionality lost.
Response within 1 hour. Status updates every 1 hour. P3 (Medium): Minor
functionality affected, workaround available. Response within 4-8 hours. P4 (Low):
Cosmetic issue or low-impact functionality affected. Response within 24-72 hours.
Incident response steps: Detection (monitoring alert, user report) → Logging (create
ticket, document symptoms) → Classification and prioritisation → Initial diagnosis
(check status dashboards, recent changes) → Escalation if needed (Tier 1 → Tier 2 →
Tier 3 → vendor) → Resolution (apply fix or workaround) → Recovery verification
(confirm service restored) → Closure (document timeline, update CMDB). Major
Incident Management: P1 incidents get a dedicated Major Incident Manager
(coordinator) separate from the technical resolving team. Coordinators manage
communication; technical team focuses on resolution.
Problem Management — Goal: FIND AND ELIMINATE ROOT CAUSE. Problems are the underlying cause of one
Root Cause Analysis or more incidents. Problem types: Reactive problem management (triggered after
Techniques incidents occur — investigate incidents to prevent recurrence), Proactive problem
management (analyse trends in incident data to find problems before they cause
significant incidents — look for patterns in low-severity incidents). Root Cause
Analysis (RCA) techniques: 5 Whys: Ask 'why?' five times. Why was the service
unavailable? Because the database was unresponsive. Why was the database
unresponsive? Because a runaway query was consuming all CPU. Why was there a
runaway query? Because a new feature deployed without query performance
testing. Why was query performance not tested? Because the testing process
doesn't include performance testing. Why is performance testing not included?
Because the development manager doesn't believe it is necessary. Root cause:
management process failure. Fishbone (Ishikawa) Diagram: Visualise all possible
contributing factors (People, Process, Environment, Materials, Methods, Machines)
and their relationships. Fault Tree Analysis (FTA): Top-down: start with the failure
event, work down to basic events that could cause it. AND gates and OR gates.
Quantify probability. Timeline Analysis: Document the sequence of events leading to
the incident — find the critical causal events. Kepner-Tregoe method: systematic
problem analysis (define problem, describe what is/is not happening, analyse
distinctive characteristics, test hypotheses). Problem output: Known Error record
(documented problem with known root cause and workaround). KEDB (Known Error
Database): searchable record of all known errors — service desk can quickly identify
and apply workaround when same incident recurs. Permanent fix: the solution that
eliminates the root cause — goes through Change Management.
Change Management — Types of changes: Standard change: Pre-approved, low risk, low impact, frequently
Types and Process occurring changes. Follows a documented procedure. No CAB review required.
Examples: monthly OS patches (previously tested procedure), adding a user account,
restoring a backup using documented procedure. Normal change: requires CAB
(Change Advisory Board) assessment and approval. CAB composition: Change
Manager (chair), technical subject matter experts relevant to the change, business
representatives, security, risk management. Normal change process: RFC (Request
for Change) submitted → Impact assessment (who is affected? what could go
wrong?) → Risk assessment (probability and severity of adverse outcome) → CAB
review → Approval (or rejection with feedback) → Schedule → Implement → Verify
→ Review. Emergency change: unexpected urgent change required to prevent or
recover from major incident. ECAB (Emergency Change Advisory Board): smaller
subset of CAB that can be convened quickly. Can approve emergency changes
verbally with formal documentation done post-implementation. Still requires
rollback plan. Higher risk than normal changes due to reduced testing and review.
Change records: ALL changes recorded in CMDB (Configuration Management
Database). Change freeze: periods when changes are prohibited or require escalated
approval (Christmas/holiday trading period, year-end financial close, major business
events). CAB should be consulted about freeze windows well in advance.
Service Level Management SLA (Service Level Agreement): Formal agreement between IT service provider and
customer defining: service hours (24/7 or business hours only), availability target
 (99.9%), performance targets (response time <500ms at 95th percentile), support
response time (P1: 15 minutes initial response; P2: 1 hour), change notification
period, reporting schedule. OLA (Operational Level Agreement): Agreement
between internal IT teams supporting each other. Less formal than SLA. Supports
the SLA. Example: Database team OLA: database restore within 4 hours. This OLA
supports an SLA commitment of service recovery within 8 hours. UC (Underpinning
Contract): External contracts with vendors and CSPs that underpin the service
provider's SLA with customers. AWS SLA for EC2: 99.99% per region. AWS is a UC
that underpins the IT department's SLA. SLA monitoring: measure actual
performance against SLA targets. Monthly SLA reports. Financial penalty triggers
(credits or service refunds for SLA breach). Service Improvement Plan (SIP): when
SLA is repeatedly breached, initiate formal improvement plan with root cause
analysis, corrective actions, and progress tracking.

5.4 Digital Forensics in Cloud — Technical Reference

Term / Concept Explanation / Detail
Evidence Types and Collection Electronic evidence types: Volatile evidence (lost when power removed): running
in Cloud processes, network connections, memory contents, logged-in users, system uptime,
command history in memory. Must capture FIRST and IMMEDIATELY. Non-volatile
evidence (persistent): disk files, logs, configuration files, databases, email. Can be
collected over longer timeframe. Order of volatility (collect most volatile first): CPU
registers and cache → RAM (running processes, network state) → Swap space →
Running disk → Temporary file systems → Remote logging data → Archived media.
Cloud volatile evidence collection: Memory dump of running VM: take snapshot →
export snapshot → analyse offline (Volatility Framework for memory forensics).
Running process list (from AWS Systems Manager: ssm-agent commands to list
processes). Network connections at time of incident (VPC Flow Logs going
backwards — review logs already captured). Non-volatile evidence collection: VM
snapshot: AWS EC2 CreateSnapshot API. Snapshot captures disk state at that
moment. Export snapshot to S3 for offline forensic analysis. Log extraction:
CloudTrail, VPC Flow Logs, CloudWatch Logs, S3 Access Logs, Application logs —
download and hash. Database export: export database tables relevant to the
incident (preserve transaction logs if possible for timeline reconstruction). Container
forensics: if container has already been destroyed, forensics depends entirely on
what was logged before destruction. Container image can be analysed for
vulnerabilities and backdoors even after container termination.
Forensic Tools and Cloud Memory forensics: Volatility Framework: open-source, supports Windows and Linux
Integration memory images. Plugins: pslist/pstree (process list), netscan (network connections),
cmdline (command line arguments), dumpfiles (extract files from memory), hivelist
(Windows registry hives), hashdump (extract password hashes). Disk forensics:
Autopsy (open-source digital forensics platform). Sleuth Kit (underlying tool). EnCase
and FTK (commercial). Cloud-aware forensics: AWS supports acquiring evidence
through the console and APIs. CloudTrail Insights: automatically detects unusual API
activity patterns (e.g., unusual number of API calls in a short period). AWS Detective:
automatically builds a graph model of your environment using VPC Flow Logs,
CloudTrail, and GuardDuty findings. Enables interactive investigation without
manual log correlation. Azure Sentinel: SIEM with built-in incident investigation
workflows. Entity behaviour analytics. Investigation graph. Log preservation for legal
proceedings: Export logs to S3 with Object Lock (Compliance mode). Obtain
cryptographic hash of all exported logs. Store hash separately (in a different, highly
controlled system). These steps create a forensically sound evidence package.
Legal and Regulatory Evidence admissibility requirements: Authenticity: the evidence is what it purports
Framework for Cloud to be. Demonstrated by: unbroken chain of custody, cryptographic hash verification
Forensics (hash on collection matched hash when presented in court). Integrity: the evidence
has not been modified since collection. Demonstrated by: hash comparison (SHA-
256 hash on collection matches current hash), write-blocker used during collection
 (prevents any writes to original evidence). Reliability: the collection method is sound
and consistent. Demonstrated by: documented forensic procedure, qualified
examiner. Relevance: the evidence is material to the case. Demonstrated by:
connect the evidence to the incident under investigation. Cloud-specific legal
considerations: Stored Communications Act (SCA), 18 U.S.C. §2703 (USA):
Government must use legal process (court order or subpoena) to obtain content of
communications stored by a cloud service provider. The standard varies by age and
type of data. CLOUD Act (2018): Allows U.S. government to compel U.S.-based CSPs
to produce data regardless of where it is physically stored. Creates conflict with
GDPR when data is in Europe. MLATs (Mutual Legal Assistance Treaties): Process for
international evidence requests. Can take months or years. Not suitable for
emergency evidence collection. Preservation orders: before obtaining legal process,
government can issue an emergency preservation demand requiring CSP to preserve
evidence immediately while legal process is obtained (18 U.S.C. §2703(f)). Data
retained for 90 days (renewable).

5.5 Security Operations — Comprehensive Reference

Term / Concept Explanation / Detail
SOC Functions and Maturity SOC Tier Model: Tier 1 (Triage Analyst): Monitor SIEM alerts. Initial triage — is this a
true positive or false positive? Apply runbook procedures for known incident types.
Escalate true positives to Tier 2. Close false positives with documentation. KPIs: Alert
volume handled per analyst, false positive rate, escalation accuracy, time-to-triage.
Tier 2 (Incident Analyst): Deep investigation of escalated incidents. Containment
actions (isolate affected hosts, revoke compromised credentials). Forensic analysis
of evidence collected from affected systems. Post-incident analysis. KPIs: MTTD
(Mean Time To Detect), MTTR (Mean Time To Respond), incident containment rate.
Tier 3 (Threat Hunter / Advanced Analyst): Proactive threat hunting — search for
evidence of undetected breaches. Malware reverse engineering. Advanced
forensics. Threat intelligence analysis. Develop new detection rules based on threat
intelligence and hunting findings. Red team activities. Develop content for SIEM
(detection rules, playbooks). KPIs: Threats identified before alert fired, SIEM rule
quality (true positive rate of created rules). SOC Operational Models: In-house SOC:
highest visibility, high cost (24/7 staffing is expensive), all institutional knowledge
retained. MSSP (Managed Security Service Provider): lower cost, immediate access
to experienced analysts, 24/7 coverage without staffing overhead. Risks: less
context about your specific environment, potential access by third party to sensitive
security data. Co-managed SOC: customer SOC for Tier 3, MSSP for Tier 1/2.
Threat Hunting — Threat hunting assumptions: Assume breach — some attackers have already
Methodology and Techniques bypassed perimeter defences and are inside the environment undetected. The
question is not 'have we been breached?' but 'where are the attackers that our
automated tools haven't found yet?' Threat hunting process: Form hypothesis (e.g.,
'Based on recent threat intelligence about APT29's TTPs, they may be using living-
off-the-land techniques in our environment — executing malicious PowerShell via
LOLBins'). Define search (which data sources, what queries will test this hypothesis).
Execute search (query SIEM, EDR, network logs for the specific indicators or
behavioural patterns). Analyse results (separate noise from signal — benign matches
vs suspicious). Investigate anomalies (deep dive on suspicious findings). Escalate if
compromise found (trigger incident response). Document and improve (record what
was found or not found, update detection rules to automate detection of similar
future activity). Threat hunting data sources: Process execution logs (Sysmon
EventID 1, Windows Security 4688, eBPF on Linux), Network connections (Zeek/Bro
network logs, VPC Flow Logs, DNS query logs), Authentication events (EventID
4624/4625, CloudTrail), File system changes (FIM — File Integrity Monitoring), Cloud
API calls (CloudTrail — look for unusual API patterns). MITRE ATT&CK: Adversarial
Tactics, Techniques and Common Knowledge. Comprehensive knowledge base of
adversary behaviours categorised by tactic (Reconnaissance, Initial Access,
 Execution, Persistence, Privilege Escalation, Defence Evasion, Credential Access,
Discovery, Lateral Movement, Collection, C2, Exfiltration, Impact). Use ATT&CK to:
guide threat hunt hypotheses (hunt for specific TTPs), build SIEM detection rules
(alert on ATT&CK techniques), evaluate SOC coverage (which ATT&CK techniques
are we detecting?).
SIEM and SOAR — Technical SIEM correlation rules — examples: Brute force → success correlation: IF (>10 failed
Configuration logins from IP X within 5 minutes) AND (successful login from IP X within 10 minutes
after failure spike) → ALERT. Impossible travel: IF (login from Location A) AND (login
from Location B within 1 hour) AND (travel time A→B > 1 hour) → ALERT (potential
account compromise or shared credential). Lateral movement detection: IF (new
authentication to host Y using credentials of user Z) AND (user Z has not previously
authenticated to host Y) AND (authentication happened after business hours) →
ALERT. Data exfiltration indicator: IF (database query returning >100,000 rows by
user with no prior large query history) AND (within 1 hour, network upload >500MB
from same source IP) → ALERT. False positive reduction: SIEM rules must be tuned
to reduce false positive rate. Techniques: Allowlisting (exclude known-good service
accounts, known maintenance windows, known-high-volume processes from certain
alerts), Context enrichment (add asset owner, criticality, department information to
alerts to help triage), Machine learning baseline (ML establishes normal behaviour
and only alerts on statistically significant deviations). SOAR Playbooks for cloud:
Phishing response: Alert fires (suspicious email with malicious attachment) → SOAR
automatically: queries URL/attachment hash in threat intel feeds (VirusTotal,
Recorded Future), detonates attachment in sandbox ([Link], CrowdStrike
Sandbox), IF malicious: quarantines email across all mailboxes (Microsoft 365 API),
blocks sender domain in email security gateway (API call), creates incident ticket,
notifies user and manager, blocks C2 domain in DNS security gateway. All
automated in minutes. Compromised IAM credentials: CloudTrail alert (anomalous
API calls from new IP/country) → SOAR: verify with user (automated Slack message
'Did you make this API call?'), IF no response in 5 minutes OR user says no: revoke
API keys (IAM API call), disable console access, isolate EC2 instance (change security
group to deny all), snapshot affected instances for forensics, create P1 incident.
Vulnerability Management — Cloud vulnerability scanning: CSP-native: AWS Inspector v2 — continuously scans
Cloud-Specific EC2 instances and Lambda functions for software vulnerabilities (CVEs in installed
packages) and network reachability issues. Results delivered to Security Hub. No
agent needed for EC2 with SSM Agent. Agentless scanning: scan cloud instances
from outside without installing agents. Orca Security, Wiz, Lacework use CSP
snapshot APIs to scan disk images without impacting production performance.
Cloud-native vulnerability management: integrate scanner with CSP APIs to
automatically discover all assets (no static IP list required — cloud environments are
dynamic). Container vulnerability scanning: Trivy, Grype, Docker Scout scan
container images in CI/CD pipelines and container registries. Integrate with CI/CD
pipeline to block deployment of images with critical CVEs. CSPM (Cloud Security
Posture Management): Agentless cloud configuration scanning. Continuously
monitors cloud resource configurations against security best practices and
compliance frameworks. Findings include: unencrypted S3 buckets, overly
permissive IAM, public security groups, missing logging, unrotated access keys.
Tools: Wiz, Prisma Cloud, Orca Security, AWS Security Hub (aggregates findings from
Inspector, Config, GuardDuty, Macie, IAM Access Analyzer). Vulnerability metrics for
reporting: MTTD (Mean Time To Discover): time from when vulnerability was
introduced to when it was detected. MTTR (Mean Time To Remediate): time from
detection to patch applied. Patch SLA compliance: % of vulnerabilities remediated
within defined SLA (CRITICAL: 24h, HIGH: 7d). Risk reduction over time: total CVE risk
score over time — show trend.

D6 13% of exam LEGAL, RISK AND COMPLIANCE Privacy law, regulatory

frameworks, audit standards, risk management, cloud
contracts
6.1 Legal Requirements and Cloud-Unique Legal Risks
FEYNMAN EXPLANATION | The Jurisdictional Complexity of Cloud — A Global Legal Minefield
In the pre-cloud world, data sovereignty was relatively straightforward: your data centre is in your country, your
data is subject to your country's laws. In cloud, data fragments may be simultaneously in Ireland, Virginia,
Singapore, and São Paulo — each subject to different legal regimes. The fundamental tension: cloud's economic
benefits come from resource pooling and geographic distribution. Cloud's legal challenges come from the same
geographic distribution. You cannot fully have both without careful architectural decisions. Three legal regimes
in conflict: (1) GDPR and EU data protection law: requires personal data of EU residents to be protected
wherever it goes. Cross-border transfers to countries without 'adequate' protection require specific safeguards
(SCCs, BCRs, adequacy decisions). (2) U.S. CLOUD Act (2018): U.S. law enforcement can compel U.S. CSPs (AWS,
Microsoft, Google) to produce data stored ANYWHERE in the world — even EU data centres. Directly conflicts
with GDPR. (3) China Cybersecurity Law + Data Security Law + Personal Information Protection Law (PIPL): data
of Chinese citizens must be stored in China. Critical data must undergo security assessments before export.
Extraterritorial reach for data affecting Chinese national security or interests. Practical resolution strategies:
Data residency enforcement (use CSP region controls to pin data to specific countries — AWS data residency
commitments guarantee data does not leave the selected region without explicit customer action), Legal
counsel in each jurisdiction (necessary for multinationals — local counsel advises on local law and conflict
resolution), Privacy-enhancing technologies (encryption, anonymisation — even if data is legally demanded,
encrypted data without the key is of limited use), Contractual protections (require CSP notification before
complying with government demands, contest overreaching demands — Microsoft, Google, Apple have done
this).

Term / Concept Explanation / Detail

Computer Crime Laws Computer crime law varies dramatically by jurisdiction: United States: Computer
Fraud and Abuse Act (CFAA): prohibits unauthorised access to computers. Very
broadly written — has been used against security researchers. Pen testers MUST
have written authorisation from the asset owner or they risk CFAA prosecution.
Electronic Communications Privacy Act (ECPA): Stored Communications Act and
Wiretap Act provisions. EU: Directive 2013/40/EU on attacks against information
systems: harmonises computer crime law across EU member states. Defines: illegal
access, illegal system interference, illegal data interference, illegal interception. UK:
Computer Misuse Act 1990 (amended): unauthorised access, authorised access with
intent to commit further offences, unauthorised modification of computer material.
Singapore: Computer Misuse Act: similar provisions. Key exam point: unauthorised
computer access is a crime in virtually every jurisdiction. Security professionals
MUST have written authorisation for any penetration testing, vulnerability scanning,
or system access that is not explicitly permitted by system ownership. 'But I found a
vulnerability' is not a defence — unauthorised access is the offence.
eDiscovery — Technical and eDiscovery (Electronic Discovery): the process of identifying, preserving, collecting,
Legal Framework processing, reviewing, and producing electronically stored information (ESI) in
response to legal proceedings. The EDRM (Electronic Discovery Reference Model): a
commonly used framework for eDiscovery. Steps: Information Governance →
Identification → Preservation → Collection → Processing → Review → Analysis →
Production → Presentation. Identification: identify relevant data custodians
(employees with relevant data) and data sources (email, files, databases, cloud
applications, instant messaging). Cloud complication: data may be in multiple CSP
services across multiple regions. Collection: forensically sound collection with hash
verification and chain of custody. Cloud collection: work with CSP through legal
process (subpoena, court order, or voluntary assistance). Some CSPs have legal
response portals. ISO/IEC 27050: Information technology — Electronic discovery.
Four parts covering overview, guidance for governance, code of practice, readiness.
Cloud eDiscovery tools: Microsoft Purview eDiscovery, Relativity, Nuix. Legal hold:
triggered when litigation is 'reasonably anticipated.' All automatic
 retention/deletion processes halted for relevant data. Technical implementation:
email hold (Microsoft 365 Litigation Hold), file hold (SharePoint Compliance), cloud
storage hold (S3 Object Lock Compliance mode). Spoliation: destruction of relevant
evidence. Consequences: adverse inference instruction (judge tells jury destroyed
evidence was damaging), monetary sanctions, case dismissal, criminal contempt.
Cloud spoliation risk: automated log retention policies that delete logs before
discovery request. Mitigation: audit automated deletion jobs, ensure legal hold
capabilities exist for all data sources before litigation arises.
Forensics Requirements for For digital evidence to be admissible in court, it must meet standards that vary by
Legal Proceedings jurisdiction but generally include: Authenticity: the evidence is what it is claimed to
be. Demonstrated by: chain of custody documentation, cryptographic hash
verification, testimony of qualified examiner. Integrity: evidence has not been
modified since collection. Demonstrated by: hash verification (SHA-256 of original
matches current hash), write-blocking during collection (hardware write blocker for
physical media; for cloud: read-only API access or snapshot-based collection
prevents modification), documented unbroken chain of custody. Reliability: the
method of collection is repeatable and scientifically sound. Demonstrated by:
documented forensic procedure, use of validated forensic tools, qualified examiner
with documented expertise. Relevance: the evidence is material to the case. Legal
authentication requirements (U.S. Federal Rules of Evidence 901): testimony by a
witness with knowledge, or through certifications for self-authenticating documents.
Business records exception (FRE 803(6)): records kept in the regular course of
business, created at or near the time of the event, by someone with knowledge.
Cloud logs typically qualify if: logs are a standard business practice (CloudTrail
enabled for all API calls), logs are created contemporaneously (real-time), logs are
stored in tamper-evident manner (Object Lock, hash signing). Expert witness
requirements: forensic examiner may need to testify about collection method and
analysis. Certifications relevant to credibility: EnCE (EnCase Certified Examiner),
GCFE (GIAC Certified Forensics Examiner), CCE (Certified Computer Examiner), CCFE
(Certified Cyber Forensics Professional).

6.2 Privacy Regulations — Deep Technical Coverage

FEYNMAN EXPLANATION | GDPR — The Most Comprehensive Privacy Framework in Force
GDPR (EU 2016/679) came into force on 25 May 2018 and fundamentally changed how organisations worldwide
handle personal data. Its extraterritorial scope means that a company anywhere in the world processing
personal data of EU residents must comply. The core principle: individuals have rights over their personal data.
Organisations processing that data must have a lawful basis, must be transparent, must minimise data
collection, must secure the data, and must enable individuals to exercise their rights. Lawful basis is the
foundation of GDPR compliance. You must have a lawful basis for EVERY processing activity. The six lawful bases
(GDPR Article 6): Consent (freely given, specific, informed, unambiguous indication of agreement — not pre-
ticked boxes, not bundled with other terms, withdrawable at any time without detriment), Contract (processing
necessary for performance of a contract with the data subject), Legal obligation (processing required to comply
with a law), Vital interests (processing necessary to protect life — narrow, cannot be used when another basis
applies), Public task (processing by public authority in exercise of official authority), Legitimate interests (the
organisation's interests outweigh the data subject's privacy interests — requires balancing test, cannot override
fundamental rights — CANNOT be used by public authorities). Special categories of data (GDPR Article 9): Racial
or ethnic origin, Political opinions, Religious or philosophical beliefs, Trade union membership, Genetic data,
Biometric data (for identification), Health data, Sex life or sexual orientation data. Processing special category
data requires BOTH a lawful basis under Article 6 AND an additional condition under Article 9 (explicit consent,
employment law, vital interests, legitimate activities of not-for-profit organisations with political/religious/etc.
aim, clearly made public by data subject, legal claims, substantial public interest, medical purposes, public
health, archiving/research/statistics).

Term / Concept Explanation / Detail

GDPR — Eight Data Subject Right to be Informed (Articles 13-14): Data subjects must be informed at point of
Rights collection (if data collected directly) or within 1 month (if data obtained from
another source) about: who is the controller, what data is processed, why it is
processed (purpose), the lawful basis, data retention periods, who data is shared
with, whether data is transferred outside EEA, the data subject's rights, the right to
withdraw consent, the right to complain to a supervisory authority, whether
decision-making is automated (including profiling). Right of Access (Article 15): Data
subjects can request confirmation of whether their data is processed, and if so, a
copy of the data and supplementary information. Must be provided within 1 month
(extendable to 3 months for complex requests). Free of charge for first request.
Right to Rectification (Article 16): Data subjects can request correction of inaccurate
personal data and completion of incomplete personal data. Respond within 1
month. Right to Erasure / 'Right to be Forgotten' (Article 17): Data subjects can
request deletion when: data is no longer necessary for the original purpose, consent
is withdrawn (and no other lawful basis), data subject objects and there are no
overriding legitimate grounds, data was unlawfully processed, legal obligation
requires erasure. Exceptions: freedom of expression, legal obligation to retain,
public health, archiving/research purposes, legal claims. Right to Restrict Processing
(Article 18): Data subject can ask you to 'freeze' processing: while accuracy of data is
contested, when processing is unlawful but data subject prefers restriction over
erasure, when you no longer need the data but data subject needs it for legal claims.
During restriction: you can store data but not process it. Right to Data Portability
(Article 20): Data subjects can receive their data in a structured, commonly used,
machine-readable format (JSON, CSV) and have it transmitted to another controller.
Applies to: data provided by the data subject, processed based on consent or
contract, processed by automated means. Right to Object (Article 21): Data subjects
can object to processing based on legitimate interests or public task (including
profiling). Must stop processing unless compelling legitimate grounds that override
the data subject's interests exist. Absolute right to object to processing for direct
marketing (no legitimate grounds override). Right Not to be Subject to Automated
Decision-Making (Article 22): Data subjects have the right not to be subject to
decisions based solely on automated processing (including profiling) that produce
legal or similarly significant effects. Exceptions: contract necessity, legal
authorisation, explicit consent. If exception applies: must implement safeguards
(right to obtain human intervention, express a point of view, contest the decision).
GDPR — Controller, Data Controller (Article 4(7)): Determines the purposes and means of processing.
Processor, Sub-Processor Primary responsibility for GDPR compliance. Appoints processors contractually.
Relationships Bears responsibility for ensuring processors are compliant. Example: your company
decides to use a CRM to manage customer data — your company is the controller.
Data Processor (Article 4(8)): Processes personal data on behalf of the controller.
Must only process as instructed by the controller. Cannot engage sub-processors
without controller's authorisation. Must assist controller with: security, breach
notification, DPIAs, data subject rights. Must delete or return data at end of service.
Must provide all information necessary for controller to demonstrate compliance.
Example: Salesforce processes your customer data as instructed by you —
Salesforce is a processor. Sub-Processor: Processor used by the processor (with
controller's authorisation). Must be bound by same obligations as the processor.
Example: Salesforce uses AWS to host its infrastructure — AWS is a sub-processor
relative to your relationship with Salesforce. DPA (Data Processing Agreement)
requirements (Article 28): The contract between controller and processor must
include: subject matter and duration, nature and purpose, type of personal data and
categories of data subjects, rights and obligations of controller, processor's
obligations (process only on instructions, confidentiality, security, sub-processor
management, assist with compliance, delete at end). Standard Contractual Clauses
(SCCs): The European Commission has published model DPAs for different scenarios
(controller-processor). Using SCCs ensures the DPA meets Article 28 requirements.
GDPR — Data Protection DPO appointment is mandatory when (Article 37): The controller is a public
Officer (DPO) authority, The core activities involve large-scale systematic monitoring of data
 subjects (e.g., social media company, CCTV operator), The core activities involve
large-scale processing of special categories data (e.g., healthcare provider, insurance
company). DPO requirements: must have expert knowledge of data protection law
and practices, must be independent (cannot be given instructions on how to
perform DPO tasks), must report directly to the highest management level, must not
be dismissed or penalised for performing DPO tasks. DPO responsibilities (Article
39): Inform and advise the controller/processor and employees of GDPR obligations,
Monitor compliance (policies, training, audits), Advise on DPIAs and monitor
performance, Cooperate with and act as contact point for the supervisory authority.
DPO can be an external service provider (outsourced DPO). DPO contact details
must be communicated to supervisory authority and published (website).
HIPAA — Technical The HIPAA Security Rule (45 CFR Parts 160 and 164) requires covered entities and
Safeguards in Detail business associates to implement administrative, physical, and technical safeguards
for electronic PHI (ePHI). Technical Safeguards (45 CFR §164.312): Access Control:
Unique user identification (required), Emergency access procedure (required —
break-glass access in emergency), Automatic logoff (addressable — implement
reasonable mechanism), Encryption and decryption (addressable — encrypt/decrypt
ePHI). Audit Controls: Record and examine activity in information systems that
contain ePHI (required). What to log: user access, authentication events, changes to
ePHI, system events. Integrity: Protect ePHI from improper alteration or destruction
(addressable — authenticate ePHI, checksums, hash verification). Transmission
Security: Guard against unauthorised access during transmission (addressable —
encryption of ePHI in transit recommended; NIST guidelines recommend TLS 1.2+).
18 PHI identifiers: Names, Geographic data smaller than state (street address, city,
county, precinct, ZIP code except first 3 digits for populations >20,000), Dates
(except year) related to an individual, Phone numbers, Fax numbers, Electronic mail
addresses, Social security numbers, Medical record numbers, Health plan
beneficiary numbers, Account numbers, Certificate/license numbers, Vehicle
identifiers (serial numbers, license plates), Device identifiers, Web URLs, IP
addresses, Biometric identifiers (fingerprints, voice prints), Full-face photographs,
Any unique identifying number or code. Minimum Necessary Standard: Must make
reasonable efforts to use, disclose, and request only the minimum PHI necessary to
accomplish the intended purpose. HIPAA Breach Notification Rule: Covered entity
must notify: affected individuals 'without unreasonable delay and within 60 days',
HHS Secretary (for breaches affecting 500+ individuals: within 60 days; for smaller
breaches: annual report within 60 days of calendar year end), prominent media
outlets in the state/jurisdiction for breaches affecting 500+ residents.
PCI DSS 4.0.1 — CURRENT VERSION: PCI DSS 4.0.1 (released June 2024 as a limited revision of 4.0
Requirements Technical with clarifications and minor updates). PCI DSS 4.0 was published March 2022; PCI
Detail DSS 3.2.1 was retired on March 31, 2024. PCI DSS 4.0 introduced 64 new
requirements; 51 were 'future-dated' (designated 'best practice' until March 31,
2025, after which they became mandatory and assessed during PCI DSS
assessments). Two compliance approaches: Defined approach (traditional):
implement each requirement as specified. Customised approach (new in 4.0):
demonstrate security objective is achieved through controls of your own design.
Only permitted for organisations with mature risk management programmes. 12
Requirements grouped in 6 control objectives: Build and Maintain a Secure Network
and Systems: Req 1 — Install and maintain network security controls. Req 2 — Apply
secure configurations to all system components. Protect Account Data: Req 3 —
Protect stored account data. Req 4 — Protect cardholder data with strong
cryptography during transmission. Maintain a Vulnerability Management
Programme: Req 5 — Protect all systems and networks from malicious software.
Req 6 — Develop and maintain secure systems and software. Implement Strong
Access Control Measures: Req 7 — Restrict access to system components and
cardholder data by business need. Req 8 — Identify users and authenticate access to
system components. Req 9 — Restrict physical access to cardholder data. Regularly
Monitor and Test Networks: Req 10 — Log and monitor all access to system
components and cardholder data. Req 11 — Test security of systems and networks
 regularly. Maintain an Information Security Policy: Req 12 — Support information
security with organisational policies and programmes. Notable 4.0/4.0.1 changes:
SBOM-style software inventory (Req 6.3.2), authenticated vulnerability scanning
(Req [Link]), expanded MFA requirements (Req 8), payment page script integrity
controls (Reqs 6.4.3 and 11.6.1), Targeted Risk Analyses (TRA) for setting control
frequencies. Scoping: the cardholder data environment (CDE) = all system
components that store, process, or transmit CHD, or that could impact its security.
Connected systems (systems that connect to CDE but don't directly process CHD) are
in scope for relevant requirements. Scope reduction: tokenise CHD before it reaches
most systems (only payment terminal and token vault in scope), network
segmentation (isolated CDE segment with strict firewall rules). Annual validation:
Level 1 merchants (>6M transactions/year) → ROC by QSA. Level 2 (1-6M) → Self-
Assessment Questionnaire (SAQ) by qualified internal assessor. Level 3/4 (<1M) →
SAQ. Quarterly external vulnerability scans by ASV (Approved Scanning Vendor)
required for all levels. Annual penetration testing required.

6.3 Audit Process and Cloud-Specific Adaptations

Term / Concept Explanation / Detail
Audit Types and Objectives Internal audit: Conducted by the organisation's own internal audit function.
Independent of operational management. Reports to audit committee or board.
Objectives: assess effectiveness of internal controls, compliance with policies,
operational efficiency, risk management effectiveness. Cannot self-audit — auditors
must be independent of the function being audited. Cloud internal audit: evaluate
cloud governance framework, IAM controls, patch compliance, security monitoring,
change management, cost management, vendor management. External audit:
Independent third-party audit by external auditors. Provides assurance to external
stakeholders (customers, investors, regulators, insurers). Types: Financial audit
(auditor opinion on financial statements — SOX Section 404 IT general controls are
assessed as part of financial audit), Compliance audit (assess compliance with
specific regulations — HIPAA compliance audit, PCI DSS QSA assessment), Security
audit (assess effectiveness of security controls — SOC 2 examination, penetration
test, red team exercise), IT general controls audit (access management, change
management, backup and recovery, availability — typically part of SOX or SOC
audit). Cloud audit challenges: Cannot physically access CSP infrastructure — rely on
third-party attestations (SOC 2, ISO 27001). Configurations change dynamically —
audit of a point-in-time configuration may not reflect current state. Multi-tenant
environment — auditors cannot test controls on other tenants' data. Ephemeral
resources — VM instances that existed during the audit period may no longer exist.
SOC Reports — Technical SOC 1 (SSAE No. 18 — AT-C Section 320): Focuses on internal controls over financial
Deep Dive reporting (ICFR). Relevant to: payment processors, payroll processors, loan servicing,
healthcare claims processing. Two types: Type 1 (at a point in time — design of
controls), Type 2 (over a period — design AND operating effectiveness). SSAE 18 is
the U.S. standard; ISAE 3402 is the equivalent international standard. SOC 2 (AT-C
Section 205): Covers operational controls relevant to customers in general. Based on
AICPA Trust Services Criteria (TSC). Security criterion (CC): Access to information and
system resources is protected. Contains Common Criteria (CC1-CC9) covering:
control environment (CC1), communications and information (CC2), risk assessment
(CC3), monitoring (CC4), control activities (CC5), logical and physical access (CC6),
system operations (CC7), change management (CC8), risk mitigation (CC9). Optional
criteria: Availability (A1): system available for operation and use as committed.
Processing Integrity (PI1): system processing complete, accurate, timely, authorised.
Confidentiality (C1): information designated as confidential protected as committed.
Privacy (P1-P8): personal information collected, used, retained, disclosed, disposed.
SOC 3: Same examination as SOC 2, but report is simplified and can be publicly
distributed (no NDA required). Contains auditor's opinion and management
assertion but NO testing details. Used for marketing/general assurance. Not
 sufficient for customer due diligence. Reading a SOC 2 Type II report: Start with
auditor's opinion paragraph (clean, qualified, or adverse). Review the description of
the system (understand what IS and IS NOT covered). Review Control environment
and control activities sections. Review test results — look for exceptions noted.
Review Complementary User Entity Controls (CUECs) — what YOU must implement.
Review Complementary Subservice Organisation Controls (CSOCs) — what sub-
processors are relied upon.
Audit Planning in Cloud Pre-audit preparation: Identify all cloud services in use (CSP, account structure,
Environments services). Obtain the most recent SOC 2 Type II reports for all CSPs. Identify CSP
certifications (ISO 27001 scope and certificate date). Map CSP controls to audit
requirements (which compliance requirements are satisfied by CSP controls vs
customer controls). Scoping: Define the audit boundary — which systems, services,
and geographies are in scope. In cloud: specify which CSP accounts, which services,
which regions. Determine if CSP infrastructure is 'carved out' (excluded from scope
— you rely on CSP's own assurance) or 'included' (auditor tests your controls on top
of the platform). Evidence collection approaches: CSPM tool exports (current
configuration state). CloudTrail logs (historical API activity). AWS Config snapshots
(historical resource configurations). IAM Access Advisor reports (who accessed what
services). Screenshots/exports from management console. Infrastructure as Code
(Terraform/CloudFormation) — the IaC IS the configuration documentation.
Continuous Control Monitoring: For highly regulated organisations: implement
continuous compliance monitoring using CSPM tools (Wiz, Prisma Cloud, AWS
Security Hub). Rules continuously evaluate cloud configuration against compliance
requirements. Evidence exported programmatically for audit. This reduces audit
preparation time from months to days.

6.4 Enterprise Risk Management for Cloud

Term / Concept Explanation / Detail
Risk Management ISO 31000:2018 (Risk Management — Guidelines): International standard for risk
Frameworks — Comparative management. Applicable to any type of risk in any organisation. Principles:
Reference Integrated, Structured and comprehensive, Customised, Inclusive, Dynamic, Best
available information, Human and cultural factors, Continual improvement. Process:
Scope context criteria → Risk assessment (identify, analyse, evaluate) → Risk
treatment → Monitoring and review → Communication and consultation. Does not
prescribe specific methodologies — principle-based framework. NIST SP 800-37 Rev.
2 (RMF — Risk Management Framework): U.S. federal government framework.
Seven steps: Prepare, Categorise (FIPS 199), Select (SP 800-53 controls), Implement,
Assess, Authorise, Monitor. FISMA compliance for U.S. federal agencies requires
RMF. FAIR (Factor Analysis of Information Risk): Quantitative risk model for cyber
risk. Produces probability distributions of expected loss in financial terms. Two
primary factors: Loss Event Frequency (how often will a loss event occur?) and Loss
Magnitude (how much will it cost when it does?). Enables: prioritisation of risks by
expected financial impact, cost-benefit analysis for security investments, executive
communication in business terms. OCTAVE Allegra (Operationally Critical Threat,
Asset, and Vulnerability Evaluation): self-directed, workshop-based risk assessment.
No external consultants required. Four phases: Establish drivers, Profile assets,
Identify threats, Identify and mitigate risks. Suitable for small to medium
organisations. COSO ERM (Enterprise Risk Management — Integrating with Strategy
and Performance): Business-oriented framework. Five components: Governance and
culture, Strategy and objective-setting, Performance (risk identification, assessment,
prioritisation, response), Review and revision, Information, communication, and
reporting. Broader than cybersecurity — addresses all enterprise risks.
Risk Treatment — Decision Risk treatment matrix: For each identified risk, assess residual risk (after existing
Framework controls) vs risk appetite: If residual risk > risk appetite → MUST TREAT (choose a
treatment option). If residual risk ≤ risk appetite → ACCEPT (monitor). If risk is
unacceptably high regardless of treatment → AVOID or TRANSFER. Treatment
 options in depth: AVOID: Eliminate the activity that creates the risk. Example:
discontinue processing of certain sensitive data types, withdraw from a market with
onerous regulatory requirements, choose not to use a specific cloud service.
Appropriate when: cost of mitigation exceeds value of the activity, risk is
unacceptably high regardless of cost. MITIGATE (Reduce): Implement controls that
reduce the likelihood of the threat event occurring (preventive controls) or reduce
the impact when it does occur (detective and corrective controls). Example:
implement MFA to reduce probability of credential compromise, implement backup
and DR to reduce impact of ransomware. TRANSFER: Shift the financial
consequences of the risk to another party. Cyber insurance: transfers financial loss
to insurer. SLA financial penalties: CSP bears financial consequences of downtime
exceeding SLA. Contract indemnification: vendor indemnifies you against losses
caused by their product defect. Important limitation: REGULATORY RISK CANNOT BE
TRANSFERRED. Even if the CSP bears financial liability for a breach, YOU remain
responsible to the regulator as data controller. GDPR fines are assessed against the
controller, not the processor (though processor can be fined for its own violations).
SHARE: Distribute risk across multiple parties. Joint ventures where partners share
liability. Multi-cloud architecture (if one CSP is breached, impact is partial).
Insurance with deductibles (both insured and insurer bear costs). ACCEPT:
Acknowledge and document the residual risk. Monitor for changes in likelihood or
impact. Acceptance must be a conscious decision by an accountable person (risk
owner) — not passive ignorance. Document: the risk, why it is acceptable, who
accepted it, when it will be reviewed. Residual risk acceptance: after applying
controls, the remaining risk (residual) may still be above zero — this is normal. Some
risk is inherent in operating any business. The goal is to bring residual risk within risk
appetite, not to eliminate all risk.
Cloud Vendor Risk Vendor assessment framework: Tier vendors by criticality: Tier 1 (critical — failure
Management would severely impact business operations or data security): full security
assessment, annual review, right to audit in contract. Tier 2 (important — significant
impact): questionnaire + independent report review, biannual review. Tier 3 (minor
— low business impact): self-certification, annual confirmation. Security
questionnaire (CAIQ as standard): CAIQ v4 contains 261 yes/no questions mapped to
the CCM v4.0 framework of 197 control objectives across 17 domains. Standardised
allows comparison across multiple CSPs. Request updated CAIQ annually. CSP
continuous monitoring: subscribe to CSP security bulletins and RSS feeds (AWS
Security Bulletins, Microsoft Security Advisory, Google Cloud Security Bulletins).
Monitor CVEs affecting CSP services (NVD, vendor advisories). Review CSP incident
history and postmortems. Monitor CSP financial stability (publicly traded CSPs: 10-K
filings, credit ratings; private CSPs: credit agency ratings, news coverage). Monitor
regulatory actions against CSP (enforcement actions, fines). Contract provisions for
vendor risk: right to audit (audit CSP controls or receive third-party audit reports),
notification of material security changes (30-60 days notice of changes affecting
security controls), breach notification timeline (24-48 hours — contractually
binding), key staff notification (if key security personnel change — signal of security
posture change), CSP compliance obligations (CSP must maintain certifications —
ISO 27001, SOC 2 — and notify customer if certification lapses), supply chain security
(CSP must flow down security requirements to their sub-processors).

6.5 Cloud Contract Design — Complete Reference

FEYNMAN EXPLANATION | Negotiating Cloud Contracts — Power Dynamics and Non-Negotiables
Cloud contract negotiation is asymmetric: AWS, Azure, and GCP have standard terms used by millions of
customers. They will not fundamentally rewrite their terms for any individual customer. However, there is
meaningful negotiation space in: enterprise agreements (large volume commitments unlock negotiation),
specific contractual addenda (BAAs, DPAs, custom SLAs, security addenda), service credits and penalty
structures, and key contract provisions. Before signing any cloud contract, answer these questions: (1) What
data will be in this cloud service, and what classification does it have? The answer drives which contract
provisions are mandatory. PHI → BAA mandatory. Personal data of EU residents → DPA mandatory. Payment
card data → PCI DSS aligned terms required. (2) What is our exit strategy? Can we export all data in standard
formats? What is the cost and timeline of migration? (3) Who owns the data we put in the cloud? (Answer: you
do — verify the contract says so explicitly.) (4) What happens to our data if the CSP is acquired? (5) Who can
access our data? (CSP employees? Sub-processors? Law enforcement without our knowledge?) Non-negotiable
contract provisions: Data ownership clause (your data is YOURS — CSP has no rights to use, analyse, or share
your data). Breach notification timeline (contractually binding, not 'commercially reasonable' — specify hours,
not generic language). Right to audit (at minimum, right to receive SOC 2 Type II report annually). Data deletion
confirmation (CSP confirms deletion of all data after contract termination, within a specified timeframe).
Governing law (not just CSP's preferred jurisdiction). No secondary use of data (CSP cannot use your data for
training AI models, benchmarking, product improvement without explicit consent).

Term / Concept Explanation / Detail

SLA Architecture SLA design principles: Measurability: SLA metrics must be objectively measurable.
'Best efforts' or 'commercially reasonable' are NOT SLA terms — they are aspirations
without accountability. Uptime must be defined precisely: what counts as
'downtime'? (only complete outage, or degraded performance?). Who measures it?
(CSP's monitoring only — conflict of interest). Calculation: 99.9% = 8.76 hours/year
at risk. But how is it measured — per month or per year? Monthly 99.9% = 43.8
minutes of allowed downtime per month. Financial consequence: what does the
customer receive for SLA breach? Service credits (% of monthly fees) are standard
but inadequate for large revenue losses. Negotiate: credit percentage (some CSPs
offer only 10% for 99.9% breach — insufficient), credit calculation (prorated by time
down or fixed percentage?), maximum credit per month (cap on total credits — may
be insufficient for extended outages), credit application process (must customer
report and claim credits, or are they automatic?). Uptime SLA limitations: CSPs
typically exclude from SLA: scheduled maintenance windows, issues caused by
customer's systems or code, issues caused by third-party services the customer
integrates, force majeure events, DDoS attacks against customer's specific
environment. Availability architecture implication: a 99.99% SLA does NOT mean
your application will be 99.99% available if you deploy it in a way that creates
additional single points of failure.
Data Processing Agreement A DPA is mandatory under GDPR Article 28 whenever a controller engages a
(DPA) — GDPR Requirements processor. Content required by GDPR Article 28(3): Subject matter and duration of
processing. Nature and purpose of processing. Type of personal data being
processed. Categories of data subjects. Rights and obligations of the controller.
Processor's obligations — must: Process only on controller's documented
instructions (exceptions: legal obligation, with prior notification to controller).
Ensure personnel authorised to process data are committed to confidentiality.
Implement appropriate technical and organisational security measures (Article 32).
Only engage sub-processors with controller's prior specific or general written
authorisation. Implement measures to assist controller in fulfilling data subject
rights requests. Assist controller with security (Article 32), breach notification
(Articles 33-34), DPIAs (Article 35). After end of service: delete or return all personal
data, delete existing copies (unless EU law requires storage). Make available all
information necessary for controller to demonstrate compliance with Article 28. CSP
DPAs: all major CSPs (AWS, Azure, GCP) publish DPAs (also called Data Processing
Addenda). These are pre-written and incorporate SCCs for international transfers.
Review CSP DPA against Article 28 requirements and your specific processing
activities. Sub-processor provisions: CSP's DPA must address sub-processors. Major
CSPs publish lists of their sub-processors. Customer must be notified of new sub-
processors (typically 30 days advance notice, opportunity to object). Customer
approval of sub-processors may be specific (approve each) or general (approve
category with notification right).
Cloud Contract Risk Liability: CSPs typically cap their total liability at the fees paid in the past 12 months
Provisions (or a multiple thereof). For large cloud deployments this can be millions, but for a
business that suffers a major breach with regulatory fines and customer litigation,
 this cap may be inadequate. Negotiate higher liability caps for data security
obligations, or for specific high-criticality services. Mutual indemnification: CSP
indemnifies you for IP infringement claims (CSP's service uses technology that
infringes on a third party's IP). You indemnify CSP for your use of the service in ways
that cause claims against CSP. Warranty: CSP typically warrants that the service will
perform materially as described in the documentation. No warranty that the service
will be error-free or uninterrupted. No warranty that the security measures will
prevent all unauthorised access. Consequential damages waiver: both parties
typically disclaim liability for consequential, indirect, or punitive damages. This limits
total recoverable damages to direct loss only — lost profits, reputational damage,
etc. may not be recoverable. Business continuity provisions: what is CSP's obligation
if they experience a major outage? What is their RTO commitment (beyond the
general SLA)? Do they have published DR runbooks? Termination provisions:
without cause (either party can terminate with N days notice), for cause (immediate
termination upon material breach), insolvency (what happens to your data if CSP
files for bankruptcy — data must be returned to you before distribution to
creditors). Data return upon termination: CSP must provide all data in an exportable
format within N days of termination. All CSP copies deleted within M days with
written confirmation. Data format: standard formats (JSON, CSV, SQL) not
proprietary formats that require CSP tools to read.
Cyber Insurance — Technical Modern cyber insurers have dramatically increased underwriting rigour post-2020
Underwriting Requirements ransomware wave. Required security controls (commonly): MFA on email and
remote access (no MFA = often declined or >200% premium increase), EDR
(Endpoint Detection and Response) deployed on all endpoints, Regular
offline/immutable backups (no CSP-managed-only backups that can be encrypted by
ransomware in the same CSP account), Network segmentation (flat networks that
allow ransomware lateral movement increase premiums), Patch management
programme (critical patches within defined SLA), Privileged Access Management
(vaulting and recording of privileged access), Incident Response plan (documented,
tested, with defined contacts), Security awareness training (phishing simulation
programme). Underwriting information required: List of all cloud services and CSPs
used. Network diagrams. Employee count (affects aggregate exposure). Revenue
(affects potential liability exposure). Cyber incident history (last 3-5 years).
Technology vendors (some vendors have elevated risk profiles). Coverage types:
First-party coverage (your own costs): Incident response expenses (forensic
investigators, legal counsel, PR), Business interruption (revenue lost during
downtime), Data recovery and restoration, Ransomware extortion payment
(controversial — paying may violate OFAC sanctions if ransomware group is
sanctioned), Credit monitoring for affected individuals, Regulatory investigation
costs (not fines in many policies). Third-party coverage (liability to others):
Regulatory fines and penalties (GDPR fines coverage available from some insurers —
others exclude), Litigation defence, PCI DSS assessments and chargebacks, Media
liability (breach of third-party IP, defamation). Important exclusions: Acts of war
(including nation-state cyberattacks — became controversial when Zurich excluded
NotPetya claims from Merck — ultimately settled, but wording is critical),
Infrastructure failure (cloud provider outage not attributable to a cyberattack),
Bodily injury and property damage (separate policy), Insider theft (may require
crime bond/fidelity insurance).
Vendor Lock-In Risk Lock-in taxonomy: Data lock-in: data stored in proprietary format that requires CSP
Assessment and Mitigation tools to access. Example: proprietary binary database format not exportable without
CSP's database software. Application lock-in: application code uses CSP-proprietary
APIs and services with no open standard equivalent. Example: application built
entirely on AWS Lambda, DynamoDB, Cognito, SNS — migrating requires rewriting
major components. Process lock-in: operational processes depend on CSP-specific
tools and interfaces. Staff expertise is CSP-specific. Training cost for migration is
significant. Financial lock-in: Reserved Instance commitments (1 or 3 year
commitments providing significant discounts). Enterprise Discount Agreements
(multi-year volume commitments with financial penalties for under-consumption).
 Lock-in assessment: Document all CSP-proprietary services used. For each: is there
an open-source or multi-cloud alternative? (DynamoDB → open-source alternative
exists, but migration cost is high). What is the estimated migration effort (person-
months)? What is the CSP-specific expertise invested (re-training cost)? Mitigation
strategies: Abstraction layers: code against abstraction layers (e.g., Kubernetes
instead of CSP-managed Kubernetes) rather than CSP APIs directly. Container-based
portability: OCI-compliant containers run on any container runtime. Terraform for
infrastructure: Terraform supports multiple providers — re-use infrastructure code
across CSPs with provider-specific modules. Multi-cloud for critical services: use
different CSPs for different functions — no complete dependency on a single CSP.
Contract provisions: data portability clause (must provide data in standard format),
reasonable migration timeline (60-90 days), migration assistance (CSP supports data
export), no financial penalty for early termination due to material breach.

KEY POINTS TO REMEMBER 75 high-probability exam concepts — read these the morning of your exam

1 D1 NIST 5 essential cloud characteristics: On-Demand Self-Service, Broad Network Access, Resource
Pooling, Rapid Elasticity, Measured Service. ALL five must be present for true cloud computing per NIST
SP 800-145.

2 D1 Elasticity ≠ Scalability. Scalability = can grow to meet demand. Elasticity = AUTOMATICALLY grows AND
shrinks in real time. Elasticity requires automation. A manually scaled system is scalable but NOT
elastic.

3 D1 Shared Responsibility by service model: IaaS — customer patches OS, middleware, apps. PaaS —
customer responsible only for app code and data; CSP patches OS. SaaS — customer responsible only
for user access and their data in the app. Provider ALWAYS owns physical layer.

4 D1 Cloud deployment models: Public (shared, multi-tenant), Private (dedicated to one org), Community
(shared among orgs with common compliance), Hybrid (mix). Multi-cloud = multiple CSPs but NOT an
official NIST deployment model.

5 D1 Cloud bursting = overflow peak demand from private cloud to public cloud. This IS a Hybrid Cloud
pattern. Example: reserve capacity on private cloud for normal load; burst to AWS during peak season.

6 D1 In cloud, cryptographic erasure (destroy the encryption key) is the ONLY reliable data sanitisation
method. Physical destruction, degaussing, and overwriting are unavailable — you don't own the
hardware.

7 D1 Zero Trust = never trust, always verify. No implicit trust based on network location. Every request
authenticated and authorised regardless of source. Assumes breach — microsegmentation, minimal
blast radius.

8 D1 VM Escape: attacker breaks out of guest VM to access hypervisor or other VMs on same host. Critical
multi-tenancy threat. Mitigated by: hypervisor patching, hardware isolation (VT-d/IOMMU).

9 D1 Side-Channel Attacks (Spectre, Meltdown): exploit shared CPU timing/cache to read adjacent VMs'
memory. Mitigated by: microcode updates, KPTI kernel patches, hypervisor isolation, disabling SMT in
high-security environments.

1 D1 FIPS 140-2 levels: L1=basic, L2=tamper-evident, L3=tamper-resistant with identity-based auth,

0 L4=tamper-responsive (zeroises keys under environmental attack). HSMs for government/federal use
require Level 3 minimum.

1 D1 ISO 27017=cloud-specific security controls. ISO 27018=PII in public clouds. CSA CCM=cloud controls
1 matrix mapped to ISO, PCI DSS, HIPAA, NIST. SOC 2 Type II=6-12 month audit of CSP controls —
strongest cloud assurance report.

1 D1 Key hierarchy: Root Master Key → CMK → DEK. DEK encrypts data. CMK wraps the DEK. Only wrapped
2 DEK stored with data. CMK stays in HSM. NEVER store keys with the data they protect.

1 D2 Data Lifecycle 6 phases: CREATE → STORE → USE → SHARE → ARCHIVE → DESTROY. Different security
3 controls at each phase. DLP at SHARE, crypto erase at DESTROY, IRM for SHARE/USE, classification at
CREATE.

1 D2 Tokenisation = replace sensitive data with random meaningless token. Token in systems; original in
4 isolated vault. Reversible only via vault lookup. NOT mathematically related to original. Primary PCI DSS
scope reduction technique.

1 D2 Anonymisation = IRREVERSIBLY remove identifying info. No longer personal data under GDPR.
5 Pseudonymisation = reversible alias — STILL personal data under GDPR. These are NOT synonyms.

1 D2 Masking = hide partial data in DISPLAY only. Original data STILL EXISTS in the database. NOT
6 encryption. Reversible. Example: showing XXXX-XXXX-XXXX-1234 on call centre screen.

1 D2 Legal hold overrides ALL retention and deletion policies. Triggered when litigation REASONABLY
7 ANTICIPATED — not just when started. Covers all data: cloud, backups, archives. Failure = spoliation =
court sanctions.

1 D2 Object storage (S3) is the most common cloud data breach vector due to misconfiguration. Default ALL
8 buckets to PRIVATE. Enable 'Block Public Access' at account level. NEVER s3:GetObject to Principal: '*'.

1 D2 BYOK = keys generated outside CSP, imported into CSP KMS. CSP still does encryption operations —
9 technically has key access. HYOK = keys NEVER leave your HSM. CSP cannot access plaintext. Highest
security, limited functionality.

2 D2 DLP types: Network (inspect egress traffic), Endpoint (agent on device, works offline), Cloud (scan cloud
0 storage and SaaS). Cannot see through encrypted traffic without SSL inspection.

2 D2 IRM = persistent protection travelling with the data regardless of destination. Controls enforced even
1 after download. Certificate revocation = instantly revoke access from ALL copies everywhere.

2 D2 Chain of custody = unbroken documented record of all evidence handling. Hash (MD5 + SHA-256)
2 immediately on collection. Any gap = evidence inadmissible. Work on copies, never originals.

2 D2 Non-repudiation = cryptographic proof that an actor performed an action and cannot deny it. Digital
3 signatures, HSM-signed audit logs, timestamped cryptographic receipts.

2 D3 Management plane compromise = total environment compromise. Protect with: MFA on all accounts,
4 IP allowlisting for console, comprehensive API call logging (CloudTrail), anomaly detection, least-
 privilege IAM.

2 D3 BC/DR metrics: RTO = how long to restore service. RPO = maximum data loss in time. RSL = minimum %
5 capacity during recovery. MTD = RTO must be LESS than MTD (absolute business ceiling).

2 D3 BC/DR testing (least to most disruptive): Tabletop → Walkthrough Drill → Functional → Parallel Test
6 (DR active while production runs) → Full Interruption (most realistic, highest risk). Untested plan = not
a plan.

2 D3 Data centre tiers: I=99.671%, II=99.741%, III=99.982% (1.6h/yr, concurrently maintainable),

7 IV=99.995% (26min/yr, fault tolerant, no SPOF).

2 D3 Hot/Warm/Cold: Hot = fully operational, near-zero RTO, highest cost. Warm = partially provisioned,
8 hours RTO. Cold = empty facility, days RTO, cheapest. Active-Active = both regions handle live traffic,
instantaneous failover.

2 D3 ALE = SLE × ARO. SLE = Asset Value × Exposure Factor. ARO = annual frequency. Control justified if:
9 Annual Cost of Control < ALE Reduction. Know this formula — it's on the exam.

3 D3 Fire suppression in data centres: FM-200, inert gas (Inergen), CO2 — NOT water (damages electronics).
0 VESDA for very early smoke detection. Pre-action dry pipe reduces accidental discharge.

3 D4 STRIDE maps to violated security properties: S→Authentication, T→Integrity, R→Non-repudiation,

1 I→Confidentiality, D→Availability, E→Authorisation. Applied to data flow diagrams — identify threats
at each element.

3 D4 OWASP Top 10 (2021): 1-Broken Access Control (↑#1), 2-Cryptographic Failures, 3-Injection, 4-
2 Insecure Design, 5-Misconfiguration, 6-Vulnerable Components, 7-Auth Failures, 8-Software Integrity
Failures, 9-Logging Failures, 10-SSRF.

3 D4 Testing types: SAST=static, source code, white-box, code-level vulnerabilities. DAST=dynamic, running
3 app, black-box, runtime vulnerabilities. IAST=interactive, agent inside app, low false positives.
SCA=open-source dependency scanning.

3 D4 Cost to fix: $1 requirements, $10 design, $100 code, $1,500 testing, $10,000+ production, millions after
4 breach. Shift Left = find security issues as early as possible. Security requirements in sprint planning.

3 D4 CASB 4 pillars: Visibility (shadow IT discovery), Compliance (policy enforcement), Data Security (DLP for
5 cloud), Threat Protection (compromised accounts, malware). Modes: forward proxy, reverse proxy,
API.

3 D4 SAML=XML-based enterprise web SSO (authentication federation). OAuth 2.0=authorisation

6 framework (delegated access). OIDC=OAuth 2.0 + identity (authentication + authorisation). Modern
apps use OIDC; enterprise federation uses SAML.

3 D4 BOLA (Broken Object-Level Authorisation) = most common API vulnerability. User changes object ID in
7 URL to access another user's data. Fix: object-level authorisation check on EVERY request, not just at
login.
3 D4 Secrets management: NEVER hardcode credentials. Use Vault, AWS Secrets Manager, Azure Key Vault.
8 Dynamic secrets (generated on-demand, auto-expire). Rotate automatically. Audit every secret access.

3 D4 MFA factors: Something you know (password), have (authenticator/hardware key/SMS OTP), are
9 (biometric). Phishing-resistant: FIDO2/WebAuthn (hardware security key, platform authenticator). SMS
OTP = weakest (SIM swapping).

4 D4 Microservices: mTLS (mutual TLS) for service-to-service authentication. Service mesh (Istio, Linkerd)
0 automates mTLS and provides authorisation policies and observability. Each service has own IAM
identity.

4 D5 Incident Management = restore service ASAP; workarounds acceptable; NO root cause analysis.
1 Problem Management = find root cause; permanent fix; RCA report; update KEDB. SEPARATE processes
with DIFFERENT goals. Tested frequently.

4 D5 Change types: Standard (pre-approved, routine, no full CAB review). Normal (CAB approval required
2 before implementation). Emergency (expedited ECAB, can be post-implementation review). ALL
changes need rollback plans.

4 D5 Cloud forensics: No physical access, multi-tenant commingling, ephemeral resources, multi-

3 jurisdictional law, log availability depends on pre-incident configuration. Take VM snapshots
IMMEDIATELY upon discovery.

4 D5 SOC tiers: 1=alert triage and escalation. 2=deep investigation and containment. 3=threat hunting
4 (proactive) and advanced forensics. SIEM detects. SOAR automates response (playbooks reduce MTTR
hours→minutes).

4 D5 Availability: MTBF = Mean Time Between Failures (higher = better). MTTR = Mean Time To Recover
5 (lower = better). Availability = MTBF / (MTBF + MTTR) × 100%.

4 D5 Bastion host = single hardened admin access entry point. All SSH/RDP routes through it for logging,
6 MFA, recording. AWS Systems Manager Session Manager = no-SSH alternative (fully logged, no bastion
needed).

4 D5 IaC security: tfsec (Terraform), Checkov (multi-framework), cfn-nag (CloudFormation). Fail CI/CD
7 pipeline on high-severity findings. Immutable infrastructure = replace instances from templates rather
than patching in place.

4 D5 Patch management CVSS priority: Critical (9-10)=24-48h. High (7-8.9)=7 days. Medium (4-6.9)=30 days.
8 Low (0.1-3.9)=90 days. Emergency patches bypass normal window but still require ECAB and rollback
plan.

4 D5 DNSSEC adds crypto signatures to DNS records to prevent cache poisoning. Does NOT encrypt DNS
9 queries. Use DoH or DoT for query privacy. Enable on authoritative zones you control.

5 D6 GDPR applies to ANY organisation processing personal data of EU/EEA residents, regardless of where
0 the organisation is based or where data is stored. No threshold — even one EU resident's data triggers
GDPR.

5 D6 GDPR breach notification: 72 hours to supervisory authority (DPA). 'Without undue delay' to data
1 subjects if high risk. Fines: up to €20M or 4% global annual turnover — WHICHEVER IS HIGHER. Both
thresholds apply; the higher amount is used.

5 D6 Data Controller = decides WHY and HOW data is processed; primary GDPR liability. Data Processor =
2 processes on controller's instructions; must sign DPA. You (cloud customer) = usually Controller. CSP =
usually Processor.

5 D6 SOC 2 Type I = controls at single point in time, limited assurance. SOC 2 Type II = controls tested over 6-
3 12 months, highest assurance. SOC 3 = public summary. Enterprise customers REQUIRE Type II.

5 D6 Legal hold triggered when litigation REASONABLY ANTICIPATED — not just when started. Suspend all
4 deletion immediately. Scope ALL relevant data including cloud, backups, archives. Spoliation = court
sanctions, adverse inference.

5 D6 Risk treatment: Avoid (stop the activity), Mitigate (controls), Transfer (insurance, SLA penalties), Share
5 (joint ventures), Accept (document residual). Transfer does NOT eliminate regulatory liability — you
remain the controller.

5 D6 HIPAA: BAA REQUIRED before ANY cloud provider can store, process, or transmit PHI. Using CSP for PHI
6 without BAA = HIPAA violation even if no breach occurred. BAA cannot be substituted by any other
agreement.

5 D6 PCI DSS scope reduction: Tokenisation (systems seeing only tokens are out of scope), Network
7 segmentation (isolated CDE reduces scope), P2PE (encrypted at point of capture — out of scope until
decryption endpoint).

5 D6 Cloud contract must-haves: SLA with financial penalties, right to audit, data portability, data deletion
8 on termination, breach notification timelines (24-48h), data ownership clause, governing law, sub-
processor notification rights.

5 D6 ALE = SLE × ARO. SLE = Asset Value × Exposure Factor. Control is justified if Annual Cost of Control < ALE
9 Reduction. This is ROI for security investment — quantitative risk management in financial terms.

6 D6 Cross-border data transfers under GDPR: Adequacy decision (EU recognises country's protection), SCCs
0 (Standard Contractual Clauses), BCRs (Binding Corporate Rules — intra-group). U.S.-EU Data Privacy
Framework (2023) = current adequacy mechanism.

6 D6 FedRAMP: Required for CSPs serving U.S. federal agencies. Three levels: Low, Moderate, High (based
1 on FIPS 199). JAB P-ATO or Agency ATO. 'Do once, use many' — one authorisation reusable across
agencies.

6 D6 ISO 27001 vs SOC 2: ISO 27001 = ISMS certification, globally recognised, annual surveillance. SOC 2 =
2 attestation of specific operational controls, U.S.-origin (AICPA), common in tech industry. Many
enterprises require BOTH.

6 D6 SEC cybersecurity rules (2023): Material incidents must be disclosed in Form 8-K within 4 business days
3 of determining materiality. Annual cybersecurity risk management disclosures in Form 10-K. Public U.S.
companies.

6 D6 DPIA required by GDPR Article 35 for high-risk processing. Triggers: new technology, large-scale special
 4 category data, systematic public monitoring, automated decision-making with significant effects.
Conduct BEFORE processing begins.

6 ALL Encryption vs Hashing vs Tokenisation: Encryption = reversible with key (confidentiality). Hashing =
5 irreversible one-way (integrity, passwords). Tokenisation = surrogate in systems, original in vault (PCI
scope reduction). Different purposes — not interchangeable.

6 ALL AAA: Authentication = who are you? Authorisation = what can you do? Accounting = what did you do?
6 All three required. MFA strengthens authentication. RBAC/ABAC strengthens authorisation. SIEM
provides accounting.

6 ALL Defence in depth = multiple independent layers of security. No single control relied upon exclusively.
7 WAF + IPS + OS hardening + input validation + encryption + SIEM = defence in depth. If one fails, others
remain.

6 ALL When stuck between two answers: prefer the option that is more PROACTIVE (prevention > detection
8 > response), more COMPREHENSIVE (addresses root cause), and more RISK-BASED (proportional to the
threat and business context).

6 ALL CCSP scenario questions: (1) What is the regulatory context? (2) What service model (IaaS/PaaS/SaaS)
9 applies? (3) Who is responsible for this control (CSP vs customer)? (4) What is the business constraint?
THEN select the answer.

Good luck, Rajesh! You have everything you need.

Understand the concepts. Apply the frameworks. Think like a cloud security architect, not a test-taker.
 APPENDIX A — GROUNDING AND VALIDATION
Where every factual claim in this guide comes from, and what was corrected

How this guide was validated

• Every quantitative claim in this guide — control counts, timelines, percentages, version numbers, and statutory deadlines
— was extracted programmatically and checked against primary or authoritative secondary sources during the validation
pass.
• Where a source of truth exists as a published standard (NIST SP, ISO/IEC, FIPS, an EU Regulation article, or a CFR section),
that document is cited as the ground truth rather than a secondary explainer.
• Claims that were found to be wrong were corrected in place, and the corrected entries are flagged with the word
CORRECTED in the grounding table so you can see exactly what changed.
• Claims that were correct but incomplete — for example, a standard that has since been superseded — were expanded
with the current status plus a note on which version the October 2025 exam expects.
• Where authoritative sources legitimately disagree (FedRAMP control counts shift slightly between published baselines
and revisions), the guide states an approximate figure and tells you to focus on the relative scale rather than memorising
a precise number.
• The relevance check maps each major section of this guide to the ISC2 October 2025 exam outline, so you can see what is
core, what is illustrative, and what is future awareness that will not be tested on your exam.

HOW TO READ THIS TABLE: Entries beginning with CORRECTED are claims that were found to be wrong or
materially incomplete during validation and have been fixed in the body of this guide. Everything else was
checked and confirmed accurate. If an exam question ever seems to contradict this guide, trust the cited
source column.

Grounding table — claim, verified value, source

Claim area Verified value Authoritative source
Exam format & CAT (Computerized Adaptive Testing) since 1 Oct 2025. 100-150 ISC2 Computerized
length items, 3-hour maximum, 25 unscored pretest items included in the Adaptive Testing FAQ
minimum length. ([Link])
Passing score 700 out of 1000 scaled. Scaled scoring accounts for item-difficulty ISC2 CCSP Exam Outline
differences; it is NOT a raw 70% correct.
Experience 5 years cumulative paid IT work, including 3 years information ISC2 CCSP certification
requirement security and 1 year in one or more of the 6 CCSP domains. An active requirements
CISSP waives the entire requirement; CCSK waives 1 year.
Syllabus validity October 2025 exam outline applies through 31 July 2026. A new ISC2 exam outline change
outline from ISC2's latest Job Task Analysis takes effect 1 August notice
2026.
Domain weightings D1 17%, D2 20%, D3 17%, D4 17%, D5 16%, D6 13%. Domain 2 (Cloud ISC2 CCSP Exam Outline,
Data Security) carries the highest weight. October 2025
NIST cloud definition Five essential characteristics: on-demand self-service, broad network NIST SP 800-145
access, resource pooling, rapid elasticity, measured service. Three
service models (IaaS/PaaS/SaaS), four deployment models
(private/community/public/hybrid).
Sixth characteristic ISO/IEC 17788 adds multitenancy to the NIST five. ISO also combines ISO/IEC 17788:2014 Cloud
(multitenancy) elasticity and scalability into a single characteristic. Computing Vocabulary
Cloud roles CSC, CSP, cloud service partner, broker and auditor roles as described ISO/IEC 17789:2014 Cloud
taxonomy are consistent with the ISO cloud reference architecture. Reference Architecture
AES classification CORRECTED. AES-128 is NSA-approved for SECRET; AES-256 is NSA CNSA Suite / CNSSP-
levels approved up to TOP SECRET. AES-256 is the only publicly available 15; FIPS 197
cipher approved for TOP SECRET. CNSA 2.0 (2022) mandates AES-256
at all classification levels.
FIPS 140 version CORRECTED. FIPS 140-3 superseded FIPS 140-2 effective 22 NIST CSRC FIPS 140-3
status September 2019. CMVP stopped accepting new 140-2 submissions in Transition Effort
2022. All remaining FIPS 140-2 certificates move to the Historical List
on 21 September 2026. FIPS 140-3 aligns to ISO/IEC 19790 and
ISO/IEC 24759.
Post-quantum Finalised 13 August 2024: FIPS 203 ML-KEM (from CRYSTALS-Kyber), NIST FIPS 203/204/205;
standards FIPS 204 ML-DSA (from CRYSTALS-Dilithium), FIPS 205 SLH-DSA (from Federal Register 14 Aug
SPHINCS+). HQC selected as an additional KEM in 2025. NSA CNSA 2.0 2024
sets 2030 as the NSS migration deadline.
TPM standards CORRECTED. TPM is specified by the Trusted Computing Group and ISO/IEC 11889; NIST CSRC
citation standardised as ISO/IEC 11889 — it is not a NIST SP. Related NIST publication index
platform-integrity guidance: SP 800-147 (BIOS Protection), SP 800-
155 (BIOS Integrity Measurement, draft), SP 800-193 (Platform
Firmware Resiliency).
ISO 27001:2022 93 controls in 4 themes: Organizational 37, People 8, Physical 14, ISO/IEC 27001:2022 Annex
Annex A Technological 34. Reduced from 114 controls / 14 domains in the A; ISO/IEC 27002:2022
2013 edition; 11 controls are new in 2022.
SOC 2 observation CORRECTED. There is no hard AICPA minimum. The practical floor AICPA SSAE No. 18 / AT-C
period used by CPA firms is approximately 3 months; AICPA guidance 205 guidance
indicates periods under 6 months may not provide sufficient
assurance; 12 months is the common enterprise expectation.
CSA CCM and CAIQ CORRECTED. CCM v4.0 = 197 control objectives across 17 domains; Cloud Security Alliance
CAIQ v4 = 261 yes/no questions. CCM v4.1 (December 2025) = 207 CCM v4.0 / v4.1 artifacts
controls; CAIQ v4.1 = 283 questions. Controls and questions are
distinct counts and must not be conflated.
FedRAMP baselines CORRECTED. Under NIST SP 800-53 Rev. 5: Low approximately 156 FedRAMP baselines; NIST
controls, Moderate approximately 323, High approximately 410-421. SP 800-53 Rev. 5
All three share 17 control families. Moderate covers roughly 73-80%
of authorised offerings.
Uptime Institute tiers Tier I 99.671% (28.8 h/yr), Tier II 99.741% (22 h/yr), Tier III 99.982% Uptime Institute Tier
(1.6 h/yr), Tier IV 99.995% (26.3 min/yr). Tier III = concurrently Classification System
maintainable; Tier IV = fault tolerant.
NIST RMF steps Seven steps in SP 800-37 Rev. 2 (December 2018): Prepare, NIST SP 800-37 Rev. 2
Categorize, Select, Implement, Assess, Authorize, Monitor. Rev. 1 had
six steps and was withdrawn 20 December 2019; 'Prepare' is the step
added in Rev. 2.
OWASP Top 10 OWASP Top 10:2021 remains the correct reference for the October OWASP Foundation Top
edition 2025 CCSP syllabus. OWASP Top 10:2025 was published in November Ten project
2025, after the syllabus freeze: it adds A03 Software Supply Chain
Failures and A10 Mishandling of Exceptional Conditions, moves
Security Misconfiguration to A02, and folds SSRF into A01.
Zero Trust Tenets as described (no implicit trust by network location, per- NIST SP 800-207
architecture session access, dynamic policy, assume-breach posture) match the
published federal definition.
GDPR breach Article 33: controller notifies the supervisory authority without Regulation (EU) 2016/679,
notification undue delay and where feasible within 72 hours of awareness, unless Articles 33-34
the breach is unlikely to result in risk. Article 34: notify data subjects
without undue delay where risk is high.
GDPR data subject Eight rights: to be informed, of access, to rectification, to erasure, to Regulation (EU) 2016/679,
rights restrict processing, to data portability, to object, and not to be Articles 12-22
subject to solely automated decision-making. Standard response
 window is one month, extendable to three for complex requests.
EU-US transfer Privacy Shield invalidated by Schrems II in July 2020. The EU-US Data European Commission
mechanisms Privacy Framework adequacy decision was adopted 10 July 2023. adequacy decision, 10 July
Revised Standard Contractual Clauses were published in 2021 with 2023
four modules.
HIPAA breach Individuals: without unreasonable delay, no later than 60 days from 45 CFR 164.400-414; HHS
notification discovery. HHS: within 60 days if 500 or more individuals affected; Breach Notification Rule
otherwise annually within 60 days of calendar year end. Media notice
required when 500 or more residents of a single state or jurisdiction
are affected.
PCI DSS current CORRECTED. PCI DSS v4.0.1 (June 2024) is the current version. v4.0 PCI Security Standards
version was published March 2022; v3.2.1 retired 31 March 2024. Of 64 new Council
requirements, 51 were future-dated and became mandatory on 31
March 2025.
Media sanitisation Clear / Purge / Destroy categories are correct. NIST explicitly notes NIST SP 800-88 Rev. 1
cloud customers may be unable to perform media sanitisation on
CSP-owned devices, which is why cryptographic erasure is the
practical cloud control.
 APPENDIX B — SYLLABUS RELEVANCE CHECK
Every section of this guide mapped to the ISC2 October 2025 exam outline

This table tells you where to spend your remaining study time. Sections marked 'core' are directly examinable and carry
domain weighting. Sections marked 'illustrative' teach a control category through named products — learn the category,
because the exam will not ask you to name a vendor. Sections marked 'awareness' or 'out of scope' are included so you
are not blindsided by a colleague or a newer textbook, but they will not appear on the October 2025 syllabus exam.

Guide section Maps to exam outline Verdict

Domain 1 — cloud concepts, service and 1.1-1.3 Cloud computing concepts, reference In scope — core
deployment models, shared responsibility, architecture, security concepts
reference architecture
Domain 1 — cryptography, key 1.3 Security concepts relevant to cloud In scope — core
management, HSM, BYOK/HYOK, computing; 1.4 design principles of secure cloud
sanitisation, virtualisation security computing
Domain 1 — AI/ML, IoT, containers, 1.5 Impact of related technologies (explicitly In scope — newly
serverless, blockchain, quantum, edge, expanded in the October 2025 outline) emphasised
confidential computing, DevSecOps
Domain 1 — CSP evaluation, ISO 1.5 Evaluate cloud service providers In scope — core
27001/27017/27018, SOC 2, CSA STAR, (certifications against criteria, product
FedRAMP, FIPS 140 certifications)
Domain 2 — data lifecycle, storage 2.1-2.5 Cloud data lifecycle, storage In scope — highest
architectures, encryption, obfuscation, DLP, architectures, data security technologies, weight
discovery and classification discovery, classification
Domain 2 — IRM, retention, legal hold, 2.6-2.8 Information rights management, data In scope — core
deletion, auditability and chain of custody retention/deletion/archiving policies,
auditability and accountability
Domain 3 — physical/logical infrastructure, 3.1-3.2 Cloud infrastructure components; In scope — core
data centre design, tiers, environmental datacenter design (logical, physical,
controls environmental)
Domain 3 — risk analysis, quantitative and 3.3-3.4 Risk analysis of cloud infrastructure; In scope — core
qualitative methods, cloud-specific risk plan and implement security controls
factors
Domain 3 — BC/DR strategy, 3.5 Plan business continuity and disaster In scope — core
RTO/RPO/RSL/MTD, architecture patterns, recovery
testing types
Domain 4 — secure SDLC, threat modelling 4.1-4.4 Awareness and training, secure SDLC, In scope — core
(STRIDE/PASTA/attack trees), testing software assurance and validation, verified
(SAST/DAST/SCA/pen test) secure software
Domain 4 — API security, OAuth 2.0, JWT, 4.5-4.6 Specifics of cloud application In scope — newly
microservices, containers, Kubernetes, architecture, supplemental security emphasised
serverless components
Domain 4 — federation, CASB, Zero Trust 4.6 Design appropriate identity and access In scope — core
access management solutions
Domain 5 — physical/logical build, 5.1-5.2 Build/implement physical and logical In scope — core
hypervisor hardening, HSM/TPM infrastructure; operate and maintain
operations
Domain 5 — hardening, CIS Benchmarks, 5.2-5.3 Operate physical/logical infrastructure; In scope — core
remote access, patch management, IaC implement operational controls and standards
security (ITIL/ISO 20000-1)
Domain 5 — ITIL processes, digital 5.4-5.7 Digital forensics, communication with In scope — core
forensics, SOC operations, threat hunting, stakeholders, security operations centre,
SIEM/SOAR, vulnerability management incident management
Domain 6 — computer crime law, 6.1 Articulate legal requirements and unique In scope — core
eDiscovery, forensic requirements risks within the cloud environment
Domain 6 — GDPR, HIPAA, PCI DSS, privacy 6.2 Understand privacy issues; 6.3 audit In scope — core
programme requirements process, methodologies, required adaptations
Domain 6 — audit types, SOC reports, audit 6.3 Understand audit process, methodologies, In scope — core
planning in cloud and required adaptations for a cloud
environment
Domain 6 — ERM frameworks, risk 6.4-6.5 Understand implications of cloud to In scope — core
treatment, vendor risk, contracts, SLAs, enterprise risk management; outsourcing and
cyber insurance, lock-in cloud contract design
Post-quantum cryptography detail (FIPS Touches 1.5 related technologies, but exam Awareness only — do
203/204/205 parameter sets) treatment is conceptual only not memorise
parameters
Named vendor products (specific tool Not named in the ISC2 outline; included as Illustrative — learn the
names such as Wiz, Trivy, Falco, CyberArk) illustrative examples of control categories category, not the brand
OWASP Top 10:2025 category changes Published after the October 2025 syllabus Out of scope for this
freeze exam — future
awareness
CCM v4.1 / CAIQ v4.1 revised counts Published December 2025, after the syllabus Out of scope for this
freeze exam — future
awareness
FIPS 140-2 to 140-3 historical-list transition Both standards are valid references for this Awareness — know that
(21 Sep 2026) exam; the transition date falls after the syllabus 140-3 supersedes 140-2
window

STUDY PRIORITY: Domain 2 carries 20% of the exam — more than any other. If your time is short, revise
Domain 2 (data lifecycle, storage architectures, encryption, obfuscation, DLP, IRM, retention) first, then
Domains 1, 3 and 4 at 17% each, then Domain 5 at 16%, and Domain 6 at 13% last. Within every domain, the
exam rewards judgment over recall: for each scenario ask who owns the control, what service model applies,
which regulation is triggered, and what the business actually needs.

Validated and regenerated — good luck, Rajesh.