CCSP Exam Prep 2026: Certified Cloud Security Professional

In this lesson

Why AI gets its own module, and what you'll build.

Key points

• The August 2026 outline has two new AI subdomains. Subdomain 1.6 asks you to comprehend AI and machine learning. Subdomain 2.9 asks you to comprehend data protection for AI and machine learning data.
• ISC2 also says AI security runs across all six domains.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; ISC2 CCSP Certification Exam Outline, effective 1 October 2025 (superseded); ISC2: How is AI security incorporated into the CCSP domains (section of the outline page)

In this lesson

How AI helps detect cloud threats, and why its output is a lead rather than a verdict. Outline: 1.6.

Key points

• Aldermoor's cloud account produces more logs than anyone can read. Nadia wants to know: can AI watch them for us, and can we trust what it says? This is the first topic in subdomain 1.6: cloud threat detection and analysis.
• ISC2's description of Domain 5 explains why. In the cloud security operations centre, AI helps manage the sheer scale of cloud logs, through threat hunting and event correlation across multi-cloud environments.
• Here are three approaches, in our own grouping. Known bad: threat intelligence feeds, such as lists of malicious IP addresses, domains and file hashes.
• Unusual: a machine learning model learns a baseline of a system's expected behaviour, then spots anomalies, which is close to impossible for people to do in real time.
• And combined: correlating activity across the stages of an attack.
• You can already see this in cloud services. Amazon GuardDuty combines threat intelligence feeds and machine learning models to identify suspicious activity.
• Microsoft Sentinel's Fusion engine uses machine learning to detect multistage attacks, by finding combinations of anomalous behaviours across stages of the kill chain.
• Our point: a detection service only sees what it's fed. GuardDuty starts from CloudTrail management events, VPC flow logs and DNS logs.
• False alarms matter. Microsoft says Fusion is built for low-volume, high-fidelity incidents, and that it's customised to your environment to reduce false positives.
• NIST's incident response guidance tells you to consider known false positives when deciding whether to declare an incident.
• But detection models are targets too. Evasion attacks modify inputs so that a model's prediction changes to what the attacker wants.
• MITRE ATLAS records attackers trying to evade a machine-learning phishing detector by modifying brand logos. One model was fooled, but the wider system still caught the sites.
• Models also change over time. ISC2 asks you to monitor AI performance continuously for security-related model drift, and to investigate a deviation in model output as a potential security incident.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; ISC2: How is AI security incorporated into the CCSP domains (section of the outline page); AWS: What is Amazon GuardDuty; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Microsoft Sentinel: multistage attack detection (Fusion); NIST SP 800-61 Rev. 3: Incident Response Recommendations; NIST AI 100-2: Adversarial Machine Learning, a taxonomy; MITRE ATLAS (adversarial threat landscape for AI systems)

In this lesson

Whether a source should feed a model at all. Outline: 1.6.

Key points

• A model is only as good as what it reads. Subdomain 1.6 names data source validation and verification.
• The EU AI Act shows what good practice asks of training data. For high-risk systems, data governance practices must cover how data is collected and where it came from, including the original purpose of personal data.
• Article 10 then gives you the validation questions. Data must be relevant, sufficiently representative and, to the best extent possible, free of errors and complete, in view of the intended purpose. To the extent its intended purpose requires, it must also reflect the geographical, contextual, behavioural or functional setting where the system is intended to be used.
• Start with origin. OWASP warns that risks are particularly high with external data sources, which may contain unverified content, so track data origins and transformations and verify legitimacy at every stage.
• Then the content. ISC2 points to discovery and classification tools that identify sensitive information before it enters a machine-learning pipeline, and to the jurisdictional risk when training data crosses cloud regions.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2024/1689 (Artificial Intelligence Act); OWASP Top 10 for LLM and generative AI applications; ISC2: How is AI security incorporated into the CCSP domains (section of the outline page)

In this lesson

What SOAR automates, what a playbook is, and how much to automate. Outline: 1.6.

Key points

• Finding a threat is half the job. Subdomain 1.6 also names Security Orchestration, Automation and Response, or SOAR.
• Microsoft's documentation describes the problem well: SOC teams face so many alerts that many are ignored and many incidents aren't investigated.
• Microsoft says one of Sentinel's primary purposes, as a SOAR platform, is to automate recurring and predictable enrichment, response and remediation tasks.
• The building block is the playbook: a collection of response and remediation actions and logic, run as a routine. A playbook can integrate with other systems, and run automatically on certain alerts or manually on demand.
• NIST's incident response guidance recommends tools such as SIEM and SOAR to help monitor log events and gather related data from many sources.
• Let's walk a playbook for a leaked access key. First, enrich: pull the key's owner and its recent activity. Second, decide: does it match a rule you've agreed? Third, act: disable the key. Fourth, tell the on-call analyst, and open an incident with the evidence attached. Fifth, record what ran. That sequence is our example. Simpler steps may not need a playbook: Sentinel's automation rules can tag, assign or close incidents directly, and create task lists for analysts.
• ISC2 links this to analysts' time. Cloud-native SIEM and SOAR platforms can automate the response to common threats, so people can focus on the most complex attacks.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Microsoft Sentinel: automation and SOAR; NIST SP 800-61 Rev. 3: Incident Response Recommendations; ISC2: How is AI security incorporated into the CCSP domains (section of the outline page)

In this lesson

Ethical concerns in AI, and where they reach a security team. Outline: 1.6.

Key points

• It doesn't list them, so we need a yardstick. The OECD AI Principles give an international one: inclusive growth, sustainable development and well-being; respect for the rule of law, human rights and democratic values, including fairness and privacy; transparency and explainability; robustness, security and safety; and accountability.
• Fairness first. NIST says fairness in AI includes concerns for equality and equity, by addressing harmful bias and discrimination, and that standards of fairness can be hard to define because perceptions differ among cultures.
• Bias goes further than people expect. NIST says it's broader than demographic balance and data representativeness, and names three categories: systemic, computational and statistical, and human-cognitive. Each can occur without any intent to discriminate. NIST adds that systems with somewhat balanced predictions may still be inaccessible to people with disabilities.
• Then transparency and accountability. NIST says trustworthy AI depends on accountability, and that accountability presupposes transparency.
• ISC2's Domain 6 description points to explainability under frameworks such as the GDPR and the EU AI Act.
• Having a person in the loop isn't a cure. For high-risk systems, Article 14 of the AI Act requires that the people overseeing them can stay aware of automation bias: the tendency to over-rely on a system's output, especially when it provides information or recommendations for people's decisions.
• Ethics extends to your suppliers. ISC2 also asks you to assess AI vendors' risk, so that their security controls and ethical guidelines align with your organisation's standards.

Sources

OECD Recommendation of the Council on Artificial Intelligence (AI Principles); NIST AI 100-1: AI Risk Management Framework; ISC2: How is AI security incorporated into the CCSP domains (section of the outline page); Regulation (EU) 2024/1689 (Artificial Intelligence Act)

In this lesson

What AI law means for a security team. A teaching summary, not legal advice. Outline: 1.6.

Key points

• Subdomain 1.6 also names regulatory requirements.
• Begin with the EU AI Act, which classifies by risk. Article 5 prohibits certain practices. Article 6 defines high-risk systems, through Annex I products and Annex III uses.
• Article 50 adds transparency duties, such as telling people when they interact with an AI system.
• Your duties depend on your role. A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name. A deployer uses one under its authority.
• Deployers of high-risk systems must assign human oversight to people with the necessary competence, training and authority.
• Check the dates. The Digital Omnibus of 2026 moved them: high-risk rules apply from 2 December 2027 for Annex III systems, and from 2 August 2028 for Annex I systems.
• One article speaks directly to you. Article 15 requires high-risk systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting vulnerabilities. Technical solutions shall include, where appropriate, measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws.
• Existing law still applies. Article 22 of the GDPR gives people the right not to be subject to a decision based solely on automated processing where it has legal or similarly significant effects, with exceptions.
• In the US, the HIPAA Security Rule requires covered entities and business associates to ensure the confidentiality, integrity and availability of electronic protected health information.
• HIPAA also reaches down the supply chain. A business associate's contract must require it to comply with the applicable Security Rule requirements, and to ensure that subcontractors handling electronic protected health information on its behalf agree to the same, by contract or other arrangement.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2024/1689 (Artificial Intelligence Act); Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending the AI Act (in force 27 July 2026); Regulation (EU) 2016/679 (General Data Protection Regulation); 45 CFR 164.306 to 164.314 (HIPAA Security Rule) and 160.103 definitions, via Cornell LII

In this lesson

How models can leak what they learned, and what helps. Outline: 2.9.

Key points

• Subdomain 2.9 begins with data set and model privacy.
• NIST describes four privacy attacks on predictive models. In data reconstruction, the attacker tries to recover private information about an individual record from access to the model. In membership inference, they find out whether a record was in the training data.
• Membership alone can harm. NIST's example is a medical study of patients with a rare disease: just being in the training set reveals something.
• In property inference, the attacker learns global facts about the training data, such as the share of records with a sensitive attribute.
• In model extraction, they query a service to learn its architecture and parameters.
• LLMs add a plainer risk: OWASP warns they can expose sensitive information through their output.
• How real is model extraction? NIST reports research showing exact extraction to be impossible, and even a functionally equivalent model, which performs similarly, to be computationally prohibitive. It also records model-stealing attacks on online services, so don't treat it as theoretical.
• OWASP's mitigations for unbounded consumption include rate limiting and user quotas.
• NIST lists limiting queries too, but warns that well-resourced attackers can get round it.
• So is a trained model personal data? In December 2024, the European Data Protection Board said that models trained with personal data cannot, in all cases, be considered anonymous. For that, the likelihood of extracting personal data, and of obtaining it through queries, should be insignificant.
• What helps? Differential privacy is the rigorous definition NIST describes: it bounds how much an attacker can learn about any one record. It protects the training data, not the model itself.
• Data minimisation is a GDPR principle: keep what's adequate, relevant and necessary.
• ISC2 also points to homomorphic encryption and to purging residual training data from ephemeral storage.
• Be clear what differential privacy doesn't do. NIST says it mitigates data reconstruction and membership inference. It gives no guarantee against model extraction, and papers report negative results against property inference. One of the main practical challenges is setting its parameters, because you trade the level of privacy against accuracy.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST AI 100-2: Adversarial Machine Learning, a taxonomy; OWASP Top 10 for LLM and generative AI applications; EDPB Opinion 28/2024 on data protection aspects of AI models; Regulation (EU) 2016/679 (General Data Protection Regulation); ISC2: How is AI security incorporated into the CCSP domains (section of the outline page)

In this lesson

How to protect AI data sets and models against tampering, and how validation and verification differ. Then we decide what Aldermoor does with an unproven data set. Outline: 2.9. About 5 minutes.

Key points

• Poisoning attacks happen during the training stage and can cause availability or integrity violations.
• Data poisoning can target pre-training, fine-tuning or embedding data, and a backdoor can leave behaviour untouched until a trigger appears.
• Models from shared repositories can carry malware that runs when the model is loaded, through techniques such as malicious pickling.
• Our reading, since the outline doesn't define the terms: validation asks whether a data set or model is fit for the job, and verification asks whether it is what it claims to be, unchanged.
• For data: track origins and changes, use version control, vet vendors, filter anomalies and validate outputs against trusted sources.
• For models: use verifiable sources, and check signatures and file hashes.
• Track provenance, and continuously monitor the integrity of training data and model weights.
• Sanitising data and inspecting models both have limits against stealthy attacks and newer triggers, so red team as well.

A word of caution on "validation"

In the EU AI Act, "validation data" has a narrower meaning: data used to evaluate a trained system and tune it. Don't confuse that with validation as used in this lesson.

Aldermoor's decision

Our call for this fictional case: hold the vendor's data until its origin is shown, move the base model on because its hash matches, red team Scribe before launch, and limit writers on the training bucket to three named people.

The AI data protection plan workbook: Aldermoor's version to compare against, and a blank one for your organisation.

Sources

NIST AI 100-2: Adversarial Machine Learning, a taxonomy; OWASP Top 10 for LLM and generative AI applications; MITRE ATLAS (adversarial threat landscape for AI systems); NIST SP 800-218A: Secure Software Development Practices for Generative AI; Regulation (EU) 2024/1689 (Artificial Intelligence Act)

In this lesson

The 2025 OWASP Top 10 for LLM applications: the whole list first, then each risk in order, using Scribe. Outline: 4.1.

Key points

• The August 2026 outline names the Top 10 for Large Language Model Applications under common cloud vulnerabilities.
• OWASP publishes it, and here is the 2025 list, all ten. One: prompt injection. Two: sensitive information disclosure. Three: supply chain. Four: data and model poisoning. Five: improper output handling. Six: excessive agency. Seven: system prompt leakage. Eight: vector and embedding weaknesses. Nine: misinformation. Ten: unbounded consumption.
• Number one: prompt injection, when prompts alter a model's behaviour or output in unintended ways. It comes in two forms. Direct: a user's own prompt alters the model's behaviour, on purpose or by accident. Indirect: the model takes input from outside sources, such as websites or files, and content in them alters what it does, hidden or not.
• Jailbreaking is a form of injection that makes a model disregard its safety protocols. And OWASP warns that retrieval and fine-tuning don't fully mitigate it.
• Number two: sensitive information disclosure. That includes health records and security credentials, and an LLM can expose them through its output.
• You can restrict in the system prompt what data the model may return, but such restrictions may not always be honoured, and prompt injection can bypass them.
• Number three: supply chain, which you met in lesson 7.7. In machine learning, the risks go beyond code flaws, to third-party pre-trained models and data.
• OWASP says there are currently no strong provenance assurances in published models: a model card gives you information, but no guarantee of where the model came from.
• Number four: data and model poisoning, when pre-training, fine-tuning or embedding data is manipulated to introduce vulnerabilities, backdoors or biases. OWASP treats it as an integrity attack.
• A backdoor can leave the model's behaviour untouched until a trigger changes it, which makes it hard to test for.
• Number five: improper output handling, which is insufficient validation, sanitisation and handling of a model's output before it's passed downstream. The results can include cross-site scripting in a browser, or remote code execution on a back-end system.
• OWASP's advice is to treat the model as any other user, with a zero-trust approach, and to validate what it sends to back-end functions.
• Number six: excessive agency, when a system can take damaging actions on unexpected, ambiguous or manipulated output. The root causes are three words worth remembering: excessive functionality, excessive permissions and excessive autonomy.
• OWASP's example is an extension that only needs to read documents, but can also modify and delete them.
• Number seven: system prompt leakage, because those instructions can contain sensitive information that was never meant to be found. OWASP says the system prompt shouldn't be considered a secret, or used as a security control, and credentials don't belong in it.
• It recommends relying on systems outside the model instead.
• Number eight: vector and embedding weaknesses, in systems using retrieval-augmented generation, which combines a pre-trained model with external knowledge sources. In multi-tenant environments where users share a vector database, OWASP warns of context leakage between users or queries, and calls for strict logical and access partitioning.
• Number nine: misinformation, false or misleading output that appears credible. A major cause is hallucination, content that seems accurate but is fabricated. A related issue is overreliance, when people trust the output without checking it.
• OWASP calls for human oversight, with reviewers trained to avoid that overreliance.
• Number ten: unbounded consumption, when an application allows excessive and uncontrolled inference.
• In the cloud, that shows up on the bill, because attackers can exploit the cost-per-use model. But it can do more than run up a bill: OWASP lists denial of service, economic loss and model theft, and calls for rate limiting and user quotas.
• Our call: prompt injection and excessive agency. OWASP says it's unclear whether any fool-proof prevention for injection exists, and it recommends least privilege and human approval for high-risk actions.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; OWASP Top 10 for LLM and generative AI applications

What you're building

One workbook that records how an AI system's data and model are protected. Compare your answers with Aldermoor's, then fill in the blank copy for a system of your own.

What each sheet records

• Data sets: origin, vendor checks, version control, anomaly checks and who can write to each one. A row turns to Hold while any check reads No.
• Model artefacts: source, hash and signature checks, code on load, red team and monitoring. A row is cleared for launch only when none reads No.
• Decisions: each decision, the reason and who took it.
• Privacy tests: what you test, the threshold you set and the latest result.
• LLM risks: one row for each item in the OWASP Top 10 for LLM applications.
• Automation rules: which alerts and actions run automatically, using the test from lesson 7.3.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its dates and results are invented. Thresholds marked as set by Aldermoor are for your own organisation to decide. This is not legal advice.

Sources

OWASP Top 10 for LLM and generative AI applications

In this lesson

What Domain 1 covers, and what you'll build.

Key points

• Domain 1 is the foundation for the rest of the course: what cloud computing is, how it's put together, and the security ideas everything else builds on. It's seventeen percent of the exam.
• We'll take it in order: what cloud is, the reference architecture, security concepts, secure design principles, and how to evaluate a provider. AI and machine learning, also in this domain, have their own module.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

What makes a service cloud, and what it means for security.

Key points

• A cloud service is more than someone else's server. NIST's SP 800-145 gives the definition most people use. We'll take it in order: the definition, the characteristics, then the money.
• It describes on-demand network access to a shared pool of computing resources, which can be provisioned and released quickly with minimal management effort or interaction with the provider. Once the contract is signed, you serve yourself.
• NIST lists five essential characteristics. On-demand self-service means you provision it yourself, without speaking to the provider. That speed has a cost: shadow IT, where a team signs up with a card and security never hears about it.
• Broad network access means it's reachable over the network from many kinds of device. If you can reach it from anywhere, so can an attacker, so identity and encrypted connections matter more.
• Resource pooling means customers share the provider's resources through a multi-tenant model, and ISC2's outline names multi-tenancy in its own right. Tenants are kept apart by software, so a flaw or a bad access setting can expose another tenant's data.
• Rapid elasticity means capacity grows and shrinks with demand. Measured service means usage is metered, so you pay for what you use, and you can see what that is.
• That metering moves spending from capital expenditure, on servers and buildings, to operating expenditure. But someone still has to remove what's no longer needed, or you keep paying for it.
• Our call: no. There's no self-service, no elasticity and no metering, so by NIST's definition it isn't a cloud service, whatever the brochure says. Next: roles and activities.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-145: The NIST Definition of Cloud Computing; ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Who does what in the cloud.

Key points

• Before you can divide responsibility, you need names for the people involved. We'll take it in order: the roles, the reference architecture, then who does what.
• The customer buys and uses the service. The provider offers it, and that can be an internal IT team as easily as a public company. The customer owns its data, so it must review the security of every provider it uses.
• A partner is a third party that builds or sells services on a provider's platform, and can add support and consulting. A broker finds and packages services for you, sometimes from several providers. Vet a broker as you would any vendor, and take the same care over partners.
• Regulators don't regulate cloud as such. They regulate how data is handled, and those rules still apply once the data is in the cloud. So the customer must work out which rules apply, and choose or configure services to meet them.
• A reference architecture gives everyone a common map, so services from different vendors can be compared and fitted together. NIST's version, in SP 500-292, is vendor neutral. It's built around five roles: consumer, provider, auditor, broker and carrier.
• The consumer picks a provider, signs the contract, sets up accounts and configures the service. The provider builds and runs the service, including the buildings and their physical security.
• The auditor examines controls independently and reports on them. The broker aggregates, integrates and customises. The carrier provides the connectivity, and that's often an internet service provider.
• Our call: a cloud broker. Aggregation, integration and customisation are exactly a broker's three activities. Next: building block technologies.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The five technologies that make cloud possible.

Key points

• Five technologies make cloud possible. We'll take them in order: virtualisation, storage and networking, then databases and orchestration.
• Virtualisation lets one physical server host many virtual ones, and the hypervisor controls their access to the hardware. Containers go further: an application is packaged with what it needs, so it runs on any compatible platform.
• If an attacker breaks out of a virtual machine through the hypervisor, that's an escape, and it can reach other machines on the same hardware. Keeping the hypervisor secure and up to date falls to the provider.
• Providers often use a storage area network, which works at block level and looks like one disk, or network-attached storage, which works at file level. You mainly care about speed, integrity and space. When storage is reused, data remnants are a risk, and you can't wipe the disks yourself.
• Everything in the cloud is reached over the network, so it needs low latency and high bandwidth. On a public network traffic can be intercepted, so encrypt it. Some providers offer dedicated connections that avoid the public internet.
• With a cloud database, the provider usually handles the patching and tuning. In IaaS, though, you run whatever you install.
• Orchestration uses automation to make all those parts work as one, across data, processes and services. It's valuable whether you use one cloud or several, and it keeps complexity from getting out of hand.
• Our call: encrypt the data, then securely destroy the key when it's no longer needed. Any fragments left behind are unreadable. That's crypto-shredding. Next: service capabilities, categories and responsibilities.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What you buy, and what you still run.

Key points

• How much of the stack you run depends on what you buy. We'll take it in order: capabilities, categories, then who is responsible.
• Capability types are one way to look at it. An application capability lets you use an application over the network. A platform capability lets you build and deploy on it. An infrastructure capability gives you computing, storage and network to shape yourself. In none of them do you control the hardware.
• The three standard categories match them. In SaaS you use the provider's application. In PaaS you deploy your own on the provider's platform. In IaaS you run everything from the operating system up. You'll see other labels, like database as a service, but these three are the ones NIST defines.
• Security is always shared, and the line moves. The customer does most in IaaS and least in SaaS. But the customer stays responsible for its data in every model, and the provider for physical security.
• In SaaS, you still manage who has access and how data is shared. In PaaS, you also own the applications you build and their data. In IaaS, you own everything above the hypervisor, including patching the operating system.
• Don't assume. Each provider publishes its own model, and the details differ from one service to the next, so read the one for what you actually bought.
• Our call: the clinic's. In SaaS the customer controls who has access, so removing a leaver is on the customer, even when the provider runs everything else. Next: deployment models.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-145: The NIST Definition of Cloud Computing

In this lesson

Who owns the cloud, and who can get in.

Key points

• A deployment model answers two questions: whose cloud is it, and who's allowed in? NIST defines four, and a fifth pattern has joined them. We'll take them in order: public, private and community, then hybrid and multi-cloud.
• A public cloud is open to anyone who subscribes, and runs on a third party's systems. It now suits almost any organisation, but you depend on the provider's choices, including which services it decides to retire.
• A private cloud serves a single organisation, whether it's built in-house or hosted by a third party. The main advantage is control, and the main disadvantage is cost, because there's nobody to share it with.
• A community cloud is shared by organisations with common needs, often in the same industry, and access is limited to members. Each member still answers for what it shares.
• A hybrid cloud combines models, typically public and private. You might keep the most sensitive data private and put the rest in public cloud. Running two kinds of cloud is harder, and that difficulty creates risk, so be sure the benefit is worth it.
• Multi-cloud isn't one of NIST's four. It means using more than one provider, with a system spread across them. It can improve availability and reduce lock-in, but each provider works differently, so it's harder to run.
• Our call: community. It's shared by organisations with common requirements, and access is limited to members. Next: interoperability, portability, reversibility and lock-in.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How to keep the option of leaving.

Key points

• Every cloud decision is also a decision about how you'd leave. Four ideas help, and we'll take them in order: interoperability, portability, reversibility, then vendor lock-in.
• Interoperability means different platforms can talk to each other and exchange data. Different providers may have different security tools, which can leave gaps in monitoring. Well-designed APIs help, by giving a standard way in.
• Portability means moving. Data portability is moving data without losing any of it. Architecture portability is moving applications or systems without significant change or loss of service, and the term also covers running a service on many kinds of device. Containers have made moving services much easier.
• Reversibility asks a narrower question: once you've moved in, can you get back out without significant impact? That might mean another provider, or back on-premises. If leaving means weeks offline, you've got a problem.
• Vendor lock-in is what you get when there's no practical alternative to one vendor. It often comes from using features only that provider offers, or from exit costs and contract terms.
• You can reduce it. Use containers and portable designs, and run a cost-benefit analysis before adopting a unique feature. Sometimes the feature is worth it. Just make that a decision, and not an accident. State your requirements early, in the request for proposal.
• Our call: reversibility as well. Leaving is possible, but not without significant impact, and a long outage like that is a barrier that creates lock-in. Next: availability, resiliency, performance and service levels.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Whether the service is there when you need it.

Key points

• The shared considerations start with whether the service is there when you need it. We'll take it in order: availability, resiliency and performance, then service levels.
• Availability is the A in the CIA triad. The provider must keep the service available within the agreed levels, and if it doesn't, there should be a remedy. It also means having capacity for customers as they grow.
• Resiliency means carrying on when conditions turn against you. Providers use regions and zones for redundancy. You might use several zones, several regions, or even several providers, and going multi-region raises the cost quickly.
• Performance is measured against what the agreement says, and it's generally high at the major providers. The weak point is usually the connection: whether the network is up and fast enough, and the provider may have no say in that.
• A service level agreement states the required performance, and it's part of the contract. Tighter terms cost more. Some providers offer fixed levels you pick from, while large customers may negotiate. Negotiation rarely pays for smaller organisations.
• Remember the shared part. Different services come with different service levels, and it's up to you to design your use of them to meet your own availability needs.
• Our call: Aldermoor. The provider met what it agreed. It was Aldermoor's job to design for what it had promised, for instance with a second zone. Next: security, privacy, governance and audit.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Staying in control of what you've handed over.

Key points

• The other shared considerations are about control. We'll take them in order: security and privacy, governance and maintenance, audit and regulation, then outsourcing.
• Big providers have resources most organisations could never afford. But they're also attractive targets, and your data's physical home could be far away, so find out where it is. Privacy brings owners, called controllers in GDPR terms, processors and data subjects into it, and the owner stays accountable.
• Cloud governance uses the same tools as on-premises governance: policies, procedures, controls and oversight. Without it, cloud use quickly outgrows what you can manage, and the bill grows with it.
• Maintenance follows the stack: each party looks after its own part. Updates in SaaS or PaaS may reach you without warning, and something can break. In IaaS you have far more control over testing and timing.
• Providers rarely let customers audit them. Independent third parties assess the provider, and you read the reports. Regulation comes in three forms: laws, contracts such as PCI DSS, and standards that organisations adopt.
• Moving to the cloud is outsourcing, so you give up some control and visibility. In SaaS you may not be able to tell whether a patch has been applied. Staff or data in another country can create legal problems as well.
• Our call: independent audit reports, such as a SOC 2 report, under a nondisclosure agreement if required. Customer audits are rare, and third-party assessments exist for this reason. Next: related technologies.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation)

In this lesson

Data science, machine learning, AI and blockchain in the cloud.

Key points

• Some technologies aren't part of the cloud's definition, but the cloud is changing what they can do. Here are the first three, in order: data science, machine learning and AI, then blockchain.
• Data science draws useful information out of very large volumes of data, which the cloud's scale makes affordable. In security, a model can learn what's normal for a system and flag what isn't.
• The data has to be good. Training on poor data gives unreliable results. And a data warehouse or data lake gathers a lot of sensitive information in one place, so it's an attractive target.
• Machine learning lets a system get better with experience, without being reprogrammed. The security concerns are the data, which needs tight access control, and how it's used, including decisions made about people. Under Article twenty-two of GDPR, people generally have the right not to be subject to significant decisions made solely by automated means, with some exceptions.
• AI systems infer from their input how to produce outputs such as predictions or decisions, and security tools already use them to help analysts cope with huge volumes of data. Module seven covers this in depth.
• A blockchain is a distributed ledger, where records are linked cryptographically and held across many computers. Participants can add new records and verify old ones, but can't change them, so it's a way to achieve data integrity. Tying yourself to one provider's blockchain can bring lock-in.
• Our call: a significant decision about a person, made with no human involved. That raises the concern GDPR addresses in Article twenty-two. Keep a person in the loop, and take advice. Next: more related technologies.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); Regulation (EU) 2024/1689 (Artificial Intelligence Act)

In this lesson

The Internet of Things, containers, quantum, edge and confidential computing.

Key points

• Here's the second group, in order: the Internet of Things, containers and quantum computing, then edge and confidential computing.
• Internet of Things devices have little storage but a constant connection, so the cloud is a natural home for their data. They're often built without much thought for security, may never be updated, and often can't run security tools. A device may be wanted for a botnet and not for its data.
• Containers have no guest operating system. A runtime on the host gives each container what it needs, so they're smaller, start faster and move easily between providers. We'll get to securing them shortly.
• Quantum computing is still largely at the research stage in the cloud. The concern is that future quantum computers could defeat today's asymmetric algorithms, which is why a move to post-quantum algorithms is planned.
• Edge computing processes data where it's collected. That can reduce single points of failure and save bandwidth. But edge devices may be too limited for normal controls, and they're often somewhere with little physical protection.
• Confidential computing protects data while it's being processed. A trusted execution environment decrypts data only for an authorised program, and blocks everything else, even a cloud administrator.
• Our call: confidential computing. Encryption at rest and in transit doesn't cover data in use, and a trusted execution environment does. Next: security principles.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-57 Part 1 Rev. 5: Key Management

In this lesson

What security protects, and the ideas behind it.

Key points

• Everything from here on protects the same three things. They're called the CIA triad, and we'll take them in order: confidentiality, integrity, availability, then what goes beyond them.
• Confidentiality means preserving authorised limits on who can see information. A loss of confidentiality is unauthorised disclosure. Encryption and access control are the usual defences.
• Integrity means guarding against improper change or destruction. Hash values are the usual way of checking for it, because a change to the data changes the hash.
• Availability means timely and reliable access. A loss of availability is a disruption, and in the cloud that can be caused by your provider, or even another tenant.
• A few more ideas sit alongside these. Authentication proves who you are, and authorisation decides what you may do. Accountability ties actions to people, and non-repudiation stops someone denying what they did.
• One more principle runs through this whole domain. Least privilege means allowing only the access that's needed to do the job, and no more.
• Our call: mainly availability, because access has been disrupted and nobody has seen the data. The unauthorised change is an integrity loss too. If attackers had copied the records as well, confidentiality would be hit. Next: cryptography and key management.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST FIPS 199: Standards for Security Categorization of Federal Information and Information Systems; NIST SP 800-53 Rev. 5: Security and Privacy Controls; NIST SP 800-207: Zero Trust Architecture

In this lesson

Protecting data you can't touch, and managing the keys.

Key points

• In the cloud, your data crosses networks and lives on disks you'll never touch. Cryptography is how you protect it anyway. We'll take it in order: why it matters, the three types, then managing keys.
• Data in transit moves between you and the provider. Data at rest sits on shared disks that you can't securely wipe. Both need encrypting, and both need integrity checks as well.
• Symmetric algorithms use the same key to encrypt and decrypt. So anyone who needs to read the data needs that secret, and it mustn't reach anybody else.
• Asymmetric algorithms use a key pair, one public and one private. A public key can be used to encrypt a key for its owner to decrypt with the private key. A private key can create a digital signature that the public key verifies.
• Hashing is the third type. It turns data of any length into a fixed-length value, which you use to check integrity.
• Key management decides whether all this works. Three decisions matter: where the keys live, whether you or the provider creates and runs them, and whether a managed service does that work.
• A key management service keeps keys separate from the data, so a breach of the data alone is less serious. Put the keys next to the data, and that benefit is gone. And someone still has to oversee the service.
• Our call: yes. Anyone who gets into that bucket gets the data and the keys, so the encryption protects nothing. Store them separately, with logging. Next: public key infrastructure.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-57 Part 1 Rev. 5: Key Management

In this lesson

How you know a public key is genuine.

Key points

• Asymmetric encryption has a problem: how do you know a public key really belongs to who it claims? Public key infrastructure, or PKI, is the answer. We'll take it in order: the parts, validating a certificate, then revocation.
• A certificate binds a public key to its subject, and it's signed by a certification authority, or CA. The end entity is whoever the certificate is for, such as a website. A registration authority is an optional helper, to which a CA can delegate some management tasks.
• Certificates and revocation lists are stored and distributed through a repository. Together, these parts let a stranger trust a key, because they trust whoever signed it.
• When your browser connects to a site, it receives a certificate and works along a chain, from that certificate up to a trust anchor, a CA it already trusts. Which CAs to trust is a local decision.
• At each link, it checks the signature, that the certificate is within its validity period, and that it hasn't been revoked. Any failure, and the path isn't valid.
• A certificate can be cancelled before it expires. CAs publish that status, through a certificate revocation list or the online certificate status protocol.
• Our call: revoke it now and get a new certificate with a new key. Waiting leaves a stolen key trusted for eight months. Next: identity and access control.

Sources

IETF RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

In this lesson

Who controls access to what.

Key points

• Access control is a shared job, and each side has its part. We'll take it in order: who controls what, user access, privileged access, then service access.
• Physical access to the provider's buildings is entirely the provider's job. Administrative control, meaning the policies and the reviews, belongs to the customer. Technical controls are where the two overlap.
• User access is the day-to-day work. The customer provisions and removes users, and decides what level they get, even when the identity system is provided as a service. Access logs may be kept by one side and reviewed by the other, so agree who does what.
• Privileged accounts can add users, read confidential data and change systems, so a compromise is serious. That justifies extra controls: stronger authentication, separate admin accounts and more frequent reviews. Grant only what's needed, in line with least privilege.
• Service access is the provider's own access to your data. Its staff need to get to infrastructure for patching and support.
• You can limit it with keys you control, so administrators see only encrypted data, or with confidential computing. Some providers publish transparency reports. And if the risk is still too high, choose a different deployment model.
• Our call: encryption at rest with customer-controlled keys, so administrators see only ciphertext on disk. For data in use, add confidential computing. Vetting helps, but it's a promise, and this is a control. Next: data and media sanitisation.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-53 Rev. 5: Security and Privacy Controls

In this lesson

How to dispose of data on disks you don't own.

Key points

• You can't shred a disk you don't own. We'll take it in order: the problem, overwriting, then cryptographic erase.
• On-premises, you decide how and when media is wiped or destroyed. In the cloud, the provider won't let you near the disks, and your data is moved and copied so often that you couldn't say which disks hold it.
• Deleted space is marked for reuse, and eventually new data is written over it. But there's no set timetable, so fragments can linger for some time. Don't rely on it for sensitive data.
• Cryptographic erase destroys the keys, so the data stays on the disk but can't be read. It's also called crypto-shredding. For this to work, the data must already be encrypted, and every copy of the key must be gone.
• If that still isn't enough for your most sensitive data, keep it on storage under your own physical control.
• Our call: it can't promise a physical wipe, because it doesn't control the drives. It can offer cryptographic erase, with a record of when the key was destroyed. Say so in the contract up front. Next: network security.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Security groups, inspection, geofencing and zero trust.

Key points

• If you can reach your cloud over a network, so can an attacker, unless you control the path. We'll take it in order: security groups, traffic inspection, geofencing, then zero trust.
• A network security group is a set of rules that acts like a virtual firewall for a group of resources. The customer usually configures it. Old firewall habits still apply: deny by default, and review what you've allowed.
• Firewalls work by inspecting traffic and deciding whether to allow it. Web application firewalls go further, examining requests to a web application or its APIs.
• Traditional monitoring sat at the network's entry and exit points, watching ingress and egress. With a mix of cloud services, there's no single edge to watch, so bring the provider's monitoring together in one place, such as a SIEM.
• Geofencing controls access according to location. A cloud firewall can match requests by country, and sign-in policies can treat countries as a condition. Location usually comes from the IP address, and a proxy or VPN changes what's seen, so treat it as one signal among several.
• Zero trust never assumes something is safe because of where it is. Older designs trusted everything inside the perimeter. Under zero trust, every request is verified, all communication is secured, and being on the corporate network earns no trust by itself.
• Our call: verify every request. Network location alone doesn't imply trust, and an attacker who gets inside would otherwise reach it freely. Next: virtualisation, containers and serverless.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); AWS WAF Developer Guide: Geographic match rule statement; Microsoft Learn: Conditional Access network assignment (locations); NIST SP 800-207: Zero Trust Architecture

In this lesson

Keeping workloads apart on shared hardware.

Key points

• Shared hardware only works if workloads stay isolated from each other. We'll take it in order: hypervisors, containers, then ephemeral and serverless computing.
• A type one hypervisor runs directly on the hardware, and it's generally faster and more secure. A type two runs on top of an operating system. It's easier to set up, but generally less secure.
• Compromise the hypervisor and you control every virtual machine on it. So whoever runs it should limit admin access and its network access, log and audit it all, and patch quickly.
• Containers are isolated from the host, but poor identity management, misconfiguration and software bugs can undo that. A specialised container operating system reduces the attack surface. And your tools must be designed for containers.
• Ephemeral resources exist only while they're needed, so there's less time to attack them. But you can't really run traditional agents on them. Security comes from the definition file that creates them.
• Serverless still has servers, but the provider runs them and you just supply code. You may avoid the weaknesses of a traditional operating system. You do lose those traditional controls, so authentication of API calls matters more.
• Our call: not well. They don't live long enough, so put the security into the definition file, and use controls built for this kind of workload. Next: common cloud threats.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The threats the cloud shares and the ones it adds.

Key points

• Every threat you already know still applies, and the cloud adds its own. We'll take it in order: the lists, the old threats, then the cloud's own.
• The Cloud Security Alliance publishes a regular list of top cloud threats. An earlier edition was called the Egregious Eleven. The twenty twenty-two edition, based on a survey of industry experts, is the Pandemic Eleven.
• Some are common to all computing, such as weak access controls and insiders. Our reading: access control is still the first thing to get right.
• Others come from the way the cloud works. A lack of cloud security architecture and strategy shows up in immature organisations, and in those with a lot of shadow IT.
• Earlier editions put data breaches, misconfiguration and weak identity near the top. They connect to everything in this domain: what you configure, who has access and how well you can see.
• Our call: shadow IT. No one means harm, but the data has left the controls that protect it. Bring it under management, and find out why the approved tool wasn't good enough. Next: security hygiene.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); CSA Top Threats to Cloud Computing (landing page)

In this lesson

Patching, baselining and immutable architecture.

Key points

• Most security isn't clever, it's consistent. We'll take it in order: the basics, patching, baselining, then immutable architecture.
• The basics are vulnerability scanning, penetration testing, keeping an asset inventory, and backups you can restore from.
• Patching matters more than any other hygiene task. Fixed deadlines can be too slow, so faster cycles are advised. Automatic patching is increasingly a best practice.
• And patching follows the stack. In SaaS, it's the provider's. In PaaS, the provider patches the platform and you patch what you put on it. In IaaS, the provider patches what lies under your virtual machines, and you patch the rest.
• A baseline is a known configuration, usually a hardened one, meaning a system set up in a secure state. New systems must follow it, and infrastructure as code makes that repeatable and removes manual mistakes. Then review running systems against it, because they drift. Provider tools can alert you.
• Immutable architecture means an environment is never altered once it's built. To patch, you tear it down and build a new one. Any drift goes when you rebuild, and elasticity makes that practical.
• Our call: the change bypassed the definition, so it breaks the baseline and it'll vanish at the next rebuild. Put the fix in the code and rebuild. Next: designing for the data lifecycle.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Following the data through its six phases.

Key points

• Many cloud services never go through a traditional development lifecycle, so it helps to follow the data instead. It has six phases. We'll take them in order, in pairs: create and store, use and share, then archive and destroy.
• Create is when content is made or changed, and that's the moment to label it and possibly encrypt it. Store generally happens at the same time, and the choice of location depends on how sensitive the data is.
• Use is handling: viewing, processing and changing. This is where data lives most of the time, and where most controls do their work. Share is exchange between parties, which needs authorised, authenticated recipients, encryption and hashing.
• Archive is long-term storage, with a retention schedule. Keep archived keys, or you won't be able to read it later. Destroy is the end, and the method must meet your requirements.
• There's a chance of a breach at every phase. Encryption helps throughout, and data loss prevention can identify and classify what you hold. Domain 2 covers the detail.
• Our call: old archives can't be read. If you rotate keys, you must keep a backup of the keys so that archived data stays accessible. Next: business continuity, disaster recovery and business impact analysis.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Designing for failure and justifying the spend.

Key points

• Domain 3 teaches the plans in depth. Here's how the cloud changes the design. We'll take it in order: cloud continuity, impact analysis, then cost and return.
• Availability zones protect against a data centre failing, but a major disaster could take out a whole region. So you can design across zones, or across regions, for the greatest availability.
• Multi-region costs rise quickly. So many organisations spread only their most critical systems, and leave the rest in one region. Some save more by keeping only backups and rebuild definitions in a second region. Remember that a cloud backup is only useful if you've got the network to reach it.
• A business impact analysis identifies what's critical, and what happens if you lose it. That lets you spend limited resources where they matter most. The same asset can be critical for one organisation and minor for another.
• Cloud isn't always the right answer, and a cost-benefit analysis helps you decide. The benefits are resilience and savings. The costs include losing control of the physical infrastructure and waiting on the provider during an outage.
• Return on investment measures the value you get for what you spend. In security, it's usually shown as risk reduction in financial terms, or as efficiency gained through faster response and automation.
• Our call: show the return. Set the time saved and the risk it reduces against the twelve thousand pounds. If the numbers don't support it, don't buy it. Next: design patterns and DevOps security.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Frameworks to build on, and security in DevOps.

Key points

• You don't have to design from a blank page, and security should be built in from the start, which is the idea of secure by design. We'll take these in order: security principles, well-architected frameworks, enterprise architecture, then DevOps.
• The security principles the outline calls SANS start with inventorying assets, including cloud providers. Then you record risks and apply mitigations. They're vendor neutral, so they work with any provider.
• Each major provider publishes a well-architected framework, a set of pillars of best practice. Security, reliability and performance are common to them, but the guidance is specific to that provider.
• The Cloud Security Alliance's Enterprise Architecture aligns IT with what the business needs. It has four domains, one of which is security and risk management.
• DevOps joins development and operations to deliver software faster. Security used to come at the end. Shifting left moves it earlier, so testing starts while the code is being written, and bugs are cheaper to fix.
• A DevSecOps team embeds security through the lifecycle, so it doesn't become a bottleneck at the end. NIST runs a working group on this.
• Our call: shift it left. Test while the code is being written, when flaws are cheaper and quicker to fix, and the release date is safer. Next: evaluating cloud service providers.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Comparing providers against objective criteria.

Key points

• Compare providers against objective criteria, and it's a fair contest. We'll take it in order: why criteria matter, the standards, then government schemes and registries.
• Some standards are voluntary, and a provider picks them to show its capabilities. Some are required for certain markets. A SOC 2 Type II report, for example, is voluntary, while PCI DSS is required for handling payment cards.
• ISO 27001 sets up an information security management system. ISO 27017 adds guidance on applying the controls to cloud services, and ISO 27018 adds guidance on protecting personal information. They're widely accepted internationally.
• PCI DSS has twelve requirements to reduce payment fraud. It predates widespread cloud use, but its requirements apply there too. Outsourcing payment processing can shift some of the risk, but you'd still have your own controls to run.
• Governments have their own schemes. In the US, FedRAMP sets the controls and the assessment for providers serving federal agencies. In the UK, government buyers can pick services from the G-Cloud marketplace.
• CSA's STAR registry is voluntary and has two levels. Level one is a self-assessment. Level two adds a third-party audit, so it gives you more assurance.
• Our call: level two, because an independent auditor has assessed the controls. A level one entry is the provider's own account. Next: product certifications.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What Common Criteria and FIPS tell you, and what they don't.

Key points

• Some certificates cover a whole service. These two cover a smaller part of one, such as a firewall or a cryptographic module. We'll take it in order: what they certify, Common Criteria, then FIPS.
• Certificates like FedRAMP or ISO 27001 speak for a provider's overall capability. Product certificates apply to one piece. They're for organisations with very specific needs.
• Common Criteria is an international way to evaluate security products. A protection profile lists the security requirements expected of one kind of product. That lets you compare like with like.
• An evaluation assurance level runs from one to seven, and measures how rigorously the product was tested. A higher level means more rigorous testing, and that's a different thing from being more secure. An independent lab does the testing.
• FIPS 140 validates cryptographic modules for US government use. FIPS 140-3 supersedes the earlier version. Validation applies when a module is configured as it was tested, so that usually means turning on only validated algorithms.
• Not being validated doesn't make a module insecure. Each organisation must decide what level of assurance it needs.
• Our call: no. The level tells you how much it was tested, not how secure it is. Check that the protection profile matches what you need, and then decide what level you require. Next: your deliverable, a shared responsibility matrix.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST FIPS 140-3: Security Requirements for Cryptographic Modules

What you're building

One workbook that pulls Domain 1 together for a cloud service: what you buy and sell, who is responsible for each layer, who has access, how you'd leave and what evidence you've seen. Compare your answers with Aldermoor's, then fill in the blank copy for your own organisation.

What each sheet records

• Service map: each service, its category, its deployment model and your role. A deployment model depends on whose cloud it is and who's allowed in, and service categories differ in how much the customer controls.
• Responsibility matrix: who handles each layer of the stack for each service. Whatever the service model, the data you put in the cloud remains your responsibility, the provider generally looks after the lowest layers, and the items between vary by service model.
• Access: user, privileged, service and physical access, with the controls and reviews for each. Physical access is the provider's job, and the customer provisions and removes users.
• Exit: how you'd leave each service, and any lock-in you've accepted. Provider-specific features can cause vendor lock-in, and a cost-benefit analysis can guide decisions about them.
• Provider evidence: the reports and certificates you reviewed. Providers rarely allow customers to audit them, so independent third-party assessments are provided instead.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its services, owners and dates are invented. Each provider publishes its own responsibility model, so check yours before relying on this layout.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Each of the eleven CSA threats, and what to do about it.

Key points

• Lesson one point eighteen gave you the headlines. Here are the Cloud Security Alliance's eleven in detail, from its Egregious Eleven edition. The twenty twenty-two edition is called the Pandemic Eleven, so check the current list when you use it. We'll take them in order, in four groups: data and configuration, identity and access, interfaces and the provider, then visibility and abuse.
• A data breach is mainly an attack on confidentiality, and it can bring fines, liability and lost trust. Record what data you hold and how it's protected, then test those protections.
• Misconfiguration undoes good design. The strongest settings protect nothing until someone applies them. Check the settings at deployment, and review each change for its effect on security.
• Without a security architecture and strategy, unplanned growth can eat the money the move saved. Write down who is responsible for what, and get executive backing.
• Insufficient identity, credential, access and key management often stems from complexity. Resources spread across providers can't all use one identity service, so passwords multiply and access logs scatter. You need a planned identity strategy, and sound management of keys and secrets.
• Account hijacking is an attacker using valid credentials. Admin and service accounts are the prize. Cloud services face the internet, so a thief can use stolen credentials from almost anywhere. Keep admin logins separate from everyday ones, widen multifactor authentication, log more closely and teach people to spot phishing.
• Insiders may be malicious or just careless, and they already have access, so the impact can be high. Train people, audit closely, and put emergency admin rights behind a break-glass procedure.
• Cloud services are run through APIs and web consoles that are reachable over the internet. Insecure ones open up new weaknesses, so require strong authentication, and test those interfaces during development.
• A weak control plane leaves the people running the environment with too little oversight of how it's configured and managed. Follow your provider's security reference architecture, and keep production apart from development and test.
• Metastructure and applistructure failures are weaknesses in what the provider supplies, such as standard images and APIs, and whatever you build on them inherits those weaknesses. You can do little to fix them directly, so look for evidence of the provider's secure development, its testing and third-party verification.
• Limited visibility comes in two forms. Unsanctioned use is shadow IT. Sanctioned misuse is an approved service used outside its approved purpose. Training and governance help, and so do data loss prevention tools.
• Abuse and nefarious use is attackers turning cheap cloud capacity against others, say to flood a service or send phishing. Providers carry most of the controls. For you, cheap capacity changes what attackers can afford, so plan for it and revisit your risk estimates.
• Our call: limited visibility, in the form of sanctioned misuse. The tool is approved, but not for that data. Tighten the rules, train the team and consider data loss prevention. Next: the module quiz.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); CSA Top Threats to Cloud Computing (landing page)

In this lesson

What Domain 2 covers, in what order, and the deliverable you'll build for Aldermoor.

Key points

• Domain 2 is about protecting data in the cloud. Many security duties are shared with the provider, but for the data itself, the customer stays accountable.
• Domain 2 is 20% of the exam.
• We'll take it in order: the data lifecycle, storage, the technologies that protect data, discovery, classification, rights management, retention and deletion, and finally the logging that makes data events accountable.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

The six phases of the data lifecycle, how dispersion spreads data, and why a data flow diagram matters.

Key points

• Three ideas, in order: the data lifecycle, data dispersion, then data flows.
• The lifecycle has six phases: create, store, use, share, archive and destroy. It's roughly linear, data can sit in more than one phase at once, and each phase brings its own risks.
• Create is when data is first entered, or modified. Classify it here, by its owner or by the system it lives in. Store means saving it somewhere retrievable. Protect it in transit on the way in, then with access controls, encryption and backups once it's stored.
• Use is the busiest phase, where data faces the most risk: rights management, data loss prevention, access reviews and logging all apply. Share means granting access to others. Plan access in advance, and use tools that catch sharing that shouldn't happen.
• Archive moves data you must keep, but don't use, to cheaper long-term storage. Watch for rotated keys, formats nobody can read any more, and media that degrades. Destroy removes data you no longer need and no longer have to keep. In the cloud, where you can't reach the disks, cryptographic erasure may be the only practical option: destroy the key, and the data can't be read.
• Data dispersion breaks data into pieces spread across many disks, with erasure coding so lost pieces can be rebuilt. That helps availability, and no single disk holds a complete copy. But pieces may land in other countries, under other laws, and the extra processing can add delay. Most providers let you restrict where data goes.
• A data flow diagram shows how data moves between components, regions and even providers. It reveals risks, such as data crossing borders or reaching a system with weak controls, and some compliance frameworks require one that records details such as where data flows.
• Our call: check where the copies would go. Global replication can move EU patient data to countries with different laws, so keep it within approved regions, and update the data flow diagram.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization

In this lesson

The storage types each cloud service model offers, and where Aldermoor keeps what.

Key points

• Cloud storage comes from pooled resources, so it can be hard to see exactly where data sits. Each service model offers its own storage types, and providers often brand them differently.
• IaaS first. Long-term storage is built to last, for records and archives, sometimes with options that stop data being changed. Ephemeral storage is the opposite: it disappears when the instance stops. Raw storage hands one virtual machine its own dedicated slice of the pool.
• Two more in IaaS. Object storage keeps whole objects, usually files, along with metadata, so applications aren't tied to particular disks. Volume storage acts like a virtual drive plugged into the machine, and its blocks may be spread over many disks.
• PaaS. A disk can be attached to the platform, with speed and durability you choose. Databases are both a storage type and a service, usually multitenant and reached through APIs. And blob storage holds unstructured data, like images and documents, reached by a URL.
• SaaS is the most abstracted. Information storage and management keeps data you enter through a web interface. Content and file storage holds files in the application. And a content delivery network places copies close to users, for speed.
• Most storage is reached through APIs, so one store can serve several service models, and even users on the internet. That's convenient, and it means the API's access controls matter as much as the storage itself.
• Our call: not for anything you need to keep. Ephemeral data is lost when the instance stops, so save uploads to durable storage, such as the object store.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The threats stored data faces in the cloud, and the control that runs through them.

Key points

• Stored data faces the same basic threats anywhere, across all three security goals. Unauthorised access threatens confidentiality, improper changes threaten integrity, and lost connectivity threatens availability. But tools built for your own data centre may not work in the cloud.
• Unauthorised access: the customer controls who can reach its data, and the provider must keep tenants logically separated. Unauthorised provisioning: storage is so easy to create that shadow IT spreads, adding cost and blind spots the security team can't protect.
• Regulatory noncompliance: a service that misses a requirement risks fines, and fails to protect the data the rule was written for. Jurisdiction: many storage services replicate globally by default, which can break laws on transfers. Denial of service: no network, no data.
• Now loss and damage. Corruption or destruction, from human error, insiders, failures or disasters. Theft or loss of media, which the provider guards physically and you blunt by encrypting. And improper disposal of old drives, again mainly the provider's job, with your encryption as a backstop.
• Malware and ransomware also reach cloud storage, including well-known collaboration apps. Access controls and antimalware help prevent it; backups and versioning help you recover.
• A pattern runs through these: where the provider holds the hardware, your strongest control is encrypting the data with keys you keep away from it.
• Our call: treat it as unauthorised provisioning. Find the owner, check its access and location, and bring it under control or delete it. Storage the security team doesn't know about can't be protected.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How encryption works, how to manage keys, and how where you encrypt and who holds the key decide what you're protected from.

Key points

• Encryption transforms data with an algorithm and a key, so it can't be read without the key. Modern algorithms, like AES, would take more time and computing power to break than almost any attacker has.
• Kerckhoffs' principle says a system should stay secure even if everything but the key is public. So the key is what you protect, and keys deserve your highest classification.
• NIST's key management guide splits a key's life into four phases: pre-operational, operational, post-operational and destroyed.
• Protect keys at every stage: create them from strong random inputs; store them in a vault or hardware device, with escrow copies; use them under access control and accountability; share them carefully; archive the ones old data still needs; and destroy the ones you no longer need, or that are compromised.
• FIPS 140-3 is the US standard for validating cryptographic modules, and it's recognised widely. Many providers offer cloud hardware security modules validated against it.
• Where you encrypt decides what you're protected from. Storage-level encryption, with provider keys, protects against stolen disks, but provider staff could still read the data. Volume-level, with your keys, keeps the provider and other tenants out, but not an attacker on your instance.
• Higher up: object-level encryption, ideally with keys you control for valuable data. File-level, in apps like Word or Acrobat, often tied to rights management. Application-level, where the app encrypts before storing. And database-level, including transparent encryption of columns, tables or the whole database.
• Who holds the key matters as much as where you encrypt. Bring your own key lets you keep control, at the cost of more skills and resources, and it suits organisations using several providers or needing physical control of their hardware security modules.
• Our call: no. Storage-level encryption with provider keys protects against stolen disks, but provider staff could still read the data. Use keys Aldermoor controls, ideally in a dedicated cloud hardware security module, at the volume, database or application level.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-57 Part 1 Rev. 5: Key Management; NIST FIPS 140-3: Security Requirements for Cryptographic Modules

In this lesson

How to manage keys, secrets and certificates, from sprawl to cryptoperiods.

Key points

• Security systems run on credentials: encryption uses keys, access control may use shared secrets, and certificates prove identity. Managing all three is secrets management.
• Secrets sprawl, much as passwords do, and they often belong to non-human accounts: API keys and device certificates. Never hard-code secrets, or keep them in code repositories or scripts. Use a management tool that stores them securely and hands them to programs only when needed. And start with a discovery and inventory of the secrets you have.
• Keys belong in an encrypted vault that asks for multifactor authentication or a long passphrase. Secrets must be stored so that anyone eavesdropping on traffic can't pick them up too, with tight access control.
• Certificates are public, so confidentiality matters less than validity. A well-run public key infrastructure issues them only to trusted parties. Certificates used as access tokens may need protecting like keys.
• For all three: log every request and use, watch the logs for anything unusual, and review access to the secrets manager as often as your most sensitive systems. Generate them with tested random number generation and store new ones securely.
• Keys also have a cryptoperiod: the time a key is authorised for use. NIST suggests limits by key type, for example about one to three years at most for a private signing key, so keys are replaced on schedule.
• Our call: treat the key as exposed. Revoke and replace it, move the new one into the secrets manager, remove the old one from the repository, and check the logs for any use of the old key. Secrets should never live in code repositories, private or not.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-57 Part 1 Rev. 5: Key Management

In this lesson

How hashing proves integrity, and how digital signatures add non-repudiation.

Key points

• Hashing is mainly about integrity. A hash function takes data of any length and produces a short, fixed-length value, like a fingerprint. Hash it again later and compare: if the values differ, the data has changed.
• We'll take it in order: integrity, then non-repudiation.
• Hashes check that backups and copies are accurate, that messages arrived unchanged, and that key system files haven't been altered, which is file integrity monitoring.
• Choose a strong function that resists collisions, where two different inputs give the same hash; a collision means the hash can no longer prove integrity.
• NIST's key management guide lists SHA-2 and SHA-3 hash functions by their security strength.
• Hashing is one-way: you can't turn the hash back into the data. That's what separates it from encryption, which is designed to be reversed with the key.
• Now non-repudiation. A digital signature combines a hash with asymmetric keys. The signer hashes the data and signs the hash with their private key. The receiver hashes what arrived, checks the signature with the signer's public key, and compares. A match shows both integrity and source.
• Signatures matter when you bring third-party software into the cloud: verify the signature before you deploy it.
• Our call: it isn't encryption, because a hash can't be reversed with a key. And it may not be enough: a name's hash can be matched by hashing a list of known names. Use the de-identification methods in the next lesson instead.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-57 Part 1 Rev. 5: Key Management; ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Obfuscation, masking, anonymisation and tokenisation, and how pseudonymisation differs under the GDPR.

Key points

• Sometimes data is needed outside its main use, such as live records copied for testing. Obfuscation removes or replaces the sensitive parts.
• We'll take it in order: obfuscation methods, masking, anonymisation, then tokenisation.
• Methods include substitution, swapping in realistic values; shuffling, moving values between rows; value variance, nudging numbers and dates; and deletion or redaction. Encryption is possible, but encrypted data is no use for testing. Good obfuscation keeps data realistic, such as valid postcodes.
• Masking hides part of the data from users who don't need it all, such as showing only the last three digits of a patient's NHS number. The full value stays stored, and showing it may need the user to sign in again. Watch free-text fields: an NHS number typed into a clinician's note won't be masked.
• Anonymisation removes direct identifiers, like a name or NHS number, and indirect ones, like a postcode or an exact date of birth, that could be combined to identify someone. It's meant to be permanent. Indirect identifiers are the hard part.
• Pseudonymisation is different: it's meant to be reversible. Under the GDPR, the data can't be tied to a person without additional information kept separately and protected. So pseudonymised data is still personal data; the GDPR's recitals say so directly.
• Tokenisation replaces sensitive data, such as a card number, with a token that's of little use to a thief. Only a tightly controlled tokenisation service can map it back. It's a recommended control for PCI DSS, but any sensitive data can be tokenised.
• Our call: no, it's pseudonymised, because the lookup table can reverse it. It's still personal data, so protect it that way, and keep the table separate and locked down.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2016/679 (General Data Protection Regulation)

In this lesson

How data loss prevention discovers, monitors and enforces, and what changes in the cloud.

Key points

• Data loss prevention, or DLP, finds, inventories and controls the use of sensitive data. It's detective, preventive and corrective at once. Many organisations roll it out in phases, one function at a time.
• Discovery scans the organisation's storage, from file shares and databases to collaboration and cloud services, and identifies sensitive data by pattern, such as card or social security formats, or by your own labels. The result is an inventory. Scanners often run with privileged credentials, so lock down who can use them.
• Monitoring is the most important part. In motion, a network DLP watches traffic at a gateway, but it can't read encrypted traffic, so agents or proxies scan before encryption. At rest, it checks storage for data in the wrong place. In use, endpoint agents watch what users do on their devices.
• Placement matters. A DLP on the office network can't see remote workers who aren't connected to it, and some tools can't monitor newer apps.
• Enforcement applies rules: alert the user, or block the action, such as uploading a patient list to personal cloud storage. Blocking can stop a breach, but a false positive can stop legitimate work. Investigate alerts; they're a useful source of incident detection.
• In the cloud, you often can't install agents in PaaS or SaaS, and some services don't allow scanning, so look for cloud-native DLP. Weigh the cost too: scanning takes time and endpoint resources.
• Our call: start with alerts and tune them. Blocking on a broad pattern will catch legitimate clinic emails, and a false positive can stop real work. Phase in blocking once the rules are accurate.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Discovering sensitive data in structured, unstructured and semi-structured data, and why location matters.

Key points

• Data discovery means two things. For security, it's finding and inventorying sensitive data, which is the job of DLP tools. For the business, it's finding trends in data, and the insight, models and tools that produce it become valuable assets to protect too.
• We'll take it in order: structured, unstructured, semi-structured, then data location.
• Structured data follows a consistent format, such as database columns. Discovery is easier, because column names and the schema describe the data. Metadata, data about data, is key here.
• Unstructured data has no common format: documents, photos, free text. You can label it, though users can remove or misapply labels. Or you can analyse the content: pattern matching with regular expressions, lexical analysis of meaning, which is prone to false positives, or hashing to spot known files.
• Semi-structured data has some structure, often tags, as in HTML, XML or JSON. The trap is unstructured data inside structured systems: a comments column in a booking table, or attachments in a ticketing system, can end up holding more sensitive data than anyone planned. Your discovery tool must handle both.
• Location matters too. Cloud data may be stored anywhere, PaaS and SaaS may not allow agents, and network DLP can't read encrypted traffic to cloud services. Know where your data lives before you choose discovery tools, and recheck after big changes like a cloud migration.
• And the customer stays accountable for discovering and inventorying its sensitive data, even in a provider's cloud.
• Our call: whether the tool could see the attachments and free-text fields at all. Ticketing systems mix structured fields with attachments, and SaaS may block scanning, so a clean result may just be a blind spot.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

How classification policies, mapping and labelling tell people how to protect data.

Key points

• Classification groups data by the attributes that drive its protection. Each level carries a set of controls, so a new system doesn't need fresh research: its classification tells you what it needs.
• We'll take it in order: the policy, mapping, then labelling.
• What drives the levels? Data type, such as health or financial data, and its legal constraints, such as where it may be stored. Ownership, including partners' and customers' terms. And value or criticality, measured by the impact of losing it.
• The policy records the levels, the data types and the required protections. It's foundational: other policies, on encryption, access and retention, refer back to it. Common sensitive types include personal data, health information and cardholder data.
• A good policy also covers access and encryption, defines what counts as regulated data, states approved uses and environments, and sets retention and disposal. It should name expert contacts who can help.
• Mapping finds where data lives, which is a vital input to risk assessment. DLP tools can scan for storage locations. Then add an owner to every data set, so someone is accountable for protecting it.
• Labels tell people how to protect data. Paper takes stamps and watermarks; devices take stickers; digital files take metadata, footers or digital watermarks. Labels should show on every medium, without saying too much, and found media is treated as the highest level until checked. DLP can read labels too.
• Our call: Restricted, the highest level, until an examination proves otherwise, and examine it on an isolated machine, since found media can carry malware.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

How information rights management makes restrictions travel with the data, and the tools it needs.

Key points

• Shared data ends up on systems you don't control. Information rights management, or IRM, makes your restrictions travel with the data. Consumer-grade IRM, usually called DRM, protects copyrighted media. Enterprise IRM protects business documents, controlling copying, printing and access.
• We'll take it in order: objectives, then tools.
• Most IRM uses an access control list on the file: who may read, edit, print or share it.
• Ideally, IRM has these five attributes. Persistence: the controls follow the data and can't be switched off by the next user. Dynamic policy control: the owner can change or revoke access after sharing.
• Expiration: access can end after a set time. A continuous audit trail: every use is recorded. And interoperability: it has to work across the different systems and tools your partners use.
• Who sets the rules depends on the access model. Under discretionary access control, the owner sets rights per document. Under mandatory access control, the owner sets metadata, like a classification, and the system decides.
• Now the tools. IRM needs a central service to prove identity and issue certificates or tokens, a store of revoked ones, and usually a network connection to check access. Think of a building pass: it's checked at every door, and a cancelled pass stops working everywhere.
• The local keys, tokens and certificates are secrets too. If they're tampered with, a user could widen their own access, and because the credential is valid, the misuse is almost invisible.
• Our call: revoke their access. With dynamic policy control, a copy stops opening the next time it checks in with the IRM service, and the ninety-day expiry is a backstop. Nothing can undo what staff have already read.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

How to retain, delete and archive data, including NIST's three sanitisation methods and cryptographic erasure.

Key points

• At the end of its useful life, data is retained, archived or deleted, often as law or compliance dictates, and classification can decide which.
• We'll take it in order: retention, deletion, then archiving.
• Retention is driven by operational needs and by compliance. Keep data as long as it's useful or required, and no longer. HIPAA, for example, requires its compliance documentation to be kept for six years. Under the GDPR, personal data mustn't be kept identifiable for longer than its purpose needs.
• Storage tiers trade cost for speed. Hot storage is quick and expensive; archive tiers are cheap, but retrieval can take hours. A retention schedule says what moves where, and when, such as files untouched for ninety days moving to a cool tier.
• Retention procedures keep old data usable: formats that stay readable, the keys needed to decrypt it, integrity checks when it's written and periodically after, controlled retrieval, and the schedule itself.
• Deletion. NIST's media sanitisation guide, revised in September 2025, sets three methods. Clear overwrites user-addressable storage, which defeats simple recovery tools. Purge makes recovery infeasible even with state-of-the-art laboratory techniques. Destroy does the same, and leaves the media unusable.
• In the cloud, you rarely touch the disks, so cryptographic erasure may be the only practical purge. Encrypt with strong keys you control, then destroy every copy of the keys. NIST treats it as a purge technique.
• Choose the method by cost and risk.
• Archiving moves data out of production into long-term storage. Control and monitor archive access, encrypt data on its way there, and hash it to prove integrity later. Some sectors require immutable storage, such as write once, read many.
• Our call: not as one rule. Retention periods differ by law and by contract, and HIPAA's six years covers compliance documents, not every record. Set periods per data type and jurisdiction, with each clinic's terms, and check for legal holds first.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2016/679 (General Data Protection Regulation); NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization

In this lesson

How a legal hold suspends retention, and how to carry one out without losing the keys.

Key points

• A legal hold suspends a retention schedule. Say invoices are normally deleted after six years. Once they're under hold, they stay until the hold is lifted, however long that takes. Deciding a hold is usually for the lawyers; security must be ready to carry it out.
• First, what to hold. Legal requests can be vague or broad. Ask legal counsel, and when in doubt, err towards holding too much.
• Second, stopping deletion. Paper can be moved to a locked room. Electronic records can be copied to a separate, controlled store, if integrity is preserved, or flagged with metadata so deletion skips them.
• Don't forget the keys. If records are encrypted, key management must know about the hold too. Miss that, and you keep data nobody can read, because its key expired on schedule.
• Held records often feed eDiscovery, the collection of evidence for a legal case, which Domain 6 covers.
• In the cloud, put legal hold support in the contract, with the storage it needs, and know who to contact at the provider.
• Our call: ask counsel to confirm the scope, and meanwhile hold wider, such as related emails, notes and logs. Then tag the keys for everything held.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Which events to log, which attributes to record, and how logs are stored and analysed.

Key points

• To hold people accountable, you need evidence, and that means logs, prepared in advance. An event is any observable action, such as a sign-in or a new server being launched.
• We'll take it in order: event sources, event attributes, then storing and analysing logs.
• Which events you can log depends on the service model. IaaS gives the most: network, operating system and application logs. In SaaS, you may get only events from the application itself. The contract can help, with extra log access or investigation support.
• Logs must answer: who did what, and when? Capture the user identity, including service accounts; the IP address, as a starting point; and geolocation, which also helps spot sign-ins from unusual countries.
• OWASP's logging cheat sheet lists the attributes worth recording: when, where, who and what, such as the time, the application, the source address, the user identity, the action and the result.
• It also advises synchronising time across systems.
• Other challenges: apps classify and format events differently, and logs kept on the host can be altered by anyone with admin rights there. A central log store with separate access addresses the second.
• Logs are only valuable if someone reviews them, and there are far too many for people alone. A SIEM collects and protects them, normalises formats and time zones, then detects, alerts and supports investigations, correlating events all the time.
• Our call: identity attribution. The app logged the account it uses for the database, not the person who asked. Log the signed-in user's identity at the application, so each event ties back to one person.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; OWASP Logging Cheat Sheet

In this lesson

How a chain of custody keeps evidence believable, and what gives you non-repudiation.

Key points

• Evidence for an investigation, especially one that may go to court, needs proven integrity.
• We'll take it in order: chain of custody, then non-repudiation.
• A chain of custody documents everyone who held the evidence and what they did with it, from the moment it's collected until it's shown in court. Without it, a defendant can claim the evidence was altered.
• It doesn't mean the data never moved. Say an investigator snapshots a cloud server's disk and copies it for analysis. The data has moved, but trained handling and a record of every handover keep it believable. Leave the copy in a bucket anyone can edit, and the chain breaks.
• Non-repudiation means someone can't credibly deny an action. Think of a stockroom with one shared key: anyone can deny taking the stock. Give everyone their own badge, and the door log shows whose badge was used.
• In systems, non-repudiation comes from unique identities, logs users can't tamper with, and digital signatures, which show both the integrity and the source of data.
• Our call: no non-repudiation. With a shared login, anyone can deny the action. Give each admin a named account, and keep their logs where they can't be changed.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

What you're building

One workbook that pulls Domain 2 together for a cloud service: your classification levels and their controls, where each data set lives and who owns it, how long you keep it and how you delete it, the keys behind it, and any legal holds. Compare your answers with Aldermoor's, then fill in the blank copy for a service of your own.

What each sheet records

• Classification levels: each level, examples, and the controls it brings, such as encryption, access, sharing, storage location and labels. Each level should carry a set of control expectations, so a system's classification tells you what it needs.
• Data inventory: each data set, its owner, store, region, level, data type and the laws or terms that apply, and whether it's structured. Mapping where data lives and naming an owner is a vital input to risk assessment.
• Retention schedule: how long each data set is kept, from when, on what basis, when it moves to a cheaper tier, and how it's deleted. Rows turn red while counsel hasn't confirmed the period. Retention balances operational need, compliance and cost; HIPAA, for example, requires its compliance documentation to be kept for six years, and the GDPR limits how long personal data is kept identifiable.
• Deletion methods: clear, purge and destroy, from NIST SP 800-88 Rev. 2 (September 2025), which treats cryptographic erase as a purge technique.
• Key register: each key, what it protects, where it's held, its owner and rotation, and whether it's under a legal hold, so a held record's key isn't deleted on schedule.
• Legal holds: each hold's scope, the records and keys tagged, who placed it and when. When in doubt about scope, ask counsel and keep more rather than less.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its names, periods and dates are invented, except where a source is cited above; the two-year log period is our suggestion. This is not legal advice: every retention period waits for counsel to confirm it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization

In this lesson

What Domain 3 covers, in what order, and the deliverable you'll build for Aldermoor.

Key points

• Domain 3 is about what the cloud is built from, and how it survives when something breaks. The provider owns the buildings and the hardware, but the customer still owns the risk to its data.
• Domain 3 is 17% of the exam.
• We'll take it in order: the infrastructure components, secure data centre design, risks, security controls, and finally business continuity and disaster recovery.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Who runs the physical environment, and who protects data on its way across the network.

Key points

• Every cloud service sits on real buildings and real cables. We'll take two topics in order: the physical environment, then network and communications.
• The physical environment means the server rooms and data centres. Who runs them depends on the deployment model. In a public cloud, it's the commercial provider. In a community cloud, it's usually the member hosting the equipment. A private cloud is often built by the organisation itself, which makes it the provider.
• The risks are the ones any data centre faces: who can reach the equipment, whether it stays cool, and whether power and water keep flowing. The answers are familiar, from perimeter barriers and staffed entrances to signed visitor logs. Provider engineers sign in through a central identity system, with a second factor, and what they do is recorded.
• Now the network. Each side looks after the equipment in its own building, and the provider keeps its network correctly set up. The hard part is the stretch in the middle. Nobody owns the public internet, so protecting data on that journey falls to both parties, and that normally means encryption.
• So a provider has to offer encrypted connections, HTTPS being the obvious one, but they only count if customers turn them on. You can also wrap traffic in a VPN, or encrypt files before you send them. Or skip the public internet altogether with a private, dedicated line.
• Who does what shifts with the service model. In IaaS, the customer configures the environment. In PaaS, the provider runs the physical parts, the internal network and the tools, and the customer uses those tools properly. In SaaS, the customer has less control again. But in every model, connecting securely stays with the customer.
• Our call: no, and Nadia can explain why it isn't needed. Most providers don't open their sites to individual customers. They offer independent audit reports instead, such as SOC 2 Type II or a CSA STAR Level 2 report. Share those with the clinic, under NDA where the report requires it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Who secures compute, virtualisation and storage, and why the management plane needs the tightest control.

Key points

• Four more components, in order: compute, virtualisation, storage and the management plane.
• Compute means the processors, memory, disks and virtual machines. The security issues match on-premises, with one addition: multitenancy. Two things never move: the hardware stays with the provider, and data and users stay with the customer. Everything in the middle depends on the service, so get it written into the contract.
• In IaaS, the customer has the most to do, including patching what it installs. In PaaS, the provider takes on the operating system and platform services, while the customer configures them and patches its own software. In SaaS, the customer handles little more than customisation, users and data.
• Virtualisation. Hypervisor security is always the provider's job, and it's critical: take over the hypervisor and you can reach every virtual machine on it. In a multitenant cloud, that means other customers' machines too.
• The virtual network is often a shared duty. Wall off each virtual network, and let only approved traffic cross, which helps prevent attacks like VLAN hopping. And some older tools, the ones that need a physical mirror port on a switch, simply won't work here. Use tools built for virtual environments.
• Storage. The provider protects the physical media and patches the service. The customer configures it, including public or private access and encryption. You can't securely wipe disks you don't control, and fragments of your data could end up in space later given to another tenant. So encrypt, keep the keys, and you can crypto-shred when you're done.
• The management plane is the web console and APIs that configure everything. Whoever holds the console holds the whole estate, which makes it a favourite target. Protect root and admin accounts first, with long passphrases and multifactor authentication. Hardware tokens are generally stronger than software, and text-message codes can be intercepted.
• Then narrow who gets in: role-based or attribute-based access, which can weigh things like location and device. Ordinary users shouldn't manage the whole environment, and development, test and production should have separate accounts.
• Our call: no. Production is separate for a reason, and broad access to the management plane is exactly what attackers want. Give a narrow role for that task, reviewed and removed afterwards.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How customers design a logical data centre, and how location and buy-or-build shape the physical one.

Key points

• In the cloud, the provider designs the physical data centre, and customers design a logical one on top of it: their own services, storage and connectivity. We'll take it in order: logical design, tenant partitioning, access control, location, then buy or build.
• A logical data centre has the same chores as a physical one. Someone still patches it, configures each service, decides who gets in, watches activity and keeps the logs. The perimeter is built from identity and monitoring, and connections in and out are secured with VPNs or TLS.
• Give every service an approved build standard, the cloud version of a hardening guide. Anything that departs from it needs a written exception and a look at the risk. Then watch for drift, and alert on changes nobody planned.
• Tenant partitioning. What separates you from your neighbours is often only software: access controls in the virtualised layer. If that separation fails, the exposure is still yours to answer for. So encrypt the data, and hold the keys yourself, outside the provider.
• Access control. Funnelling everyone through one entry point makes it simpler to watch, but if that entry point fails, nobody gets in. You can federate your existing identity system with the cloud, or use identity as a service. Whichever you choose, a trained workforce is part of the control.
• Physical design belongs to whoever owns the building, usually the provider. Location comes first: avoid areas prone to disasters or unstable utilities where possible. Sites with different disaster profiles improve availability, which is easier at a provider's scale.
• Buy or build. Building gets you exactly what you want, at a price. Buying is cheaper, but you take what's on offer. Cloud customers have largely gone the buying route, and where data is too sensitive for public cloud, private or community cloud offers a compromise.
• Our call: close it now, and investigate. A deviation from the baseline needs an approved exception with a risk analysis, and an unexpected change should be investigated.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

How HVAC, connectivity and resilient design affect availability, and how you get assurance about them.

Key points

• Environmental design is the provider's job, except in a private cloud. It mostly affects availability. As a customer, you review it through third-party audits rather than in person. We'll take it in order: heating and cooling, multivendor connectivity, then resilient design.
• HVAC needs depend on the climate. A site with harsh winters plans around heating, and one in a hot, humid climate plans around cooling. Some providers build in cold regions to use the outside air. If HVAC fails, availability falls, just as it would with a power cut.
• So ask whether the provider has enough HVAC capacity, and what backs it up. A SOC 2 Type II report covering availability should describe it, usually under a non-disclosure agreement. And a properly architected application can move between data centres if HVAC fails.
• Connectivity can be a single point of failure, and links from more than one vendor reduce that risk. Because cloud services live on the internet, losing the office line needn't stop work: people can carry on from any working connection.
• For the data centre itself, best practice is dual entry and dual provider. In plain terms: two internet providers, with their cables kept apart and coming in on different sides, so one cut can't take out both.
• Resilient design means engineering for the disturbances you expect, and it covers power, HVAC and connectivity. For power, that means an uninterruptible supply to carry you across to long-term backup.
• And think about placement. Two power feeds in one duct can fail together, so put critical systems where the expected disaster won't reach them.
• Our call: only partly. Cooling is the provider's job, but keeping the service running for clinics is Aldermoor's. That's why it should be built to survive losing a data centre.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-53 Rev. 5: Security and Privacy Controls

In this lesson

How to identify and analyse cloud infrastructure risk, and what to ask a provider.

Key points

• Moving to the cloud doesn't lower your risk on its own. A common mistake is to treat security as entirely the provider's job. Providers cover part of it, but the risk to the data stays with the customer. We'll take it in order: identification, analysis, then cloud-specific questions.
• Identification comes first. Many frameworks start with what you value, so list it: suppliers, staff, business processes, data and equipment. Then look for what could disrupt each one. Sources include deliberate acts, natural disasters, and errors or omissions.
• Frameworks give you a method, and some add catalogues of common risks. ISO 31000, NIST's SP 800-37 and COBIT are examples. Cloud risks should be identified when you decide to use a service, and watched for its whole life. If they change enough, you may need to move.
• Analysis asks two questions: how likely is it, and what's the impact? Take an overnight report that fails now and then, which is likely. If it's a monthly sales summary, the impact is small. If it builds tomorrow's clinic list, it's serious. The same event earns a different response.
• Assessments can be quantitative, using numbers, which best supports cost-benefit decisions. Or qualitative, using levels like low and high, which communicates well to decision-makers. Semi-quantitative approaches sit between.
• Then the cloud-specific questions. Who provides authentication, and how much control do you give up? How is data encrypted at rest and in transit, and who can reach it? What about the vendor's own suppliers, policies and incident response support?
• You usually can't audit a provider directly, so review its standard evidence: a SOC 2 report, ISO 27001 certification, and specialised material such as ISO 27017 and 27018, HIPAA or FedRAMP.
• Our call: no. A certificate is evidence about the provider's controls. The customer still owns the risk to its data and has its own side of the shared responsibility model to assess.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments

In this lesson

The threats specific to a shared, internet-connected cloud, and what limits them.

Key points

• One weakness sits under everything here: a cloud service lives on the internet, so anyone connected can have a go at it, or at your provider. We'll take it in order: collateral damage, other tenants, then the provider's own staff.
• Collateral damage first. An attack on your provider may have nothing to do with you. Knock the provider offline and its customers go down with it, and a storm or earthquake elsewhere can do the same. So your usual threat model may not be enough.
• Other tenants. If the barrier between customers fails, a competitor or an attacker could end up looking at your data. It counts as a breach even if they do nothing with it, and the law or a regulator may then expect action from you. Your best defence is encryption with keys you manage.
• The provider's staff. Insiders at cloud companies have taken customer data before, and by then your contract may be all you have left. So focus on stopping it happening: encrypt, and keep the keys outside the cloud.
• Some risks apply to every cloud. Providers are big, attractive targets, so ask for their test results. Regulated data may not be allowed to cross borders. Downtime is possible, so look for multiple zones or regions. And data centres may sit where the disaster profile differs from yours.
• The Cloud Security Alliance publishes a regular list of top cloud threats. Its 2022 edition, the Pandemic Eleven, came from a survey of 703 industry experts.
• Earlier editions put data breaches, misconfiguration, poor cloud security strategy and weak identity management at the top.
• Our call: it does concern Aldermoor. An attack aimed at a neighbour can spill over, because you share the provider. So check for impact, and confirm the service can move to another region if it has to.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CSA Top Threats to Cloud Computing (landing page)

In this lesson

How cloud risk treatment works in practice, from choosing a provider to monitoring.

Key points

• Lesson 6.16 covers the treatments in general: avoid, mitigate, transfer, share or accept. Most of what you'll do here is mitigation, in four steps: choose the provider, design the system, encrypt, then monitor.
• It begins before you sign. Write down what you need, then measure each provider against it. A provider that can't deliver is a risk you chose.
• Then design. Security goes in at the start, driven by those same requirements. If you need logs kept for a year, pick a service that can keep them, and then actually turn that on.
• Encrypt all data at rest and in motion, since it's outside your direct control. TLS, IPSec or VPNs protect data in transit, and storage can often use customer-controlled keys. Fewer ways in and out also makes it easier to monitor.
• Finally, monitor. Providers give you tools for configuration, change tracking and usage, but they do nothing until you use them. A log nobody reads catches nobody.
• Some controls exist because you've handed over direct control. Others are really supplier management. Either way, the gains from moving to the cloud have to be worth the risk you've taken on. And for the most sensitive data, a hybrid approach can keep it out of public cloud altogether.
• Our call: no. Insurance offsets the financial impact; it doesn't keep clinics running. And insurers usually expect mitigations to be in place, so transfer works alongside mitigation, not instead of it.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Choosing physical, system, storage and communication controls in a shared responsibility model.

Key points

• Controls are chosen to fit the risks, as in any risk programme. We'll take it in order: physical and environmental protection, then system and storage, then communication.
• Physical and environmental protection is usually the provider's. In a private or community cloud it may be yours, and anything on your own premises certainly is. The needs are the same everywhere: get the site right first, then layered access, reliable power, the utilities to run it, and enough skilled people.
• A public cloud customer still has choices. Pin services to the countries you want, read up on how the provider plans to recover from a disaster, and design your application so that losing one data centre doesn't take it down.
• For systems, break the problem into parts: processes, storage and communication pathways. NIST's SP 800-53 has a family for this, called System and Communications Protection. Start with policy and procedures, then separate system administration from user functions, and isolate security functions from the rest of the system.
• That family also covers denial-of-service protection, which most providers offer as a service. Boundary protection, for traffic going in and data going out. And cryptographic key management, which matters more when you've lost physical control.
• Encryption of stored data is a joint effort. The provider looks after the hardware. You pick the right service and set it up, say by blocking public access. Holding your own keys adds protection, but only if you look after them.
• For communication, plan for outages with redundant connectivity, and protect data in transit. TLS or a VPN keeps data private on the move. A hash shows if something changed by accident. To catch someone changing it on purpose, use a digital signature or an HMAC.
• Our call: keep them apart. That's separation of duties: split sensitive functions between people, so one team can't change a control and also hide the change. NIST's own example is that whoever runs access control shouldn't also run audit.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-53 Rev. 5: Security and Privacy Controls

In this lesson

Identification, authentication, authorisation and accountability in the cloud.

Key points

• You can extend an existing identity system to the cloud, buy identity as a service, or use your provider's own. A provider's system is simple within its own cloud, but weigh lock-in and a single point of failure. Good practice is summed up as IAAA, and we'll take it in order: identification, authentication, authorisation and accountability.
• Identification: a user claims an identity, such as a login name. If cloud and on-premises use separate identity systems, it gets harder to see what any one person is doing. Identity as a service is designed to connect to many kinds of system, so it can join the two.
• Authentication: the user proves it, with a password, PIN or biometric. Add multifactor authentication where more security is needed.
• Authorisation: an authenticated user gets the resources they're allowed. Across many services, each has its own permission model, which is hard to manage. A cloud access security broker can centralise that control.
• Accountability: users answer for what they do, which relies on logging and monitoring. We'll get to that in the next lesson.
• People matter here too. If one password unlocks everything, a leak at any vendor unlocks you. You may not hear about it soon, and the vendor may not know either.
• Because the cloud is reachable from anywhere, a login from another country is no longer suspicious on its own. Conditional authentication helps: ask for multifactor authentication when the country or device is unusual. It balances usability with security.
• Our call: a cloud access security broker. It gives a single layer for administering user access across different services, each with its own permission model.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Log collection, correlation and packet capture, and what you can and can't see in the cloud.

Key points

• Auditing a provider is hard. It has too many sites and customers to let you walk through them, and letting you into its networks or logs could expose other tenants. So you work with what the service offers. We'll take it in order: log collection, correlation, then packet capture.
• Log collection. The first problem is sheer volume, so filter for what matters. Whatever else you do, capture anything involving privileged accounts. NIST's SP 800-53 and OWASP's logging cheat sheet help you decide the rest.
• Send cloud and on-premises logs to one aggregator. Someone reviews them every day, and privileged account alerts get handled at once. Unread logs can still help after an incident, but they won't warn you of one.
• Correlation finds the relationships between events on different systems. A baseline shows what's normal, so anomalies stand out. An account signing in at three in the morning might be someone on call, or an intruder. SIEM platforms often do this work.
• Packet capture records network traffic, which can reveal things like data exfiltration or worms spreading. In the cloud, it can be difficult or impossible. SaaS often offers no way to do it, and the traffic is encrypted anyway.
• Some providers offer limited tools, such as a virtual network tap inside your own virtual private cloud. You can't see traffic beyond it, because that could expose other tenants. If you'll need packet capture, write that down as a requirement before you migrate.
• Our call: they assumed a capability SaaS rarely offers, and nobody checked before buying. For now, use whatever logs the vendor provides. Then make it part of how you evaluate services: decide what you need to see, and whether a SaaS product can show it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

How business continuity and disaster recovery differ, and how the cloud changes both.

Key points

• The cloud has made continuity and recovery cheaper and easier to run across distant locations. We'll take it in order: business continuity, disaster recovery, then the cloud's role.
• Business continuity means carrying on when something goes badly wrong. The business continuity plan, or BCP, is written for the scenarios you're most likely to face, and only for what matters. A business impact analysis tells you which processes those are.
• The disaster recovery plan, or DRP, is about the technology: getting systems and facilities working again, often at another site, and then back to normal. Not every incident needs both. A burst pipe that closes an office for a week might need only the BCP: staff work elsewhere and nothing is rebuilt. A fire that guts your server room needs both.
• Each plan ends at a different point. Disaster recovery ends when the technology and buildings are back in working order. Business continuity ends when the way you work has returned to what it was.
• When a provider has a disaster, plans stack up. The provider activates its plans and must keep customers informed. Each customer may then activate its own, perhaps moving to another region or provider.
• High availability makes the cloud a natural part of both plans, and customers may focus on services that survive a disaster rather than on recovering from one. But one rule comes first: people before systems and data, whenever health or safety is at stake.
• How you recover is your decision. Backups, several availability zones, load balancing or something else: the provider won't pick for you.
• Our call: get people out. People come before systems and data, and the plan should allow the work to continue from elsewhere.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-34 Rev. 1: Contingency Planning Guide

In this lesson

How RTO, RPO and recovery service level turn business needs into recovery targets.

Key points

• Even in the cloud, resilience costs money, so three metrics justify the spending. We'll take them in order: recovery time objective, recovery point objective, then recovery service level.
• The recovery time objective, or RTO, is how long you can be without a system. A business impact analysis ranks each system, and each gets a maximum tolerable downtime: the absolute limit. The RTO must be shorter than that.
• RTO belongs to the business, not IT. IT's job is to lay out the choices and what each costs. And it's surprising how many critical systems stop being critical once the owner sees the bill.
• The recovery point objective, or RPO, is how much data you can afford to lose, measured in time or transactions. It guides your backups. If you can lose four hours of data at most, a backup every twelve hours misses that target.
• Backing up more often costs more, so weigh it against what the data is worth. With regulated data, skimping can cost more than the backups would. Cloud storage can make a tight RPO affordable, and a transaction journal lets you replay work after a failure.
• The recovery service level, or RSL, is the percentage of computing power that production needs during a disaster. Development and test can usually be shut down. If thirty of your hundred and fifty machines run production, that's a twenty percent service level, so recover those thirty.
• Our call: no. A nightly backup could lose up to a day of records. To meet fifteen minutes, back up far more often, or use replication or journalling.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-34 Rev. 1: Contingency Planning Guide

In this lesson

How to write, implement and test a continuity and recovery plan.

Key points

• A plan needs three things, and we'll take them in order: writing it, putting it in place, then testing it, with updates as you learn. Continuity and recovery are separate plans, but neither should be written without sight of the other.
• Creation begins with a business impact analysis. Group processes as critical, important or supporting, then set the order. If the app servers can't start until the database is up, the database goes first. Senior leaders should settle these priorities up front, because everyone thinks their system matters most.
• Plan for a range of disasters, with history and government agencies as guides. Your provider's reference architectures help as well. And hard-to-recover legacy systems may be worth replacing before an emergency.
• Implementation needs an executive sponsor, to find the money, and named people to do the work. Expect things like a fallback site, supplier agreements and training.
• Spend according to priority. For critical work, active-active keeps things going almost without a break. Active-passive costs less and suits important work that can wait a little. Everything else can live in one zone and take longer to return.
• Test at least once a year, starting with the likeliest scenarios. New plans start with scheduled tests. Mature ones can include surprise tests, known only to senior approvers and a few key people.
• The tests rise in realism. A tabletop talks through the plan. A walk-through moves people to their places. A simulation exercises the plan while normal work continues.
• A parallel test really carries out the steps while live systems keep running, then compares the two. A full cutover switches the primary off. That can go badly wrong, so leave it to the most mature teams.
• Our call: not yet. Full cutover is for the most mature teams, because critical functions may fail. A new plan starts with a tabletop, then builds up through walk-throughs and simulations.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

What you're building

One workbook that pulls Domain 3 together for a cloud service: what you depend on, what could go wrong, how fast you need each service back, the order you'd restore it, and how you'll test the plan. Compare your answers with Aldermoor's, then fill in the blank copy for a service of your own.

What each sheet records

• Assets: anything essential or valuable to the organisation, including data, systems, people and key suppliers, with its owner and priority. Identifying assets is the usual first step in identifying risk.
• Risk register: each risk, its source, a score from likelihood and impact, the treatment, the actions and who accepted what's left. Risks are typically measured by likelihood and impact, and the residual risk should be judged against your risk tolerance.
• Recovery targets: maximum tolerable downtime, RTO, RPO and recovery service level for each service. The RTO must normally be shorter than the maximum tolerable downtime, and it's a business decision.
• Recovery order: the steps and what each depends on. Systems others depend on, such as single sign-on, come first.
• Test schedule: from tabletop through walk-through, simulation and parallel test to full cutover. Test at least annually, and leave full cutover to the most mature teams.
• Provider evidence: the third-party reports you reviewed, what they cover and any gaps. Most providers don't allow customers to audit them directly and offer reports such as SOC 2 instead.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its names, scores, targets and dates are invented. The scoring scale of one to three is our suggestion; use your organisation's own scale if it has one.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-34 Rev. 1: Contingency Planning Guide

In this lesson

How to calculate SLE, ARO and ALE, and when to use something else.

Key points

• Asset value is the estimated cost of the property, reputation or goodwill at risk. Exposure factor is the percentage of that value you'd lose if the exploit happened.
• Multiply them to get the single loss expectancy, or SLE: the cost of one event.
• The annual rate of occurrence, or ARO, is how many times you estimate it happens in a year. If you expect it once in ten years, that's nought point one.
• Multiply SLE by ARO for the annual loss expectancy, or ALE: the total loss over a year. You'll also see it called annualised loss expectancy. It's the same thing.
• Try it. An asset is worth two hundred thousand pounds, and an exploit would destroy a quarter of it. That's an SLE of fifty thousand pounds. If that happens twice a year, the ALE is one hundred thousand pounds. These figures are made up, but the method isn't.
• The point of the number is to choose. Quantitative results best support cost-benefit decisions. Our reading: weigh what a control costs against the annual loss it removes.
• Reach for qualitative analysis as an initial assessment, or for the intangible aspects of a risk. Customer confidence is hard to put a price on, for example, so low, medium and high may tell you more. That example is our reading.
• Here's our worked example. Aldermoor values its reporting service at four hundred thousand pounds. A long outage would cost a quarter of that, so the SLE is one hundred thousand pounds. It expects one every five years, an ARO of nought point two. So the ALE is twenty thousand pounds. These figures are ours.
• Our call: not on these numbers alone. The control costs more each year than the most it could save, which is twenty thousand pounds. If the reports matter in ways the figures miss, make that case qualitatively. Next: what a control does.

Sources

HHS Health Sector Cybersecurity Coordination Center: Quantitative Risk Management for Healthcare Cybersecurity (7 May 2020); NIST IR 8286Ar1: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management; NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments; NIST IR 8286r1: Integrating Cybersecurity and Enterprise Risk Management

In this lesson

The five types of control, sorted by what each one does.

Key points

• Lesson three point eight sorted controls by what they protect. You can also sort them by what they do. NIST gives five examples, and we'll take them in order: preventative, deterrent, detective, corrective, then compensating.
• Preventative controls reduce or remove a specific weakness. Multifactor authentication is one: it cuts down the weaknesses that come with passwords.
• Deterrent controls dissuade a threat actor, which lowers the likelihood of an attack. A warning banner is a deterrent, and so is the threat of prosecution. It doesn't block anyone. It only discourages.
• Detective controls warn you of an attempted or successful event. Monitoring access logs and alerting the security operations centre is one. It doesn't stop the event, but it tells you.
• Corrective controls reduce exposure by offsetting the impact after something has happened. If a database is encrypted, its data stays protected when the files are stolen. Our reading: that limits the damage after the theft, so here it's corrective. Elsewhere, encryption is often called a compensating control.
• Compensating controls adjust for a weakness in another control. One control falls short, so another one covers the gap.
• You'll also see controls grouped as administrative, technical and physical. Our reading: that grouping says what a control is made of, and these five say what it does.
• Here's our worked example. Aldermoor's admin console shows a warning banner at sign-in, which is a deterrent. Multifactor authentication is preventative. An alert when someone opens patient data without a ticket is detective. These choices are ours.
• Our call: compensating. It adjusts for a weakness in another control, here the missing multifactor authentication. Next: denial-of-service attacks.

Sources

NIST IR 8286r1: Integrating Cybersecurity and Enterprise Risk Management; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How denial-of-service attacks work, and how to blunt them.

Key points

• A denial-of-service attack tries to make a system unavailable to the people who need it. A single source is a plain denial of service. Many sources make it distributed, a DDoS, often using botnets of compromised computers. That produces far more traffic, and it's harder to defend against.
• American government guidance sorts the techniques into three types. Volume-based attacks try to use up bandwidth or system resources with sheer traffic, so legitimate requests can't get through.
• Protocol-based attacks exploit weak implementations of network protocols, typically at layers three and four.
• Application-layer attacks go after weaknesses in a specific application, at layer seven. Instead of flooding the network, they consume the application's processing power. Attackers can combine all three.
• Spotting one starts before it arrives. Analyse your traffic regularly, so you know what normal looks like. Then a sudden slowdown or spike stands out.
• Prepare several layers. A mitigation provider can filter malicious traffic before it reaches your network. Load balancing spreads the work and helps avoid a single point of failure. Firewalls can filter suspicious patterns and apply rate limits. And a content delivery network, listed as a response step, spreads content across many servers and absorbs traffic. Our reading: set one up before you need it.
• Many cloud platforms build in load balancing, so a surge in requests gets shared out before it can take the service down.
• During an attack, run your incident response plan and tell your provider, who may be able to reroute traffic. Keep the evidence too: timestamps, IP addresses and logs.
• Our call: no. A distributed attack comes from many sources, which makes those addresses hard to trace and block. Use the mitigation service, the content delivery network and rate limits instead. Next: alternate processing sites.

Sources

CISA, FBI and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks (March 2024); CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The kinds of alternate site, and how to choose one.

Key points

• An alternate site can be one you own or operate, one you share through a reciprocal agreement with another team or organisation, or one you lease commercially.
• Readiness runs from cold to hot. A cold site has space, power and environmental controls, but no equipment. It's normally the cheapest, and the slowest. Everything has to be acquired, installed and loaded, which can take days to weeks.
• A warm site adds the equipment, but the software and data aren't loaded. It may run only critical processes. A test or development site somewhere else can serve as one.
• A hot site is fully operational, with current software and recent data, ready to take over quickly. It means running the system in full at a second location, with support close to production's, so it's expensive.
• Two variations are worth knowing. A mobile site is a self-contained, transportable shell. It may arrive within twenty-four hours, but installing and setting it up adds to that. A mirrored site is fully redundant, with real-time mirroring. It's the most expensive, and it offers virtually one hundred percent availability.
• Let the business impact analysis choose. A critical function may need a hot site, while a reporting job that can be down for days just needs space. Either way, pick a place that the same hazard is unlikely to hit.
• In the cloud, a set of services can stand in as a hot site if your own environment fails, and another region or zone can play this part. Our reading: the same trade-off applies. The readier the standby, the more it costs.
• Our call: no. At a cold site everything has to be acquired and installed, which can take days to weeks. Four hours needs something much readier, most likely a hot site. Next: the module quiz.

Sources

NIST SP 800-34 Rev. 1: Contingency Planning Guide; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What Domain 4 covers and what you'll build.

Key points

• Domain 4 is about the software itself. Strong networks and identity don't help much if the application running on them is insecure. It's sixteen percent of the exam.
• We'll take it in order: awareness and common flaws, the secure development lifecycle, applying it, testing, verified software, cloud application architecture, and identity.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Why secure software depends on culture, design and everyone's share of the work.

Key points

• Secure software starts with people, not tools. We'll take it in order: building the culture, security by design, shared responsibility, then security as a business goal.
• A security culture comes from steady, deliberate effort. SAFECode describes three parts: executives who support it and take part, a designed programme, and a way to sustain and measure it.
• Security by design builds protection into every stage. Security needs go on the requirements list from day one.
• Shared responsibility means it isn't only the security team's problem. Nobody gets to opt out, whatever their seniority. That mirrors the cloud model, where provider and customer each have defined duties.
• Treat security as a business objective, like revenue or customer satisfaction. Teams driven only by compliance can see it as an obstacle, yet an incident can seriously damage the business.
• Our call: security by design. Security belongs in the requirements and at every step after, not bolted on at the end. Next: the pitfalls that derail all of this.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The ordinary reasons application security programmes fail.

Key points

• Most application security programmes fail for ordinary reasons. We'll take them in order: misunderstanding responsibility, missing support and culture, staffing and process, then training budgets.
• The first pitfall is assuming the provider handles all of it. Providers publish their shared responsibility models, yet some customers still believe everything has been outsourced. Leaders need to know exactly what the organisation keeps.
• Next comes weak backing from senior management. Without their approval and funding, the effort lacks resources and is largely wasted.
• Then there's ignoring culture. Culture varies even between close competitors. A process that clashes with how people work is unlikely to be adopted, so plan the change, and review it regularly.
• Security specialists are scarce, so one expert may support several teams, and consistency suffers. And with no framework for secure development, security becomes ad hoc.
• When money is tight, training is often cut first, because the damage isn't immediate. Cheaper formats are better than none: online courses, or bringing one trainer to a large group.
• Our call: move to a cheaper format. Online courses can lose a little impact, but they beat dropping training altogether. Next: the top risks in web applications.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The ten most critical web application risks in the 2025 edition.

Key points

• The OWASP Top Ten is an awareness document on the most critical risks to web applications. The current edition is twenty twenty-five. We'll take it in order: access and configuration, the supply chain and cryptography, injection and design, then the rest.
• Number one is broken access control, which is users acting outside their permissions. Number two is security misconfiguration: unsafe defaults, unnecessary features and overly open settings.
• Number three, software supply chain failures, has grown in scope: breakdowns in how software is built, distributed or updated. Number four is cryptographic failures, where sensitive data isn't properly protected.
• Number five is injection: untrusted input gets treated as a command. Number six is insecure design, which is a flawed plan rather than a coding mistake, so perfect code can't fix it.
• The last four are authentication failures, software or data integrity failures, security logging and alerting failures, and the new one, mishandling of exceptional conditions. That last one is software that fails badly when something unexpected happens.
• Our call: broken access control. The server has to check each request against what that user may see. Next: the same idea, applied to APIs.

Sources

OWASP Top 10:2025

In this lesson

The ten API-specific risks in the 2023 edition.

Key points

• APIs have their own list, because they fail in their own ways. The current edition is twenty twenty-three. We'll take it in order: authorisation, resources and business flows, then the wider picture.
• Authorisation dominates. Broken object level authorisation means an API returns a record without checking that this caller may have it. Attackers simply change the identifier in the request.
• Broken object property level authorisation exposes or lets someone change particular fields. Broken function level authorisation lets ordinary users reach administrative functions. And broken authentication lets attackers assume another identity.
• Unrestricted resource consumption can cause denial of service, or simply a large bill. Unrestricted access to sensitive business flows is automated use that harms the business, even with no bug at all.
• Server side request forgery tricks an API into fetching from a place it shouldn't. Security misconfiguration is familiar. Improper inventory means forgotten versions and debug endpoints. Unsafe consumption is trusting another company's API too much.
• Our call: improper inventory. You can't protect what you've lost track of, so keep an up-to-date list and retire old versions. Next: the risks of LLM applications.

Sources

OWASP API Security Top 10 (2023)

In this lesson

The OWASP risks for applications built on large language models.

Key points

• Module seven covered AI in depth, so here's the list as developers meet it. The outline names this OWASP list too. We'll take it in order: input and data, output and agency, then cost and accuracy.
• Prompt injection is number one: inputs that change the model's behaviour. In our reading, the next group concerns data and components: sensitive information disclosure, leaked system prompts, data and model poisoning, and supply chain and vector store weaknesses.
• Improper output handling means trusting what the model produces and passing it on unchecked. Treat model output as untrusted input. Excessive agency means giving a model more power to act than it needs.
• Unbounded consumption can run up costs or take a service down. Misinformation means confident output that happens to be wrong, and an application that depends on it inherits the error.
• Our call: improper output handling. The model's text must be validated and encoded before it's used, like any other input. Next: two more references you'll see named.

Sources

OWASP Top 10 for LLM and generative AI applications; ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

What the CWE Top 25 and ASVS are for, and when to use each.

Key points

• Two more names in the outline do different jobs. We'll take it in order: the CWE Top Twenty-five, the verification standard called ASVS, then how to choose.
• The outline calls it the SANS Top Twenty-five. It's a list of the most dangerous software weaknesses, published under the Common Weakness Enumeration, and it's built from real vulnerability records.
• It's aimed at engineers, and it's useful for designing tests. Because it measures all reported software, some entries matter less in cloud-native systems, and the list changes each year, so check the current edition.
• ASVS is the Application Security Verification Standard. It gives testers a basis for checking web application controls, and gives developers a list of requirements for secure development.
• Here's the difference. Top ten lists raise awareness of what goes wrong. ASVS is more like a specification: requirements you can build to and verify against. In our reading, you use the lists to prioritise and the standard to verify.
• Our call: ASVS. It's written as requirements you can test against, which is what the clinic is asking for. Next: the secure development lifecycle.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); CWE Top 25 Most Dangerous Software Weaknesses; OWASP Application Security Verification Standard (project page); OWASP Top 10:2025

In this lesson

How a secure lifecycle differs from an ordinary one, and two frameworks that help.

Key points

• Now the process that keeps software secure. We'll take it in order: from an SDLC to a secure one, the NIST framework, then the OWASP maturity model.
• A software development lifecycle covers everything from requirements through design, build and test to running the system. Security isn't built into that by default. A secure lifecycle adds security tasks to every phase.
• Draw the lifecycle as a timeline running left to right, and moving security to the beginning is called shifting left. Flaws found earlier cost less to fix.
• The NIST Secure Software Development Framework groups practices into four areas: prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. It describes outcomes, not specific tools.
• OWASP's Software Assurance Maturity Model measures how good your current practice is, and plans improvements. It has five domains: governance, design, implementation, verification and operations.
• Our call: SAMM. It's designed to assess the current state and plan improvements. Next: where security requirements come from.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-218: Secure Software Development Framework

In this lesson

Where security requirements come from, and why early is cheaper.

Key points

• Security has to be justified in business terms, and written down early. We'll take it in order: why it pays, what requirements capture, then how to make it stick.
• A secure lifecycle costs a little more at the start. But defects get more expensive the later you find them, and some security flaws are impossible to fix after the fact.
• Business requirements state the outcomes the company wants from its technology. Functional requirements turn that into specifics. Alongside them, you record the security, privacy and compliance objectives.
• Those objectives then drive specific requirements. Regulated data brings rules on who may see it, how it's protected and how long it's kept. So find out which rules apply before anyone designs anything.
• It only works if it's mandatory. A secure lifecycle succeeds when the business requires it for all development, not just the projects someone remembers.
• Our call: add the requirement now. It's still cheap at this stage, and every later phase depends on it. Next: the phases of the lifecycle.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The security job at each stage of the lifecycle.

Key points

• Every lifecycle has similar stages, and each one has a security job. We'll take them in order: requirements and design, development and testing, then deployment and operations.
• Requirements cover planning and gathering what the system must do, security included. Design has to meet those requirements, and it's when you plan the test cases, for unexpected use as well as expected.
• Development is writing and integrating the code, often with bought-in components and cloud services, and developers unit test as they go.
• Testing validates the whole system, and every test should trace back to a requirement. If a requirement says only a patient's own clinic may open a record, test every route to a record.
• Deployment is the first release, where you check default settings, API and identity configuration, and harden each component. One written secure baseline per approved service keeps that consistent.
• Operations and maintenance normally lasts longest: monitoring, checking who still has access and handling incidents.
• Our call: deployment. That's where default settings are checked against your requirements, and components are hardened. Next: waterfall, agile and DevOps.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How waterfall, agile and DevOps change security's role.

Key points

• The phases stay similar, but how you move through them varies. We'll take it in order: waterfall, agile, then DevOps.
• Waterfall moves through stages one after another. Nothing gets designed until the requirements are complete, and that discipline can help security.
• Its weakness is inflexibility. Late changes are painful, though a modified form lets a project return to an earlier phase.
• Agile delivers in short cycles called sprints, adding requirements as it goes. Security can benefit, because fixes ship faster and automated tests can run repeatedly as code moves through the pipeline.
• The risk is prioritisation. With limited developers, features users have asked for can push security work into a later cycle, and the system carries that risk until then.
• DevOps pushes for even faster and more frequent deployment. Automated testing becomes essential. In our reading, security checks belong in the pipeline, because a review at the end can't keep pace.
• Our call: agile prioritisation. Reserve capacity, or the risk stays open for as long as the fix keeps slipping. Next: risks that are specific to the cloud.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The four cloud-specific development risks the outline names.

Key points

• Building for the cloud brings risks that an on-premises build doesn't have. The outline names four. We'll take them in order: shared technology, provider insiders, visibility and control, then law and jurisdiction.
• You share infrastructure with other tenants. Tenants are often kept apart only by software. A hypervisor bug or bad permission could let one reach another.
• The application can respond. Assume the walls could fail, so encrypt sensitive data and hold the keys yourself. In our reading, if customers share your application, your own code needs tenant checks too.
• Provider staff can be a route to your data too. The risk of unauthorised access by people at the provider is one of the costs of cloud. Encryption with keys you control limits what they can see.
• Using a provider means giving up some visibility into how your systems run. With SaaS, you may see little sign of whether patches went in, and the physical infrastructure is out of your hands. So log what you can and ask for evidence.
• In the cloud, data moves across borders easily, and that can break privacy law. A development team needs to know where data may go before it picks a region or a logging service.
• Our call: law and jurisdiction. Personal data is crossing a border through a side door, so stop it, and review how errors are logged. Next: threat modelling.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The six threat categories in STRIDE.

Key points

• Threat modelling means asking what could go wrong before an attacker does. STRIDE, from Microsoft, is a mnemonic for six kinds of threat. We'll take them in order: identity and integrity, then accountability and secrecy, then availability and privilege.
• S is spoofing: pretending to be someone or something else. Multifactor authentication and digital signatures help. T is tampering: altering data without authority. Access controls prevent it, and logging and monitoring reveal it.
• R is repudiation: you can claim you never did something, and nothing shows otherwise. Logging and digital signatures provide that evidence.
• I is information disclosure: data reaching people who shouldn't see it. Encryption, data loss prevention and access controls are the usual answers.
• D is denial of service: legitimate users can't get in. Redundancy, high availability and mitigation services help. E is elevation of privilege: gaining rights you shouldn't have. Strong access control and input validation stop it.
• Our call: repudiation. Nobody can prove who did it. Logging each change to a named user closes that gap. Next: three more methods for ranking and analysing threats.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Three more threat modelling methods, for ranking and analysis.

Key points

• STRIDE finds threats. These three help you rank them or run the process. We'll take them in order: DREAD, PASTA, then ATASM.
• DREAD scores a threat with five questions. How bad is the damage? How easily can it be reproduced? How easy is it to exploit? How many users are affected? And how easily can it be discovered?
• Watch for one thing. The exam outline expands the D in DREAD as disaster, but the standard term is damage. Answer from the idea, and don't be thrown by the wording.
• PASTA is the Process for Attack Simulation and Threat Analysis. It's a seven-step, risk-based method that ties threats to business objectives, and it can reuse your business impact analysis.
• The seven steps run from objectives and technical scope, through breaking down the application and analysing threats and vulnerabilities, to modelling attacks and analysing risk and impact.
• ATASM stands for architecture, threats, attack surfaces and mitigations. It isn't a model in its own right. It organises the work, so it can run alongside the other three.
• Our call: DREAD. It's built for ranking threats once you've found them. Next: stopping these flaws as code gets written.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Preventing known flaws, with OWASP's and SAFECode's guidance.

Key points

• Common flaws are well documented, so they can be avoided. We'll take it in order: layered controls, OWASP's resources, then SAFECode.
• Avoiding them takes layers. Training tells developers what to avoid, in the languages they actually use. A documented process means everyone follows the same steps.
• Then there's test-driven development. Give developers well-defined security test cases, so they know what they're building to.
• OWASP publishes cheat sheets, which give developers quick guidance on specific topics. It also has a secure coding practices guide, covering areas such as input validation and cryptographic practices.
• ASVS helps here as well: it gives you verifiable requirements, and testers often use it to categorise findings.
• SAFECode is an industry forum where software companies share what works in secure development. Its guidance is deliberately broad, so you tailor it to your own teams and practices.
• Our call: training in their own language. Developers need to see how to avoid the flaw in the code they actually write. Next: keeping track of what you build.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); OWASP Application Security Verification Standard (project page)

In this lesson

Knowing exactly which software is running, and getting back to a good version.

Key points

• Good code isn't enough. You have to know exactly which code is running. We'll take it in order: why integrity matters, versioning and rollback, then audit evidence.
• Software configuration management protects the integrity of your software and its settings. Lots of people change code and configuration at once, often in different places, so you need one controlled record.
• Without it, the wrong build can reach customers, and the damage goes well beyond the fix.
• Versioning means you can roll back to a known good state, and rebuild if you have to. It also lets you keep the different configurations that particular customers or regulators require.
• It also produces evidence. What was checked before release, and how you'd undo it, gives auditors something to verify. A configuration management database can record it, and it can be federated across cloud and on-premises.
• Our call: configuration management. With versioned settings, you'd see the change and roll it back. Next: testing.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What assurance means, and how functional and non-functional testing build it.

Key points

• Testing tells you how much confidence to have. We'll take it in order: what assurance means, functional testing, non-functional testing, then CI/CD.
• Software assurance is how confident you are that code has no weaknesses and behaves as designed. You never get certainty, since no test can show errors don't exist. So you keep monitoring even after every test passes.
• Functional testing checks the system does what the requirements say. Three kinds of testing lead up to it: unit tests on single pieces, integration tests as pieces combine, and usability tests with real users.
• Make test environments as close to production as you can. If real data sits in a lower environment, even a stale copy, it earns production-grade controls. Regression testing then checks that changes haven't broken anything or brought old flaws back.
• Non-functional testing covers qualities rather than features: security, load and capacity, and compatibility across platforms.
• In a continuous integration and delivery pipeline, automated testing is essential. Once code's checked in, tests run automatically, and small changes make problems easier to find.
• Our call: real data needs production-grade controls, however old it is. Use synthetic data, or raise the environment's controls. Next: security testing methods.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Box testing, and the differences between SAST, DAST and IAST.

Key points

• Security tests differ in what the tester knows, and when they run. We'll take it in order: box testing, then SAST, DAST, and IAST.
• White box testers see the source code. Black box testers know nothing, just like an outsider. Grey box testers know some things, such as the architecture or documentation, but not the code.
• Static application security testing, or SAST, analyses source code without running it. It's a form of white box testing that can start early and run throughout development, and it won't find everything.
• Dynamic testing, or DAST, attacks the running application from the outside, as a form of black box testing. Its coverage is limited, so it shouldn't be your only test.
• Interactive testing, or IAST, puts an agent inside the application to watch it as it runs, which makes it a grey box approach. RASP also runs alongside the application, but it's a protective tool: it can stop an attack as it happens.
• Serverless and microservices can make this harder. Without a long-lived host for an agent, certain tests can't run, so something else must cover the gap, such as a web application firewall.
• Our call: SAST. It reads the source code, so it needs no running application. Next: what automated scanning misses.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Dependencies, software bills of materials, and what people find that tools miss.

Key points

• Most software is built from other people's software. We'll take it in order: composition analysis, software bills of materials, then manual testing.
• Software composition analysis lists every dependency in your application, and flags ones that are out of date or have known vulnerabilities. Someone still has to check whether a flaw actually affects you.
• A software bill of materials, or SBOM, lists the components in a finished product. Standard formats let you exchange that list, and some can carry digital signatures, so you can verify nothing has been altered.
• Peer code review means a colleague reads the code before it moves on, and works best on small changes. Tools can flag unsafe functions as developers type.
• Automated tools can only try what they've been told to try, and they can report false alarms. Manual testing brings human judgement and creative thinking, at a higher cost. In most cases, using both gets you the benefits of each.
• Our call: investigate, then plan the fix. It may not affect you now, but confirm that and keep it on the list, because the code might start using it. Next: quality assurance and abuse cases.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Quality assurance in DevOps, and testing what attackers would try.

Key points

• Two final kinds of assurance. We'll take it in order: quality assurance, use cases, then abuse cases.
• Traditionally, quality assurance was a separate check just before release. In DevOps, it's embedded at every phase, and the tests trace back to what the requirements say about features and security.
• Quality assurance can also cover load and stress testing, and tracking security flaws found by other tests. In some teams, it's the final gate before code reaches customers.
• A use case tests a defined requirement: a clinician opens a patient's record and sees that patient's notes.
• An abuse case, or misuse case, tests the opposite. Attackers don't follow the rules, so you try what they'd try, and check the application stays secure and responds correctly.
• Our call: a use case. It confirms expected behaviour. The abuse case would be double-booking, or booking another clinic's slot. Next: securing APIs.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Building, restricting and monitoring APIs.

Key points

• APIs usually front your most important data. We'll take it in order: building them securely, configuring and restricting them, then testing and monitoring.
• A custom API goes through the same secure lifecycle as any other software. Its requirements should cover encryption and how access is monitored. And access is often monitored through authentication or keys.
• Authorise every object a caller asks for. OWASP's guidance is to check, in every function that takes a record ID from the client, that the logged-in user may perform that action on that record.
• Fewer ways in means less to protect. Where you can, make the API the only route to a service. Use provider APIs exactly as defined, and write approved configurations that policy can enforce.
• Responsibility for APIs is often shared, so test how each dependency is configured as part of your lifecycle. Vulnerability scanning finds known flaws. It can't find unknown ones, so logging and monitoring have to back it up.
• Our call: no. A scan only finds what's already known. Logging and monitoring are how you notice the rest. Next: the supply chain.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); OWASP API Security Top 10 (2023)

In this lesson

Assessing vendors, and checking integrity, authenticity and licensing.

Key points

• Your software depends on suppliers, and their problems become yours. The outline names four concerns. We'll take them in order: vendor assessment, then integrity and authenticity, then licensing.
• Software supply chain failures are third on the twenty twenty-five OWASP Top Ten. They cover breakdowns in how software is built, distributed or updated, often through third-party code or tools.
• Assess vendors the way you assess your own risks. You might audit them directly, or send a questionnaire. Larger suppliers often can't answer everyone, so they share an independent report, such as a SOC 2 Type II, or an ISO 27001 certificate.
• Integrity means the component hasn't been altered. Authenticity means it really came from the author. Check signatures and hashes, and use an SBOM to confirm your deployed components are the versions their authors released.
• Licensing is a risk in its own right. A licence says how you may use the software: how many users, or which sites. Some free and open-source licences forbid use in commercial products. Your composition analysis can track this.
• Our call: don't use it under that licence. Free to download doesn't mean free to sell. Find an alternative, or get a commercial licence. Next: third-party and open-source software.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); OWASP Top 10:2025

In this lesson

What to ask suppliers, and how to validate open-source software.

Key points

• Bought software and free software both need checking. We'll take it in order: the questions to ask, the evidence and who's responsible, then validating open source.
• Third-party tools often hold your data, so ask where the software runs, how data's encrypted, how access is managed, and what logging and auditing you get. Security terms belong in every vendor contract.
• Look at evidence too: the supplier's SOC 2 report, recent scans and penetration tests, and its security and privacy policies. The work can move to a supplier, but accountability for the data stays with you.
• Some people assume open source is safe because anyone can read the code. Yet large projects are hard to review, and popular libraries have had serious flaws. Give it the same risk-driven checks you'd apply to anything you buy.
• Prefer projects that are actively maintained and have a long, solid history. Because you have the code, you can run static analysis on it, then add interactive testing in the running application. Sandbox testing and third-party verification help as well.
• Our call: no. Popular projects have shipped serious flaws too, and how you integrate them can add new ones. Validate it like any other component. Next: cloud application architecture.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Cloud application shapes, and WAFs, database monitoring and XML firewalls.

Key points

• Cloud applications aren't always three-tier, and they gain some extra defences. We'll take it in order: architectures, web application firewalls, database activity monitoring, then XML firewalls.
• Beyond the traditional three tiers, you'll see microservices, which split an application into single-purpose services, and serverless, which runs only when an event triggers it. You can't observe code that isn't executing, so monitor at the front door.
• A web application firewall, or WAF, inspects web requests against rules for allowable behaviour. That helps against attacks like injection and cross-site scripting. It works at the application level, while an intrusion detection system watches network traffic.
• Database activity monitoring watches for unusual database use, and can alert on it or block it. It's separate from the database's own logs, though it may use them. It can also watch privileged users, and it needs tuning to avoid false positives.
• An XML firewall sits in front of XML-based applications and APIs, and checks messages at the application layer. It's useful for protecting older code, but it's an added layer, not a replacement for secure development.
• Our call: database activity monitoring. The requests look like normal web traffic, but the pattern of database use isn't. Next: API gateways and load balancers.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What API gateways and load balancers add.

Key points

• Two more components sit in the path of your traffic. We'll take them in order: API gateways, load balancers, then where they fit.
• An API gateway manages traffic to your back-end services. It can limit how fast callers send requests, log each one, and enforce authorisation. It's also a good place to validate keys.
• It helps because it reduces the number of entry points. Every call comes through one place, so you can apply and watch controls consistently. All the main providers offer a managed gateway.
• A load balancer spreads traffic across several servers or data centres. For security, that means availability: it helps prevent a single point of failure during an attack.
• It's also a natural place to enforce encryption. For example, an application load balancer can automatically redirect plain web traffic to the encrypted version.
• Layer them. In our reading, a typical path has a firewall or gateway filtering requests, then a load balancer sharing them out across healthy servers. Choose each one from your risk analysis and an inventory of what you actually run.
• Our call: the API gateway. Rate limiting per key is exactly its job. A load balancer would just spread the same flood around. Next: cryptography and sandboxing.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); CISA, FBI and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks (March 2024); AWS Well-Architected Framework: Security Pillar

In this lesson

Applying encryption, key separation and sandboxes in application design.

Key points

• You saw the cryptography basics in Domain 1. Now we'll apply them to applications. We'll take it in order: data at rest, data in motion, keys, then sandboxes.
• Encrypting stored data is standard for anything sensitive, and most provider storage offers it as an option. Provider-managed keys are the easy path, but high-security applications call for keys the customer controls.
• Data in motion uses standard methods: TLS, HTTPS and VPNs. A provider's private backbone isn't automatically a trusted network, so encrypt that traffic anyway, and confirm it's configured.
• Keeping keys in a service you control separates the service holding the data from the service holding the keys. That's separation of duties, and for sensitive data, it's preferable to leaving keys with the provider.
• A sandbox is a walled-off environment that limits what code can do and what it can reach. In the cloud, you can create one quickly. So developers can test risky code, and anything that breaks stays inside.
• Our call: no. Private doesn't mean trusted, so encrypt it, and check how it's configured. Next: microservices and containers.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Microservices, containers, Docker, Kubernetes and how to secure them.

Key points

• Modern applications are built from many small parts. We'll take it in order: microservices, containers and Docker, Kubernetes, then securing the stack.
• Microservices are small independent services that talk to each other, usually over APIs. You can update each one on its own, but those updates have to be coordinated so nothing breaks.
• A container packages an application with everything it needs, so it runs anywhere that supports the technology. Docker is a popular container platform. Images are kept in registries, and each one should come from a set you trust.
• Kubernetes is an orchestrator. You say how many containers you want, and it decides where they run, and it can restart them if a host fails. Updates replace the whole image rather than patching a running container.
• Kubernetes has its own controls: restrict access to its API, enforce pod security standards, set network policies, and keep audit logs. Keep secrets out of images, and provide them at runtime.
• Remember that the platform is itself software. It has to be configured and patched, and if it's compromised, every container on it is too. It's a single point of control, and a single point of failure.
• Our call: no. Anyone who can read the image gets the password. Keep secrets outside images and inject them at runtime. Next: federated identity and single sign-on.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-190: Application Container Security Guide; Kubernetes: Cloud Native Security overview

In this lesson

Single sign-on, federation, identity providers and the main protocols.

Key points

• Applications rarely manage identity alone. We'll take it in order: single sign-on, federation, identity providers, then the protocols.
• Single sign-on means you authenticate once and reach every system under one identity service. Fewer credentials means you can ask for stronger ones, and access is easier to monitor and to remove.
• The downside is concentration. If the service is down, users are locked out of everything. And a stolen account reaches every connected system, so watch it closely.
• Federation extends that trust across organisations, so one digital identity works on another company's systems. It widens the damage if an identity is compromised. But you can disable one account and cut off access everywhere.
• Federating also means trusting another organisation's controls, which you don't run. So assess the risk before connecting.
• An identity provider identifies and authenticates users. It might be your cloud provider's own service, or a separate identity-as-a-service product, which often suits a multi-cloud setup. Choose based on your strategy.
• Three protocols to recognise. SAML uses XML and handles authentication between separate systems. OAuth two handles authorisation, and came out of web and mobile apps. LDAP talks to directories, mostly in older or on-premises estates.
• Our call: have the hospital disable the account at its identity provider. One change cuts access across every federated system. Next: multifactor authentication.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The factor types, what counts as true MFA, and how it supports SSO.

Key points

• Passwords alone aren't enough, so applications ask for more proof. We'll take it in order: the factors, what counts as true multifactor, then how it works with single sign-on.
• There are three classic types of factor: something you know, such as a passphrase; something you have, such as a token or phone; and something you are, such as a fingerprint.
• A newer signal is the context of the request, such as whether this device has been used before. Policies can ask for an extra step only when something looks unusual.
• Multifactor means different types of factor, not simply more of them. A password plus a PIN is two things you know, so it's still one factor type.
• With single sign-on or federation, multifactor limits the damage of a stolen account. You can demand a token when someone moves from one federated system to another, or at intervals during the day. It's a trade between convenience and risk.
• Our call: no. Both are things you know, so it's a single factor type, asked for twice. Next: cloud access security brokers.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What a CASB does, and how its deployment changes what it can do.

Key points

• When you use many cloud services, you need one place to see and control them. We'll take it in order: what a CASB does, inline or out of band, then agent or agentless.
• A cloud access security broker sits between your users and cloud services. It monitors activity and enforces policy across services with different access models. It adds to your firewalls and intrusion systems rather than replacing them.
• To prevent something, a CASB has to be in the path of the traffic. That's inline, and it works like an intrusion prevention system. An out-of-band CASB gets a copy of the traffic. It's reactive, more like an intrusion detection system.
• Agent-based CASBs run on the device. They work well on company laptops, but staff may refuse them on their own phones, and they can slow devices down.
• Agentless CASBs connect through the cloud service's API instead, so the device doesn't matter, provided the service exposes one. They're fast to roll out, but can't respond proactively the way an agent can.
• Our call: inline. Only something in the path of the traffic can stop it. An out-of-band broker can only tell you afterwards. Next: secrets, keys and certificates.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Managing the credentials that aren't human.

Key points

• Much of what signs in today isn't human. We'll take it in order: what secrets are, generating them, storing them, then keys and certificates.
• Secrets are credentials used mostly by systems and privileged accounts: API keys, digital certificates and SSH keys. They often carry high privilege, so protect them like privileged accounts.
• Secrets need to be generated by approved methods. In the cloud, pipelines generate them automatically, and automatic scaling adds new hosts that need them to authenticate. So you need a secrets management tool.
• Never put secrets in source code or code repositories. Store them in a secrets manager, retrieve them when they're needed, and log each use.
• Key management services hold encryption keys and integrate with cloud services, often through an API. Certificates prove a remote host's identity. Automate how they're deployed and renewed.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); AWS Well-Architected Framework: Security Pillar

What you're building

One workbook that pulls Domain 4 together for a software release: what it must do, what could go wrong, how you tested it, what it's built from, and whether it's ready to ship. Compare your answers with Aldermoor's, then fill in the blank copy for your own organisation.

What each sheet records

• Requirements: the security, privacy and compliance objectives for the release, each with a test that proves it. Requirements should include security objectives, and tests should trace back to them.
• Threat model: each threat with its STRIDE category and DREAD score. STRIDE classifies threats, and DREAD asks five questions to help rank them. The workbook scores each question from one to three, which is our own simple scale.
• Test plan: which tests run, when, and whether a failure stops the release. In a pipeline with continuous delivery, automated testing is a required feature, and static, dynamic and interactive tests suit different stages.
• Components: every dependency, its licence and whether its integrity was checked. Composition analysis inventories dependencies, and licence management can be built into it.
• Release gate: the evidence that the release is ready. Configuration management supplies evidence such as version checks and rollback plans, and deployment is where defaults are checked.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its features, versions, scores and owners are invented. Adjust the checks and scales to fit your own process before relying on them.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

What Domain 5 covers, and the deliverable you'll build: Aldermoor's incident and forensics runbook.

Key points

• Domain 5 is 17% of the exam.
• It's about running the cloud safely, day after day. Many of these tasks sit with the provider and you may never see them, so part of your job is oversight of the provider.
• The outline has six parts, and we'll take them in order: building the infrastructure, operating it, operational controls and standards, digital forensics, communication, and security operations.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The two pieces of security hardware the outline names, the TPM and the HSM, and how to use them in the cloud.

Key points

• Hardening hardware follows the same rules in the cloud as on premises, though the methods differ. In a public cloud, the provider configures the hardware; in a private cloud, you do.
• The outline names two pieces of hardware, and we'll take them in order: the Trusted Platform Module, then the Hardware Security Module.
• A TPM is a dedicated cryptographic coprocessor that's usually built into the system hardware, so it can't be added later. It generates random numbers, key pairs and hashes, and it securely stores small amounts of data, such as the keys for full disk encryption.
• TPMs also act as roots of trust. A signed hash of a system's hardware can be compared with its current state to check nothing has changed.
• They come in forms. Dedicated hardware resists tampering best. Integrated and firmware TPMs resist it less. A virtual TPM is software in the hypervisor, so the hypervisor must keep it isolated from the virtual machines.
• An HSM is a separate device dedicated to cryptography, added as a card or over a cable or network, so it can be added or upgraded later. It stores keys, encrypts and decrypts, and supports authentication. Common uses include key pairs for a public key infrastructure, financial data, and signing records in DNSSEC.
• In the cloud, you can't touch the hardware, so the major providers offer HSMs as a cloud service, used through an API call. For very high security, some providers let you connect a physical HSM that you manage on your own premises. Your keys then stay under your control, so neither the provider's staff nor other customers can realistically reach your data. It costs more, and it's harder to run.
• Our call: no option gives an absolute guarantee, but a customer-managed HSM is the strongest, keeping provider access nearly impossible. It costs more and adds complexity, so Nadia offers it only where the contract justifies it, and records the trade-off.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

What secure by default means, and how to install and harden the tools that manage the cloud.

Key points

• Two topics here, in order: secure by default, then installing and configuring the tools that manage the cloud.
• NIST describes the principle of secure defaults. A system's default configuration should enforce security restrictively, so it protects itself as shipped, and its security mechanisms should deny a request unless it's explicitly authorised.
• The UK's NCSC calls Secure by Default an ethos, not a compliance badge. Among its principles: build security in from the beginning; fix the root cause, not the symptom; keep at it for the product's whole life; don't let security wreck usability; and security shouldn't need extensive configuration to work.
• Don't assume your cloud is secure by default, though. In general-purpose IaaS and PaaS, virtual hardware may not be configured for security out of the box. The customer must configure it, for example by segmenting networks and allowing only the traffic between hosts that's needed.
• Now the management tools: tools such as VMware vSphere, and the provider consoles customers use. Compromise one, and an attacker may reach hundreds or thousands of virtual machines. So follow the vendor's hardening steps, and add external standards such as CIS Benchmarks or DISA STIGs.
• Five practices complete the picture. Build in redundancy, because a critical tool can be a single point of failure. Patch on a rotating schedule, moving running machines off first. Isolate access, with least privilege and a dedicated admin network. Keep the tools under configuration and change management. And log all activity.
• Here's our worked example. Ravi's team installs a new tool to manage Aldermoor's machines. It arrives with a default admin account. Before it goes live, they change the default credentials, disable what isn't needed, put it on the admin network only, and send its logs to monitoring. These are standard hardening steps.
• Our call: harden first. A management tool reaches every machine it manages, so it gets vendor guidance, a benchmark, isolation and full logging before it goes live. A short delay costs less than a compromised console.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-53 Rev. 5: Security and Privacy Controls; UK NCSC: Secure by Default principles; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Hypervisor types, virtual hardware configuration and sizing, and guest operating system tools.

Key points

• In the cloud, a virtual machine shares physical hardware with many others. So the biggest virtual hardware issue is the hypervisor keeping guests strictly apart, acting as a reference monitor over their access to the hardware.
• A Type 1 hypervisor, also called bare metal, runs directly on the hardware, and it's the common choice among the major providers. A Type 2, or hosted, hypervisor runs as a program on top of an ordinary operating system. It's mostly used for testing or individual needs, and it's generally less secure.
• Why it matters: break the hypervisor, and you reach every machine on it. An attacker who escalates from one tenant to the hypervisor can attack other customers, an attack called VM escape. In public cloud services, the hypervisor's security is always the provider's responsibility.
• Configuration comes next. Give the hypervisor only the functions it needs, for example blocking traffic between virtual machines unless required, and encrypting guest snapshots. Patch the virtualisation tools promptly. On the customer side, use a virtual private cloud and security groups to control which hosts can talk.
• Then sizing. You choose memory, processor cores and storage. Provision enough for the workload, but not so much that you pay for idle capacity. Infrastructure as code describes this in a definition file, which also enables autoscaling: as load rises, more instances start automatically.
• Last, guest tools: toolsets that add drivers, device support and better interaction for a guest operating system. In a public cloud, the provider usually supplies them, so check it supports what you need before you choose it. In your own environment, install only what's needed: no Windows toolset on a cluster with no Windows guests.
• Our call: the bigger problem is real patient data on office laptops, so use test data there, or keep the copy in the hardened cloud environment. Type 2 hypervisors are also generally less secure.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

How administrators reach cloud systems safely: remote protocols, local access, consoles and the controls around them.

Key points

• Most cloud administration is remote, and it crosses untrusted networks, usually the internet.
• We'll take it in order: remote protocols, local access, the provider's consoles, and the controls that protect them all.
• Secure Shell, or SSH, lets an administrator run commands on a remote system over an encrypted channel, using shared or public key cryptography to authenticate. Remote Desktop Protocol, or RDP, gives remote control of a desktop, with encryption and authentication. It's a frequent target for attackers, so keep it patched. VNC plays a similar role on Unix and Linux.
• For local administration, a secure KVM switch lets one keyboard, screen and mouse control several machines without leaking data between them. Its protections include isolated ports, tamper-evident design, buffers wiped when you switch, fixed or signed firmware, physical disconnects, and blocking USB storage.
• Every provider gives customers an admin console: the Management Console in AWS, the Portal in Azure, and the Cloud Console in Google Cloud. Command-line tools call the same APIs. The provider makes sure only authenticated users get in. You authorise your own people, protect the console with multifactor authentication, and log and review every use.
• Now the controls. Encrypt sessions with strong protocols such as TLS 1.3 and session-specific keys. Use strong, multifactor authentication. Give admins a separate privileged account from their everyday one. Log and review admin activity more closely. And manage it all with an identity tool, with single sign-on where it fits.
• The outline also names jumpboxes and bastion hosts.
• The principle behind them is in the guidance for management tools: route admin access through isolated networks or a dedicated administrative network, with tight access control.
• Our call: no. RDP is a common target, and remote admin is high risk. Keep access through the protected admin path, with MFA and logging, and speed up that path instead.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Secure network configuration (VLANs, TLS, DHCP, DNSSEC, VPNs) and the network controls that protect cloud workloads.

Key points

• Cloud services are reached over networks, so nearly every cloud security concern comes back to the network.
• First, five parts of secure configuration, in order: VLANs, TLS, DHCP, DNSSEC and VPNs. Then the controls.
• A VLAN keeps a group of hosts' traffic to themselves, so traffic between VLANs passes through a control point, often a firewall. Each frame carries a VLAN tag. VXLAN extends the idea across data centres and clouds. As a cloud customer, you'll mostly use network security groups, which allow or deny traffic by address, protocol and port.
• TLS encrypts data in transit, and the current version is 1.3. In the handshake, the client lists what it supports, the server picks the version and cipher and sends its certificate, and the two agree a session key. Configure it to allow only ciphers known to be secure. Mutual TLS, where both sides show certificates, suits high-security links.
• DHCP hands out addresses in four steps: discover, offer, request, acknowledge. Misconfigured, it can cause a denial of service or misdirect traffic. DNS turns names into addresses, and it can be poisoned or spoofed. DNSSEC signs DNS data, which protects its integrity. It doesn't make it confidential, and it doesn't stop look-alike domain names.
• A VPN builds an encrypted tunnel, so remote users or whole sites join a network safely. Options include OpenVPN, IKEv2 with IPsec, and browser-based SSL VPNs, which are convenient but may connect from unmanaged machines. A software-defined perimeter goes further: hosts accept no traffic until a controller authenticates the user and authorises the connection.
• Now the controls. Firewalls allow or drop traffic between segments: stateless ones check each packet, stateful ones track the conversation, and web application firewalls inspect web and API traffic. In the cloud, combine security groups with host-based firewalls. That's microsegmentation: control down to a single host.
• An IDS detects and alerts; an IPS also acts, for example by blocking traffic. Network sensors may miss traffic between virtual machines that never crosses a switch, so host-based agents help, at a cost. Honeypots can reveal attackers by looking like something valuable, but they raise legal concerns, such as entrapment, so never set one up for the purpose of catching people.
• Our call: a decoy that looks valuable is fine for detection. Drop the aim of luring and catching people, which raises legal concerns such as entrapment. Getting legal advice first is our call.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Hardening operating systems against a baseline, keeping them there, and patching in each service model.

Key points

• Hardening puts a machine into a secure state: change default credentials, disable unneeded accounts and services, install security tools, and set the operating system's security options. A baseline documents that standard state, and each setting should map to a control objective.
• Virtualisation brought images: templates that build every machine with the same settings. Start from your own image or one your provider offers, then check it against published guides such as CIS Benchmarks, DISA STIGs or NIST checklists. Whatever the source, tailor it to your own needs.
• Systems drift, so monitor them. A configuration management database records what each system should be, for audits and automated scans. Organisation-wide vulnerability scans catch banned services. And immutable architecture limits drift: at the next deployment, old hosts are torn down and rebuilt from the baseline image.
• Now patching. In SaaS, the provider patches, and you check it meets the agreed service levels. In IaaS, you patch the guest operating system and your applications. In PaaS, the provider patches the platform's operating system, and you patch what you install.
• Think of patching in three stages. Before: learn of the flaw and the vendor's fix, and check it applies to you. During: test it, then apply it to every affected system and track progress, with a way to roll back. After: record the new known good state. Set timeframes by criticality: for example, critical patches within seven days.
• Cloud adds traps and tools. Machines that are powered off miss patches, so power them on for patching or check them when they start. Infrastructure as code and immutable builds should always use the latest patched templates. And software composition analysis finds flaws in the open-source parts of your applications.
• Why it matters: today's hardened system is tomorrow's target, as new flaws are found and weaponised. A published patch only protects you once it's on every system that needs it, so tracking matters as much as applying.
• Our call: powered-off machines miss patches, and they wake up vulnerable. Patch them when they start.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Microsoft Azure: Shared responsibility in the cloud

In this lesson

Keeping hosts and guest operating systems available: clusters, maintenance, redundancy tiers and resilience.

Key points

• Availability is more than uptime. A system that's running but unreachable isn't available. High availability means the system and the infrastructure around it stay usable, often measured in nines: five nines, or 99.999%, is about five minutes of downtime a year.
• A cluster groups resources under a coordinating agent, giving redundancy, shared workloads and scaling without disruption. It controls each machine's share of resources: a reservation is a guaranteed minimum, a limit is a maximum, and a share is a weighting used when machines compete.
• Maintenance mode takes a host offline for work, and it touches all three goals. Availability: move running machines off first, with live migration. Confidentiality: migration traffic may be unencrypted, so protect it on untrusted networks. Integrity: changes still need approvals, and logs must keep running.
• Tools automate this. VMware's Distributed Resource Scheduler, or DRS, moves running machines between hosts without disruption and saves power when demand is low. Microsoft's Virtual Machine Manager does similar work, called dynamic optimisation. Storage clusters pool storage: tightly coupled ones perform better, loosely coupled ones cost less.
• For data centre redundancy, the Uptime Institute defines tiers. Tier 1 has no redundancy. Tier 2 has partial redundancy. Tier 3 allows planned maintenance without an outage. Tier 4 is fault-tolerant, with no single point of failure, and costs the most.
• The guest operating system is usually your job. In IaaS, once a machine is created, the provider no longer controls its operating system. You can plan to recover, with backups and snapshots, accepting some data loss and rebuild time. Or you can build in resilience, with clusters, live migration, and availability zones or regions that fail over for you.
• Our call: no. The provider supplies the resilience options, but choosing and configuring them, like zones and failover, is the customer's job. And for a guest operating system in IaaS, availability is Aldermoor's responsibility.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Monitoring performance, capacity and hardware, and spotting misuse in the numbers.

Key points

• Both sides monitor. The provider checks it can meet demand and bills accurately; the customer checks the provider keeps its promises and its own systems stay available. Most monitoring serves availability, but it can reveal misuse too, such as a processor spike caused by cryptocurrency-mining malware.
• For performance and capacity, watch three things. Network: bandwidth use, link state and dropped packets. Compute: processor use, and also GPUs or the number of API calls. Storage and memory: the amount used, reads and writes per second, and how fast data comes back. Set thresholds that trigger alerts and planned action.
• And someone must look. A metric nobody reviews won't warn you before a service fails, and you may pay for capacity you couldn't use.
• Now hardware. Physical parts have tolerances for heat and power: processors, memory, fans, drives and network gear. A hot processor or an unstable power supply shortens a part's life. Fan speed hints at workload. Many drives report their own health through SMART, and solid-state drives report failing sectors as they near the end.
• The environment matters too: heat, humidity and water. Every monitored item needs an alert threshold and a response, such as moving machines off failing hardware automatically. In general, hardware monitoring is the provider's job, because it controls the hardware.
• Our call: investigate now. A spike with no matching demand can point to misuse, such as mining malware, so treat it as a possible security event, not a capacity problem. Adding capacity would only feed it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Backing up and restoring hosts and guests, and securing the management plane.

Key points

• Two topics, in order: backup and restore, then the management plane.
• For backup, responsibility follows the service model. In SaaS, the provider backs up and restores, usually under service levels. In PaaS, it's shared. In IaaS, backing up your virtual machines is yours.
• In every model, your data stays your responsibility, so check what the contract actually restores.
• Backups need security too. Snapshots can hold sensitive data without the same protections, so restrict who can reach them. Store them on different hardware, or in another availability zone, not beside the machines they protect. Check backups regularly, refresh them after patches or major changes, and test recovery, for example in disaster recovery exercises.
• In IaaS and PaaS, resilience features, like automatic replication, failover between zones and load balancing, are the customer's to configure. The provider supplies the capability; you design for your own objectives.
• Now the management plane. Mostly used by the provider, it's the virtual version of a data centre's controls: powering machines on and off, provisioning memory and storage, and moving running machines before hardware maintenance. It's usually reached through an API, so it needs strong logging, monitoring and access control.
• Its key job is orchestration: automated configuration and management. An admin schedules a patch, and the plane moves the machines off the cluster, stops new ones starting, and enters maintenance mode to apply it.
• Don't confuse it with the management console. The console is what customers use to manage their own services. It may call the plane's API, but it must never give one customer control of the whole infrastructure, or of another customer's.
• Our call: keep them apart. Backups stored beside the systems they protect break a core principle of backup, physical separation, because one incident could take out both.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Microsoft Azure: Shared responsibility in the cloud

In this lesson

Four service management processes: change, release, deployment and configuration management.

Key points

• Running a cloud safely needs repeatable processes. IT service management frameworks provide them, and for service management, the two to know are ISO 20000-1 and ITIL.
• We'll take four processes in order: change, release, deployment, then configuration.
• Change management keeps the organisation running while services are added, changed or retired. A change request records the purpose, the owner, the resources and the impacts. A change board reviews it: is the benefit worth the cost, is the risk acceptable, and can it be rolled back? Then the owner carries it out, with a fallback ready.
• Not every change gets the same treatment. Low-risk changes, like standard patches, are pre-authorised. Normal changes go through the full request, review and implement process. Emergency changes, needed to resolve an incident, take a faster route, sometimes approved afterwards, but they're still documented.
• In a CI/CD pipeline, some reviews, like code analysis, can be automated.
• Release management is the logistics of getting changed software out: what's in it, when it ships, and a check afterwards that it behaves as planned. With CI/CD, developers merge small pieces of code often, and automated tests catch problems early. Before release, check every change has passed its tests and the release notes are written.
• Deployment management puts it in users' hands. With continuous deployment, code that passes its tests goes to users automatically. Riskier updates can go to a small group of users first, in phases. Letting users pull updates when they choose helps uptime, but some never update, leaving vulnerabilities unfixed.
• Configuration management keeps a known good configuration. The things under control are configuration items: code, operating systems, documents, even whole systems. A configuration management database, or CMDB, records them. Compare against it to spot drift, query it when a new vulnerability is announced, and update it after every change, or audits are likely to flag it.
• The cloud adds two strong tools. Immutable infrastructure isn't patched in place: it's replaced with a new build from a validated image.
• Infrastructure as code writes the configuration as a definition file, so every instance is built the same way, without manual steps.
• Our call: Ravi can act, as an emergency change, if it's documented and reviewed afterwards.
• But the rule must also go into the code and the CMDB, or the next rebuild could quietly undo it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Incident management and problem management, and how they work with your cloud provider.

Key points

• Two processes, in order: incident management, then problem management.
• First, two terms. An event is anything observable, like a user logging in. An incident is an event that's unplanned and has an adverse impact, like ransomware, or a lost connection to a cloud service.
• The main goal of incident management is to restore normal service as quickly as possible and limit the harm. Not every incident needs the security team. A traffic spike after a marketing campaign is an operational issue. A coordinated denial-of-service attack needs IT and security together.
• A good plan answers who, what and how. Who's on the team, and who leads it? Who outside must be involved? What counts as an incident? Which tools, such as a SIEM, will you use? How do you get from detection to restored service? And who must you tell, including any breach notices the law requires?
• Incidents are prioritised by two measures. Impact is how much harm the incident does. Urgency is how soon it must be resolved, and anything affecting life, health or safety is more urgent. Many organisations turn this into a priority score, such as P0 to P5, and a high enough score can trigger the continuity plan.
• In the cloud, plan with your provider. Many incidents don't involve it, but some do: an attack on one customer can affect others, and the provider's own incidents must be reported to its customers. Know its contacts and status page, and what it will and won't do. Many providers refuse physical access without a warrant or similar legal process.
• Problem management looks behind incidents. In ITIL, a problem is the cause of one or more incidents. Root-cause analysis finds it, and the aim is to make future incidents less likely or less harmful, so it's a form of risk management.
• Once a root cause is identified, it goes into a known errors database, with how to fix or avoid it. A workaround is a temporary fix: it restores service fast, but it doesn't make the problem less likely. If that's not enough to reduce the risk, find a permanent fix for the root cause.
• Our call: keep it open. A restart is a workaround: it restores service, but it doesn't make the next failure less likely. Log the workaround against the problem, find the root cause, and then record it as a known error.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Continuity, availability and capacity management for cloud services.

Key points

• Three processes keep a service usable, in order: continuity, availability, then capacity.
• Continuity management accepts that bad things happen despite your efforts, so you plan the response before you need it. It matters to customers and providers alike.
• There are four steps. Identify critical functions and resources, usually through a business impact assessment. Prioritise recovery, in the right order: power before systems. Plan continuity, such as automated failover. And document the plans, because under stress, working from a written plan beats improvising.
• Then train the people who'll use them.
• Standards help. ISO 22301 sets requirements for a business continuity management system. In NIST's controls, this is contingency planning.
• And HIPAA's Security Rule requires a contingency plan for electronic protected health information, with data backup, disaster recovery and emergency mode operation plans.
• Availability management is broader than uptime. A service can be up, with its login page reachable, but unusable if a dependency, such as access control, fails. Threats include power loss, disasters and network loss. Maintenance matters too: some providers exclude scheduled maintenance from their availability promise.
• Providers build in high availability, such as moving machines off a failed host and balancing load. But customers have a role. In IaaS, availability is almost entirely your job, except the physical facility. In PaaS and SaaS, you must still design for the provider's availability features and switch them on, such as database replication.
• Capacity management compares what a service can supply with what's being used. If two hundred staff share a hundred and twenty licences, the service is oversubscribed, and some will be turned away. The provider has to forecast demand, monitor it and provision ahead of it, using growth trends, the capacity promised in service levels, and known peaks.
• Some oversubscription can be acceptable, and cheaper. Users in time zones far apart rarely all log in at once. But if you need everyone connected at the same time, write it into the service level agreement, so the provider plans for it.
• Our call: check real demand first. Oversubscription can be fine, but UK afternoons and Canadian mornings do overlap. Measure the peak, and if clinics need everyone connected at once, put it in the service levels.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-53 Rev. 5: Security and Privacy Controls; 45 CFR 164.306 to 164.314 (HIPAA Security Rule) and 160.103 definitions, via Cornell LII

In this lesson

Information security management, service-level management and continual service improvement.

Key points

• Three more processes, in order: information security management, service-level management, then continual service improvement.
• An information security management system, or ISMS, is the organisation's joined-up way of managing security risk: controls, management support, skills and oversight.
• Know the frameworks. ISO 27001 sets the requirements for an ISMS, and 27002 gives the controls. Cloud and privacy guidance builds on them: 27017, 27018, and the privacy standard 27701.
• NIST's Risk Management Framework, SP 800-53 and the Cybersecurity Framework do similar work, and SOC 2 adds an independent audit against the Trust Services Criteria.
• Service-level management defines, measures and corrects how services are delivered. The most common service level is availability, as a percentage of time. Others include concurrent users, data durability, support response times, recovery time, and how fast patches are applied.
• The tool is the service level agreement, or SLA. It's a formal agreement built around outcomes you can measure, which is exactly why it matters for security: it gives you numbers to track and to enforce. In public cloud, the provider usually sets the levels. It needs routine monitoring, and a missed level should carry a penalty, usually a refund.
• Continual service improvement monitors IT services, including the ISMS, and improves them in a cycle. It has two goals: services meet the organisation's objectives, and security risks stay adequately reduced.
• Metrics should suit their audience. Instead of a long list of patches, report one figure: say, eighty-two percent of servers patched within ten days. Give it a target and it becomes a key performance indicator, or KPI. Against a target of ninety-five percent, it shows red, and management knows to act.
• Improvement ideas come from other places too: audit findings, internal or external, and the lessons learned after real incidents, including their root cause.
• Our call: no. A refund compensates Aldermoor, not the clinics that couldn't book. Treat the miss as input to improvement: find out why, check Aldermoor's own resilience, and raise it with the provider.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Why forensics is harder in the cloud, e-discovery, legal hold and the first steps of collection.

Key points

• Digital forensics applies scientific methods to collecting, examining and interpreting digital data. Its main concern is integrity, shown by the chain of custody. It's specialist work, often outsourced, but you must design systems that support it.
• The cloud makes forensics harder. Replication puts data in many places at once, so it's hard to pin down a single crime scene. Multitenancy means more people to rule out. And providers rarely allow physical access, because investigating one customer could expose another's data.
• Collection is harder too. In SaaS, you see little beyond your own data. IaaS gives you your virtual network, but not the physical one. Data may be split across countries, and machines can move between hosts, so it's hard to prove where something happened. So agree investigation support in the contract.
• E-discovery is the electronic side of legal discovery: identifying, collecting, preserving, reviewing and analysing information for a legal case. Two references help. ISO 27050 is a multi-part standard on e-discovery, and the Cloud Security Alliance's guidance covers legal issues, contracts and e-discovery in the cloud. Using a provider doesn't remove your legal responsibility for the data.
• When legal action starts, routine deletion must stop for the relevant data. That's a legal hold: the data is kept until the case ends. Write legal hold into contracts and SLAs, including the extra storage it needs, and know who to call at the provider.
• Before an expert arrives, you may take the first steps. Log every action: the time, the person, the tool, what you inspected, and the result. Document system states and running apps. Capture volatile data first, like memory and short-lived cloud resources. Analyse copies, never the original, and verify integrity often, for example with hashes.
• Prepare before any incident. Send logs to a central store that insiders can't easily alter. Keep backups and baselines, so you can show what changed. Keep a retention policy with a clear legal hold procedure.
• In the cloud, plan to collect the provider's activity logs, snapshots and memory dumps where available.
• Our call: capture evidence first, where it's safe to. Shutting down loses what's in memory, and a rebuild replaces the disk. Contain the server, snapshot it and capture memory, then rebuild.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-86: Integrating Forensic Techniques into Incident Response; AWS Well-Architected Framework: Security Pillar

In this lesson

Chain of custody, what makes evidence useful, and how to collect and preserve it.

Key points

• Evidence, in order: the chain of custody, what makes evidence useful, then collecting and preserving it.
• The chain of custody records who handled the evidence, when and how: collecting it, copying it, analysing it and presenting it.
• Chain of custody doesn't mean nothing changed. Moving a drive to a lab changes something. It means there's a reliable, documented history, so the evidence can be relied on. Keep the scope tight too: in a multitenant cloud, collecting too much could expose another customer's data.
• Useful evidence has five attributes. Authentic: genuine and tied to the incident. Accurate: its integrity isn't in doubt. Complete: presented in full, even the parts that weaken the case. Convincing: it clearly supports the claim. Admissible: it satisfies whoever rules on it, for example a court.
• Handling digital evidence has four phases: collection, examination, analysis and reporting. Collection may start during routine incident response, before anyone knows a prosecution will follow, so responders must handle evidence properly from the start.
• When collecting, use the original media where you can; when analysing, always use verified copies. Hash the original and the copy, and check they match.
• Follow the procedure: a named evidence custodian, a log of every action, and systems left on to keep volatile data. And keep in touch with the provider, legal counsel and law enforcement.
• Then preserve it. Store it securely and sign it in and out, like a library book. Control temperature, humidity and power. Block interference: a Faraday bag stops a phone being wiped remotely. Analyse copies, or use a write blocker, which allows reading but not writing. And document everything.
• In the cloud, physical evidence may be out of reach, and if it really must be collected, the provider will likely insist on law enforcement. Some providers offer their own forensic tools and staff.
• Agree in advance, in the contract, what yours will provide.
• Our call: not necessarily ruined, but weakened. Record exactly what was done, when and by whom, so the chain of custody stays honest.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-86: Integrating Forensic Techniques into Incident Response

In this lesson

Communicating with vendors, customers, partners, regulators and other stakeholders.

Key points

• Cloud operations depend on good communication with many parties. We'll take them in order: vendors, customers, partners, regulators, then other stakeholders.
• Four questions shape any message: who is it for, what must it say, why does it matter to them, and when is it needed?
• Who sets the level of detail, and in an incident, legal may review what goes to the public. What must answer the question: so what? Why means the audience can act on it straight away. And when matters: a breach reported years late is likely to be of little use, and looks like a cover-up.
• Vendors first. Start with an inventory of critical third parties, like your cloud provider or payment processor, and treat communication with them like internal communication. Contracts and SLAs should give two-way channels: notice of planned and unplanned downtime, and a way for you to report problems, often through tickets.
• Customers. Here, you're the customer of your cloud provider, and your key duty is to define the SLA terms for communication: how fast incidents are acknowledged, notice of maintenance, support hours, and performance reports.
• And the shared responsibility model is a key thing to communicate: who secures what.
• Partners often have access like employees, but aren't under your control. Communicate at three stages. Onboarding: due diligence, then security requirements in the contract. Management: access, audits, and joint incident and recovery testing. Offboarding: remove access, recover assets, and remind them of confidentiality.
• Regulators. Watch for new requirements: GDPR's rules on data leaving the EU, for example, shaped many cloud architectures. And where you must report your compliance to a regulator, do it on time.
• Other stakeholders. The public: incident statements, prepared with PR and legal. Security researchers: publish a security contact for responsible disclosure, perhaps with a bug bounty. Investors: required filings may include security matters. And in a crisis, follow your communications team's documented procedures.
• Our call: tell the affected clinics promptly, through the agreed channel, but don't post details publicly until legal and PR have reviewed them.
• As their processor, Aldermoor must tell the clinics without undue delay, and they decide on wider notices.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); 45 CFR 164.402 to 164.410 (HIPAA Breach Notification), via Cornell LII

In this lesson

The security operations centre, and intelligent monitoring of security controls.

Key points

• Two topics, in order: the security operations centre, then intelligent monitoring of security controls.
• The security operations centre, or SOC, brings day-to-day security work together. In the cloud there are at least two: the provider's, for what it controls, and yours, chiefly for your data.
• A SOC's main jobs: continuous monitoring and reporting, often on dashboards. Data security monitoring, wherever sensitive data lives. Alert prioritisation, with set procedures for acting. Incident response, where SOC staff are often the core of the team. And support for compliance, from configurations and scan results.
• The cloud changes the tools. Many older tools rely on copying traffic from a physical switch port, which a virtual cloud network doesn't offer, and encryption can hide data from monitoring. So SOCs use the provider's own tools, often joined to theirs through APIs.
• Examples are Microsoft Sentinel and Amazon GuardDuty.
• Build or buy? Providers can justify round-the-clock SOCs, because the cost is shared across many customers. A small, cloud-only organisation may outsource to a managed security service provider, or MSSP. It's a trade-off between control and cost, decided by business leaders with security's advice.
• Monitoring of security controls used to happen at infrequent audits, yearly or even less often. Continuous monitoring, in NIST's Risk Management Framework, aims for near real-time awareness. Watch two things: is the control working, and what alerts has it raised? An intrusion detection system that spots an attack nobody acts on isn't an effective control.
• Watch firewalls, web application firewalls, intrusion detection and prevention, and honeypots: are they running, what are they flagging, and what's trending, like dropped packets or honeypot activity?
• Network security groups belong on the list too.
• And when systems change, say a move to SaaS, the SOC should be part of the change.
• AI now helps. Microsoft Sentinel's Fusion engine uses machine learning to link signals into multistage attacks, with fewer false positives.
• Amazon GuardDuty uses threat intelligence and machine learning to spot things like stolen credentials or cryptomining.
• People still need to oversee the tools.
• Our call: say what the MSSP must do for high-priority alerts, such as phone the on-call lead and isolate the server under agreed authority, and test it. An alert that ends in an inbox protects nothing.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Microsoft Sentinel: multistage attack detection (Fusion); AWS: What is Amazon GuardDuty; NIST SP 800-37 Rev. 2: Risk Management Framework

In this lesson

Logs, SIEM tools, log management and threat intelligence.

Key points

• Logs record the events in your systems and networks, from firewalls and antivirus to operating systems and apps. There are far too many for people to read unaided.
• We'll take it in order: the SIEM, log management, then threat intelligence.
• A security information and event management tool, or SIEM, does four jobs. It centralises logs, which also keeps them out of reach of people who could alter them on the source system. It normalises them, for example to one time zone and consistent field names. It correlates events. And it raises alerts.
• Correlation links events. A login from another country, then email access, then mass downloads could mean stolen credentials, or a user at a conference. Add travel records, threat intelligence or the provider's status feeds, and the picture gets clearer.
• Each alert should lead to a set procedure, often tracked as a ticket. PaaS and SaaS can be blind spots, because providers rarely share their internal logs. A cloud access security broker, or CASB, can fill the gap by logging users' activity in cloud services.
• Logs are critical evidence, so protect them. Store them on write once, read many media, so they can't be changed. Restrict access, because logs can hold sensitive data. Monitor capacity, and rotate or move older logs offline. Keep them as your retention schedule and the law require, then delete them securely.
• Configure what gets logged. The clipping level decides which events are recorded: a login or a password change is worth keeping; a routine clock sync may not be. And check that forwarded logs match the originals, with an alert if forwarding is tampered with or stops.
• Threat intelligence is threat information that's been analysed and given context, so it supports decisions. It includes indicators of compromise, such as known bad addresses or file hashes, and attackers' tactics, techniques and procedures.
• Feeds can warn early, for example of stolen credentials on the dark web, or look-alike domains.
• Our call: keep the login events. They're among the most valuable, because they show access controls at work, and they're evidence in an investigation.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-61 Rev. 3: Incident Response Recommendations; NIST SP 800-53 Rev. 5: Security and Privacy Controls; AWS: What is Amazon GuardDuty

In this lesson

Incident response, vulnerability assessment and penetration testing.

Key points

• Three topics, in order: incident response, vulnerability assessment, then penetration testing.
• An incident response capability has three parts: a plan with scenario-based procedures, a trained team with a coordinator who can assemble it, and root-cause analysis after each incident.
• Most models share the same phases. Prepare: the plan, the team, training and detection. Detect: monitoring, audits, user reports and researchers, documented from the first moment. Respond: in most incidents, contain first, to stop further damage. Recover: remove the cause and return to normal service. Post-incident: lessons learned and root cause.
• NIST's incident response guide changed in April 2025. Revision three maps incident response to the six functions of version two of the Cybersecurity Framework. Govern, identify and protect are wider risk work that prepares you. Detect, respond and recover handle the incident. And lessons feed improvement all the time, not just at the end.
• If normal operations can't be restored, the coordinator may declare an interruption or a disaster, which invokes the continuity and disaster recovery plans.
• In the cloud, keep the provider's contacts ready. Even if the provider caused a breach, the data controller still has legal duties. One advantage: you can rebuild virtual systems to a known good state quickly.
• Vulnerability assessments use scanners to find possible weaknesses. Run them on a schedule, often outside business hours, or on a trigger, such as a new release reaching production. Scan from inside and outside, to see what an insider or an outsider could find.
• Penetration testing goes further: it tries to exploit the weakness, to confirm it's real and see how far an attacker could get. NIST's testing guide gives one common model, with four phases: planning, with rules agreed and management approval; discovery, including vulnerability analysis; attack; and reporting, which runs throughout.
• Penetration tests carry risk, because they use real attacks, sometimes on production systems. So agree the rules first, consider a similar non-production system, and stop before an action would cause damage. Because of cost and impact, a yearly test may be enough, with regular scanning in between.
• Our call: don't wait. Check the finding now, then patch or reduce the risk on your normal timeline for critical flaws. Penetration tests confirm and go deeper, but they don't replace acting on scans.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-61 Rev. 3: Incident Response Recommendations; NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

What you're building

One workbook that pulls Domain 5's response work together for a cloud service: who to call, how to set priority, what each phase involves, first steps for likely scenarios, how to collect and log evidence, who to tell, and what you learned. Compare your answers with Aldermoor's, then fill in the blank copy for a service of your own.

What each sheet records

• Contacts: each role, who fills it, how to reach them and when to call. An incident plan names the team, a coordinator, and the roles of outside parties such as the cloud provider, and you need the provider's contacts ready before anything goes wrong.
• Priority: rate each incident's impact and urgency, and the sheet gives a priority and a response. Plotting urgency against impact is a common way to prioritise, and a high enough priority can trigger the continuity plan. The four levels and the rule behind them are our own choice; set yours to fit.
• Phases: actions under prepare, detect, respond, recover and post-incident, with an owner for each. A row turns red while a preparation step reads No. NIST's current guide, Revision 3 of SP 800-61 (April 2025), maps the same work to the Cybersecurity Framework 2.0 functions; use whichever model suits you.
• Playbooks: first signs, containment, evidence, recovery and who to tell, for the scenarios you're most likely to face. Scenario-based procedures, written in advance, beat decisions made under stress.
• Evidence first steps: what to do before anything is shut down or rebuilt: open the log, keep volatile data, snapshot, hash, copy and analyse only copies.
• Custody log: every action on every item: who, what, when, where it is and why, with its hash. The chain of custody doesn't prove nothing changed; it documents everything that did.
• Communications: each audience, what they need, the channel, who approves and when. Public statements go through legal and PR.
• Lessons learned: root cause, what went well, what to improve, and an owned action, feeding continual improvement.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its names, times and hashes are invented; the 24-hour notice to clinics is our suggested contract term. This is not legal advice: decide notices with counsel, and check the deadlines in Domain 6.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-61 Rev. 3: Incident Response Recommendations; AWS Well-Architected Framework: Security Pillar; NIST SP 800-86: Integrating Forensic Techniques into Incident Response

In this lesson

What this module covers, and what you'll build.

Key points

• Domain 6 is 13% of the exam, the smallest by weight.
• Our view is that it punches above that. Getting law wrong can cost money, or close a market to you altogether.
• This module has five parts: law across borders, privacy, audit, risk, and contracts.
• Nobody expects you to practise law. Your job is to notice legal risk, and bring it to your lawyers early.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Why more than one law can apply to one record, a worked CLOUD Act and GDPR example, and what to tell a customer. Outline: 6.1.

Key points

• Picture one Aldermoor record. It's stored in one country, on a provider headquartered in a second, about a patient living in a third. Each of those places may have a claim, and their laws may disagree.
• Start with reach. The GDPR applies to processing in the context of an establishment in the Union, wherever the processing happens. It also applies to organisations outside the Union that offer goods or services to people in the Union, or monitor their behaviour in the Union.
• Now the classic collision. The GDPR restricts transfers of personal data outside the Union.
• A foreign court judgment or authority's decision to disclose data may only be recognised or enforced if it's based on an international agreement, such as a mutual legal assistance treaty. Any transfer without one would need its own ground under the GDPR.
• But under the US CLOUD Act, a communications or remote computing provider must meet its US duties to preserve or disclose communications and customer records in its possession, custody or control, wherever they're stored.
• Let's walk it through. A German clinic on Aldermoor's platform has its records in Frankfurt, with a US provider underneath. A US authority serves that provider with a demand for some of those records. Step one: if those records are covered, the US duty reaches what's in the provider's possession, custody or control, wherever it's located, so Frankfurt alone doesn't end the question.
• Step two: in the EU, a foreign court judgment or authority's decision is only recognised or enforced if it's based on an international agreement, and any transfer without one would need its own ground.
• So European servers may not settle the question, if your provider falls under US law. Changing the corporate structure may be part of the answer, and that's a job for lawyers.
• The same kind of clash goes beyond privacy. One place's deadline for reporting a breach may not match another's, and limits on exporting a technology can stop it crossing a border.
• Legal systems differ too. Where law rests on statute, you can read what's coming. Where it rests on court decisions, it can shift with less warning. And it varies inside countries: breach deadlines change from one US state or Canadian province to the next.
• Our call: don't promise it. Hosting in the EU helps, but a provider under US law may still face a demand.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); 18 U.S.C. 2713 (CLOUD Act: required preservation and disclosure), via Cornell LII

In this lesson

Where a legal duty comes from, the international frameworks behind many laws, GDPR roles, and a worked obligations register. Outline: 6.1.3.

Key points

• Words matter here. Some duties come from legislation. Some come from a regulator, which turns legislation into detailed rules. Others come only from an agreement you signed. What's at stake differs: criminal or financial penalties at one end, and at the other a lawsuit or a lost customer.
• Some examples, starting with Aldermoor's own. PCI DSS, for clinic payments, is contractual: it applies because card issuers require it, so what you risk is penalties and the ability to process cards.
• The GDPR and HIPAA are legislation.
• And FISMA shows the regulator's pattern: it obliges US agencies to run security programmes, and NIST publishes the detailed guidance.
• Behind many laws sit international frameworks. The OECD's privacy guidelines include limits on collection, stating your purpose, safeguards and accountability.
• APEC's framework, from 21 Pacific economies, has nine principles, such as preventing harm and giving notice.
• Then the GDPR, the one you'll meet most. The controller determines the purposes and means of processing. The processor processes on the controller's behalf.
• In cloud, that's often customer and provider.
• The top tier of fines is up to 20 million euros or, for an undertaking, 4% of total worldwide annual turnover, whichever is higher, and a lower tier is 10 million or 2%.
• Using a provider doesn't hand over your accountability. A controller must use only processors offering sufficient guarantees, and must be able to demonstrate compliance.
• Processors have their own duties, and can be liable and fined too.
• Some rules also put a name on it: HIPAA's Security Rule requires you to identify a security official.
• Let's sort four of Aldermoor's duties, as our worked example. The GDPR is legislation, and the fines you just saw sit behind it. HIPAA is legislation too, and it applies if Aldermoor is a business associate. PCI DSS, for clinic payments, is contractual, so the risk is penalties and the ability to process cards. A clinic's security schedule is contractual as well, so the risk is a lawsuit or a lost customer.
• Our call: it's binding. The body that publishes the framework doesn't mandate it, but your contract does, and a customer can ask for proof.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); 45 CFR 164.306 to 164.314 (HIPAA Security Rule) and 160.103 definitions, via Cornell LII

In this lesson

How eDiscovery and forensics change in cloud, a worked chain-of-custody example, and the standards to recognise. Outline: 6.1.4 and 6.1.5.

Key points

• Suppose a court case needs Aldermoor's data. eDiscovery means finding and securing that electronic data so that it can be used as evidence. In cloud, nearly all of that work happens with live systems, though snapshots can still be analysed separately. In a data centre, by contrast, you might image a server and study it offline.
• Cloud makes it harder in three ways. Each extra party handling evidence makes its chain of custody harder to prove. It may sit where another country's rules get in the way. And the provider may hold what you need, with you having no power to demand it.
• So prepare before you need it. Raise eDiscovery while you're choosing a provider and negotiating the contract. Keep contacts and escalation routes in your incident plan.
• Watch the logs. Don't assume your provider keeps what you'll need, or keeps it for long. A provider tends to record what it needs to run and bill the service. What your users did inside your application is yours to record.
• Here's a worked example of ours. Aldermoor needs a snapshot of a compromised server. The provider's staff take it, a storage service holds it, and an outside analyst reads it. That's three hand-offs, so that's three records you'd want: who had it, when, and what they did. If you can't show that, the chain of custody gets harder to prove.
• The outline names standards you should recognise. ISO/IEC 27050 is about eDiscovery.
• On forensics, 27037 covers handling digital evidence, 27041 whether your methods are fit for purpose, 27042 analysis and interpretation, and 27043 investigation principles and processes. CSA's guidance covers the legal side, including contracts.
• One warning. Forensics is a specialist job, and well-meaning people can spoil evidence just by touching it.
• Our call: Aldermoor owns this gap, because the provider may never have kept what's needed.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026

In this lesson

Why some private data is regulated and some contractual, a worked sort of Aldermoor's data, and what GDPR Article 28 requires. Outline: 6.2.1.

Key points

• Privacy and security aren't the same. Privacy is often a right that the law gives a person. Security is one of the ways you help honour it.
• So begin by asking what kind of private data you hold, and why you must protect it. The outline contrasts contractual and regulated data.
• Two terms first. Personally identifiable information points to a person. A name does that alone; a date of birth may only do it combined with something else.
• Protected health information is a HIPAA term for identifiable health information, including care and payment, though it excludes employment records a covered entity holds as an employer.
• The key difference is where the duty comes from. For regulated data, it's the law, so failure can bring statutory penalties and regulators may audit you.
• For contractual data, it's what the parties agreed, so they shape the controls and the remedies. Laws can be prescriptive, though some, like HIPAA's Security Rule, allow flexibility.
• Contracts do two useful jobs. They protect data that no specific privacy law covers, like confidential business plans. And they carry duties down a supply chain, which is what a HIPAA business associate agreement does.
• Let's sort two things Aldermoor holds, as our worked example. A patient's visit note identifies a person and covers their care, so privacy law is likely to apply, depending on where the patient is, and the clinic's contract may add stricter terms on top.
• Article 28 of the GDPR shows what a processor contract must say. Grouped our way: instructions, meaning act only as the controller directs. People, meaning confidentiality and security. Others, meaning sub-processors only with authorisation. Help, meaning support with people's rights, security, breaches and impact assessments. Proof, meaning information and audits. And the end, meaning delete or return the data.
• Our call: no. He may be right about HIPAA. But names identify people, so other privacy laws may apply, depending on where those staff are, and the clinic's contract may cover it too.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; 45 CFR 164.306 to 164.314 (HIPAA Security Rule) and 160.103 definitions, via Cornell LII; Regulation (EU) 2016/679 (General Data Protection Regulation)

In this lesson

The five privacy laws the outline names, one at a time, then applied to Aldermoor's markets. Outline: 6.2.2.

Key points

• The outline names five laws for you to recognise: FERPA, PIPEDA, the GDPR, HIPAA and India's Digital Personal Data Protection Act.
• Let's take them one at a time, in that order. It isn't the whole world, so in real work start by listing the laws that touch your own data.
• FERPA, the US Family Educational Rights and Privacy Act, gives parents and eligible students rights over education records at institutions receiving US Department of Education funds.
• Canada's PIPEDA applies to personal information collected, used or disclosed in the course of commercial activities.
• Under its first principle, an organisation stays responsible for information it transfers to a third party for processing, and must use contracts or other means to provide comparable protection.
• The GDPR gives people rights over their data, including access and erasure.
• Its principles include purpose limitation, data minimisation, storage limitation, integrity and confidentiality, and accountability.
• Health data is a special category, with stricter conditions.
• The UK has its own version, the UK GDPR, which applies to Aldermoor at home.
• HIPAA is a US federal law for health information held by covered entities and their business associates. Its Security Rule binds both directly, and requires them to ensure the confidentiality, integrity and availability of electronic protected health information.
• Remember the US has no single overarching privacy law. It's a patchwork, with states such as California adding their own.
• India's Digital Personal Data Protection Act is new to the outline.
• This is a sketch, from a 2023 summary of the bill by PRS India. According to that summary, it applies to digital personal data processed in India, and to processing abroad for offering goods or services there. Processing generally needs consent, with exceptions for specified legitimate uses.
• It calls the responsible party a data fiduciary, which must keep data secure and delete it once its purpose has been met.
• Our call: no. A strong baseline helps, but reporting duties vary between jurisdictions, and that 2023 summary shows India's bill didn't mirror all the GDPR's rights.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); US Department of Education: FERPA; Canada: Personal Information Protection and Electronic Documents Act; Regulation (EU) 2016/679 (General Data Protection Regulation); UK ICO: Guidance on AI and data protection; 45 CFR 164.306 to 164.314 (HIPAA Security Rule) and 160.103 definitions, via Cornell LII; ISC2 CCSP Certification Exam Outline, effective 1 October 2025 (superseded); PRS India: Digital Personal Data Protection Act, 2023 summary

In this lesson

Whose law applies along the chain, the GDPR's order for transfers, the EU-US story, and a worked data path. Outline: 6.2.3.

Key points

• For Aldermoor, walk the chain and ask where each party is: the patient, the clinic, Aldermoor itself, then the cloud provider and anyone it subcontracts to. Any of them can bring another law into play, and head offices count too.
• The GDPR's approach to transfers has a clear order. Article 44 says transfers must keep the regulation's level of protection.
• Article 45 allows them where the Commission has decided a country is adequate, so that data can flow with no further safeguard.
• Without that, Article 46 requires appropriate safeguards, such as standard data protection clauses and binding corporate rules.
• For Aldermoor, one piece of luck: the Commission lists the United Kingdom as adequate.
• The US story shows how this moves. An earlier arrangement, Safe Harbor, was struck down in 2015, and Privacy Shield replaced it.
• In July 2020, the Court of Justice's Schrems II decision raised points about US access to data, and new US safeguards followed. On that basis, the Commission adopted its adequacy decision for the EU-US Data Privacy Framework on 10 July 2023, Implementing Decision 2023/1795.
• Its list now names that framework for the US, not Privacy Shield, and only for commercial organisations participating in it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); European Commission: adequacy decisions; European Commission: EU-US data transfers

In this lesson

ISO/IEC 27018, the Generally Accepted Privacy Principles and GDPR rights, with a worked access request. Outline: 6.2.4.

Key points

• The outline names three standard privacy references here: ISO/IEC 27018, Generally Accepted Privacy Principles, and the GDPR.
• Let's take them in that order. An audit against privacy criteria gives customers a report they can use to judge a provider's practices.
• ISO/IEC 27018 is the cloud privacy standard. Think of it as questions a customer can put to a provider. Where is my data, and who are your subcontractors? Who independently checks you? Will you tell me about incidents? Do I stay in control? And may you use my personal data for marketing?
• Generally Accepted Privacy Principles came from a task force of accountants in the US and Canada, and SOC 2 audits can optionally draw on them. There are ten, and it helps to group them, as we do here. What you owe the person: notice, choice and consent, and access. How you treat the data: collection, use, retention and disposal, quality, and security. Who else sees it: disclosure to third parties. And how you run it all: management, monitoring and enforcement.
• GDPR rights need something real behind them. The right of access needs you to find a person's data. The right to erasure needs you to delete it.
• Walk one request, as our worked example. A patient asks a clinic for their data. The clinic is the controller, so it asks Aldermoor to help, and Aldermoor's processor contract must commit it to do that, as far as it can.
• Privacy can also pull against security. Watching traffic helps you catch data leaving, yet staff have privacy rights too, and what you must do first varies by country. Sometimes telling people is enough. Sometimes you need a documented justification.
• Our call: trace every copy, using the data map. The right to erasure has conditions and exceptions, so the clinic and counsel decide what applies.
• Aldermoor's processor contract must commit it to help the clinic respond, as far as it can.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation)

In this lesson

When a privacy impact assessment is needed, what it contains, and a worked page for Scribe. Outline: 6.2.5.

Key points

• A privacy impact assessment asks: what personal data does this system touch, and what happens to people if it goes wrong?
• Our comparison: a business impact analysis looks at harm to the business, and this looks at harm to people. Under the GDPR, a data protection impact assessment is needed where processing is likely to result in a high risk to people.
• Article 35 gives three examples of when one is required, and the list isn't exhaustive. They are systematic and extensive automated evaluation that leads to significant decisions, large-scale processing of special categories of data or of criminal conviction data, and large-scale monitoring of a publicly accessible area. Health data is a special category. An assessment must describe the processing, assess necessity and proportionality, assess the risks to people, and set out measures to address them.
• Here's Aldermoor's for Scribe, as a one-page record, and this is our worked example. At the top, it says what's covered: Scribe, not all of Aldermoor. Next comes a diagram following a note into the training set and out as a summary. Beside each step, it names the rules triggered. And the last column gives each risk a control and an owner.
• Here's one row. The step is training on clinical notes. The rule, unless counsel says otherwise, is health data as a special category, because de-identified notes may not stay anonymous.
• For Scribe, the assessment might say that a managed AI service can't be used for clinical notes, or that notes from one region can't leave it. Findings like that can reshape a cloud design.
• Our call: before launch. Article 35 puts the duty on the controller, and where high risk is likely, the assessment comes prior to the processing. Where necessary, it's reviewed when the risk changes.
• Where the clinics are controllers, Aldermoor's processor contract must commit it to assist them, as far as it can.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); EDPB Opinion 28/2024 on data protection aspects of AI models

In this lesson

Internal and external audit, what shapes your audit duties, and why cloud changes the evidence and access. Outline: 6.3.1 to 6.3.3.

Key points

• An audit answers a question outsiders can't check for themselves: are your controls designed sensibly, and are they actually working?
• There are two kinds of auditor. An internal auditor works for the organisation, can look more often, and knows how it really runs. To stay credible, internal audit usually sits under a different leader from IT.
• An external auditor isn't employed by the organisation it audits, and is generally barred from also advising it. Its report carries more weight with outsiders, and some frameworks require one.
• What you must audit, and when, comes from outside the security team. Your sector, the data you hold, and the laws that apply all shape it, and so do your customers.
• Contracts can set the timing: a customer might want a first report within a set period after signing, then one every year.
• Cloud also changes the evidence. Automatic failover can move a compliant system into a region where it isn't compliant. It's hard to prove the virtual server you audited in March is the one running in June. And with data spread across regions, a fair sample is harder to take.
• The biggest change is access. Providers rarely let customers audit their facilities, and the right hardware may be impossible to find anyway. So assurance comes from the provider's independent reports, and checking a provider becomes vendor risk management.
• Responsibility splits too: the provider is usually audited for the hypervisor, and the customer for the virtual machines it runs on top.
• Here's a worked example of ours: Aldermoor's audit stack. At the bottom, the provider's own audit report covers its data centres and hypervisors. In the middle, Aldermoor's audit covers what it runs: its application, its access controls, and its virtual machines. As a software provider built on someone else's infrastructure, Aldermoor needs its own report for that layer.
• Our call: offer the reports, not a visit. Customers can carve the provider's controls out of their own audit scope and rely on the provider's auditors instead.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

SOC 1, SOC 2 and SOC 3, the SSAE and ISAE standards behind them, CSA STAR, and why scope comes first. Outline: 6.3.4 and 6.3.5.

Key points

• When Aldermoor asks its provider for assurance, a report comes back. The outline names SSAE, SOC and ISAE.
• So we'll cover SOC 1, SOC 2 and SOC 3, then the SSAE and ISAE standards behind them, and we'll add CSA STAR because it's built for cloud.
• SOC reports come from the AICPA, whose framework lets accountants give assurance on controls at an outsourced service.
• SOC 1 is about controls that matter to a customer's financial statements. Its main readers are the auditors of those statements, so it's rarely what a security team needs.
• SOC 2 is the security one. It reports on controls relevant to security, availability, processing integrity, confidentiality and privacy. A Type 1 report looks at how controls are designed, at a single date. A Type 2 report also tests whether they operated effectively, over a period, so it gives more assurance. Providers usually share a SOC 2 only under a nondisclosure agreement.
• SOC 3 is the public version. It carries the auditor's general opinion without the sensitive detail of a SOC 2, so anyone can read it.
• Behind these reports sit the standards auditors follow. SSAE is the AICPA's attestation standard for SOC work, used mainly by auditors.
• Internationally, the International Auditing and Assurance Standards Board issues the ISAE standards, which are similar but not identical, and the major providers offer reports under both. So check with your business which reports your customers and regulators expect.
• CSA STAR is cloud-specific, and its controls come from the Cloud Controls Matrix. At Level 1, the provider assesses itself, which is weak assurance. At Level 2, an independent auditor checks it.
• The Consensus Assessments Initiative Questionnaire gives yes or no questions for assessing providers, and the STAR Registry is public.
• Whatever the report, read its scope first. The scope statement says what was audited and what was left out, and if the service you use was left out, the report tells you nothing about it.
• Scopes get narrowed for good reasons, such as cost or a service that isn't ready, so never assume a famous name means full coverage.
• Here's our worked example: Aldermoor reads its provider's SOC 2 in four steps. One: is it Type 2, and does the period cover recent months? Two: is each service Aldermoor uses inside the scope? Three: are there exceptions or findings? If a finding touches a service Aldermoor uses, Aldermoor inherits that risk.
• Our call: no. For a service outside the scope, the report gives no assurance at all.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); AICPA and CIMA: SOC 2; CSA Cloud Controls Matrix (landing page)

In this lesson

Gap analysis as three questions, CSF 2.0 profiles, and the phases of an audit. Outline: 6.3.6 and 6.3.7.

Key points

• Clinics keep asking Aldermoor for an independent report, so it plans its first SOC 2. Before any auditor arrives, it needs to know where it stands. That's a gap analysis: compare what you actually do against a chosen framework, and list where they differ. It's quicker and less rigorous than an audit, which makes it a good first step, and a good response when requirements change.
• Think of a gap analysis as three questions. Against what? Agree the framework and the scope, with management behind it. Where are we really? Find out through interviews and evidence, and check what you're told. And what's missing? Name the gaps, and get leaders to sign off the findings.
• Common yardsticks include ISO 27002 and the NIST Cybersecurity Framework.
• The current version of the NIST framework, CSF 2.0, builds this in. A Current Profile describes the outcomes you achieve now. A Target Profile describes the ones you've chosen to reach. You analyse the gaps between them and write a prioritised action plan.
• And when you prioritise, put first the gaps that match real risks.
• Then plan the audit itself. Planning answers four questions, often months ahead. What are we auditing, and what will we get at the end? Against which standard, and which scope? Who will audit, with the right qualifications? And are we ready, which a readiness check tells you?
• A SOC audit, for example, needs a licensed accountant.
• After planning come three more phases. In fieldwork, auditors examine evidence, interview people and test controls. In reporting, you usually see a draft and can correct errors before the final report. In follow-up, you fix findings, and some auditors retest and add a note to the report.
• Many organisations then treat audit as continuous, not a yearly event.
• Our call: finish the gap analysis and fix the top gaps first. A Type 2 tests controls over a period, so controls that are still being built will show up as findings.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST Cybersecurity Framework 2.0

In this lesson

The ISMS, control frameworks, policies, policy exceptions and audit stakeholders. Outline: 6.3.8 to 6.3.11.

Key points

• An audit checks something that already exists: a way of running security. The outline lists four related topics: an information security management system, a system of controls, policies, and the stakeholders involved.
• An ISMS is a systematic way of managing security, through processes, technology and people. ISO 27001 sets out the requirements for one, built around managing risk.
• It needs leadership's backing to work. For a cloud customer like Aldermoor, its ISMS is where every cloud control and risk decision lives.
• Beside the ISMS sits a control framework, a catalogue of good practice to treat the risks it finds. Examples include ISO 27002, NIST SP 800-53, the NIST Cybersecurity Framework and the CSA Cloud Controls Matrix. You scope it, keeping the controls that apply, then tailor it to fit how you work.
• The current NIST framework, CSF 2.0, has six functions, with Govern at the centre informing Identify, Protect, Detect, Respond and Recover.
• Policies are formal, high-level and approved by management. Organisational policies set the general rules. Functional policies cover specific activities, such as data classification, acceptable use and incident response.
• Cloud adds its own risk: shadow IT, a service the organisation doesn't know about. So a cloud policy says which services are approved, and checks that providers meet your rules on things like MFA, encryption and third-party access.
• When a provider can't meet a policy, don't hide it. Treat the exception as a risk, document it, and add compensating controls.
• Finally, stakeholders. An audit needs the staff who provide evidence, the security team who run it, and management, who usually pay for it. Cloud adds more: a software provider and the infrastructure under it, as well as any contract limits on audits.
• Our call: don't quietly skip it. Record it as a policy exception, which makes it a risk, and add compensating controls, such as Aldermoor encrypting the backups with its own keys. Review it if the threat changes.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST Cybersecurity Framework 2.0

In this lesson

Regulated industries such as NERC CIP, HIPAA and PCI DSS, and auditing a distributed cloud. Outline: 6.3.12 and 6.3.13.

Key points

• Moving to cloud doesn't move your compliance duties. Responsibility for meeting regulations stays with the cloud customer.
• Many providers offer services built for specific regimes, and a regulated customer usually relies on the provider's audit reports to show those services meet the rules.
• The outline names examples, so let's take three in turn. NERC CIP covers organisations that generate and deliver power in the US and Canada, including their use of cloud. HIPAA, as amended by the HITECH Act, covers protected health information, with security, privacy and breach notification duties. PCI DSS covers payment card data.
• HIPAA and PCI DSS don't specifically address cloud, so you check that your provider can meet them before you move regulated data.
• Because big public providers rarely allow customer audits, organisations with the same regulations sometimes share a community cloud, designed around those rules.
• Now the distributed model. Auditors don't check every server; they sample. Aldermoor's auditor might check 15 of its 60 virtual machines to see whether logging is set up as policy says.
• In cloud, that sample spans many countries, and virtual servers can move between hardware almost instantly. So providers supply evidence through continuous monitoring, and audits that need site visits cost more.
• Jurisdiction adds friction too. An auditor may need visas or work permits to visit a facility abroad, so involve legal advisers early.
• Our call: check before switching it on. A system that's compliant in its normal region can break the rules once it fails over to another one.
• For EU personal data, in our reading, that failover is a transfer, so the GDPR's transfer rules from lesson six point six apply.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2016/679 (General Data Protection Regulation)

In this lesson

Assessing a provider's risk programme, risk profile and appetite, and the five data roles. Outline: 6.4.1 and 6.4.2.

Key points

• Cloud changed enterprise risk. Servers that once took weeks to build now take minutes, and someone can create infrastructure in another country, under different laws, almost by accident.
• The major providers don't allow customer audits, so you assess them indirectly, as supply chain risk management. First, does the provider have a risk programme, and are the risks it finds being dealt with? Its independent reports, such as SOC 2, ISO 27001, FedRAMP or CSA STAR, are your evidence.
• Read the scope and the findings. A finding in a service you use becomes your risk too.
• Two more things to judge. Risk profile is the risk an organisation actually carries, after its controls. Risk appetite is the level of risk it chooses to live with rather than reduce. A young start-up usually carries more, and accepts more, than a bank.
• Now the data roles. The outline lists them, and we'll take them in order: owner, controller, custodian, processor and steward.
• Behind them all is the data subject, the person the data is about.
• The data owner, or controller, decides why and how personal data is processed. In GDPR terms, that's the controller, which determines the purposes and means of processing.
• The owner carries the risk if the data is breached, even when someone else holds it.
• The data custodian, or processor, handles the data on the owner's behalf, and protects it as the owner directs. The GDPR's processor processes personal data on the controller's behalf.
• NIST treats the information owner or steward as one role: an official with authority over specific information, who sets the rules for its use and protection, and keeps that responsibility even when it's shared.
• Here's our worked example: Aldermoor's chain. The patient is the data subject. The clinic decides why the visit note exists, so it's the owner and controller. Aldermoor processes it for the clinic, so it's a custodian and processor, and its cloud provider is a further processor below it. Inside the clinic, a named person acts as steward, setting the rules for that data. That's our reading for a fictional company.
• Our call: it's still the clinic's problem too. The owner stays accountable when a processor is breached, so the clinic's contract has to carry its security demands to Aldermoor: how data is protected, how fast breaches are reported, and whether insurance is required.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; Regulation (EU) 2016/679 (General Data Protection Regulation); NIST SP 800-37 Rev. 2: Risk Management Framework

In this lesson

Breach notification under the GDPR and HIPAA, Sarbanes-Oxley records duties, and GDPR transparency. Outline: 6.4.3. Not legal advice.

Key points

• Regulators expect organisations to be open about what happens to data. The outline gives three examples, and we'll take them in order: breach notification, the Sarbanes-Oxley Act, and the GDPR's transparency rules.
• This isn't legal advice; counsel confirms what applies to you.
• Most modern privacy laws require breach notification, but they differ on timing, on whether a suspected breach counts, and on who must be told: the people affected, a regulator, or both.
• So your incident plan needs each deadline and each contact written down in advance.
• Under the GDPR, a controller tells the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to put people at risk. A processor tells the controller without undue delay.
• If the risk to people is high, the controller tells them too, unless, for example, the data was encrypted so it's unintelligible.
• Under HIPAA's breach rule, for a breach of unsecured protected health information, a covered entity tells each affected person without unreasonable delay, and no later than 60 days after discovery. For 500 or more people, it tells the Secretary at the same time. A business associate tells the covered entity, also without unreasonable delay and within 60 days.
• The Sarbanes-Oxley Act of 2002 applies to companies publicly traded in the US.
• For security, the key point is records: it's a crime to destroy, alter or hide documents so they can't be used in official legal proceedings, and losing data in an attack doesn't remove the legal duties.
• The GDPR's transparency rule is Article 12. A controller must give people information in a concise, transparent, intelligible and easily accessible form, using clear and plain language.
• In practice, that means telling people plainly why you collect their data and what you do with it.
• Here's our worked example: a breach at Aldermoor touching EU and US clinics' patients. Aldermoor's clock starts when it discovers the breach. As a processor, it tells the EU clinics without undue delay, so they can meet their 72 hours. As a business associate, it tells the US clinics no later than 60 days, and in practice much sooner. Its contracts may set a tighter limit, such as 24 hours. The clinics then decide what to tell authorities and patients.
• Our call: tell the clinics now, and update them as facts arrive. A processor must notify without undue delay, and a controller can give the authority information in phases.
• Waiting for certainty would break Aldermoor's own duty to tell them without undue delay, and leaves patients exposed for longer.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); 45 CFR 164.402 to 164.410 (HIPAA Breach Notification), via Cornell LII; SEC: The laws that govern the securities industry (Sarbanes-Oxley)

In this lesson

The five risk treatments, risk frameworks, risk metrics and assessing a provider's risk environment. Outline: 6.4.4 to 6.4.7.

Key points

• Once you've found a risk and judged its likelihood and impact, you decide what to do about it. The outline names five treatments, and we'll take them in order: avoid, mitigate, transfer, share and accept.
• Avoid means not doing the risky activity at all, which often costs you the opportunity too. Mitigate means adding controls that cut the likelihood or the impact, often several in layers.
• Transfer usually means insurance, which pays out after an incident. Share means splitting the risk with another party, for example through contract terms with a supplier.
• Accept means living with what's left, called residual risk, as long as it's within your tolerance. Risk never reaches zero.
• Frameworks give you a method. ISO 31000 gives guidelines for risk management and defines risk as the effect of uncertainty on objectives, though you can't be certified against it. NIST SP 800-37 is the Risk Management Framework, built for security and privacy risk.
• ENISA's cloud risk assessment lists cloud-specific risks, such as loss of governance and isolation failure.
• And NIST CSF 2.0 uses Tiers, from Partial to Adaptive, to describe how rigorous your risk practice is.
• Metrics show whether treatments are working. Common ones include patching levels, time to deploy patches, intrusion attempts, and how long it takes to detect, contain and resolve incidents. A metric drifting outside its expected range can mean a control has stopped working.
• Finally, assess the risk environment around a provider. Could it be taken over? Is it financially stable? Where are its offices, and is it facing lawsuits? What pricing protection do you have, how will it meet your compliance needs, and how does it recover from failure?
• Designing that review is due diligence; carrying it out is due care.
• Here's our worked example: one row of Aldermoor's risk register. The risk: an outage in the provider's main region stops clinics booking appointments. Treatment: mitigate, by running a standby in a second region; transfer part of the cost, through business interruption cover, one type of cyber insurance; and accept the residual risk, which Nadia signs off. The metric: time to recover, reviewed every month.
• Our call: insurance alongside controls, not instead of them. Insurers are unlikely to cover an organisation without adequate controls, and they may require ones such as MFA. Transfer usually goes together with mitigation.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management; NIST Cybersecurity Framework 2.0

In this lesson

The MSA, SOW and SLA, the contract clauses that matter, and cyber risk insurance. Outline: 6.5.1 and 6.5.3. Not legal advice.

Key points

• Most of what you can demand from a provider lives in the contract. Three documents carry it, and we'll take them in order: the master service agreement, the statement of work, and the service level agreement.
• Legal counsel usually owns the wording, but security has to get its requirements in.
• The master service agreement is the overall contract between customer and provider. In our reading, it's the natural home for ongoing security terms, such as compliance duties passed to the provider, and how quickly it must tell you about a breach.
• A statement of work sits under the MSA and covers one piece of work, such as a migration project. That lets you set requirements that only apply to that job, like secure transport for drives during the move.
• The service level agreement sets measurable service levels, such as uptime, and what happens when they're missed, such as service credits or the right to leave.
• Do the maths: 99% uptime still allows about 87.6 hours of downtime a year.
• Monitor it, because documented misses can let you leave without a penalty.
• Then the clauses. The outline lists them, and these are the ones we'll focus on. Right to audit, which providers often meet with their standard reports. Definitions, so key terms like security, privacy and breach notice mean the same to everyone. Termination, and access to your data when you leave. Assurance, such as a yearly SOC 2. Compliance duties that flow down. And litigation terms, such as arbitration, which limit your options.
• Cyber risk insurance can also sit in the deal, for example requiring a provider to carry cover. Policies have limits and sublimits, and usually cover costs such as investigation, recovery, legal notifications and lawsuits.
• Our call: get counsel to review the arbitration term before signing, because it can limit how Aldermoor recovers damages.
• On audits, accept the provider's standard reports in place of a customer audit, as many contracts do, and write the yearly report into the assurance clause.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

Vendor assessments, lock-in, viability, escrow and supply chain risk. Outline: 6.5.2 and 6.5.4.

Key points

• Cloud turns vendor management into a continuous job, because you're outsourcing processes that run every day. The outline names four parts, and we'll take them in order: vendor assessments, lock-in, viability and escrow.
• Assess the vendor before you choose it, then keep assessing. For many customers, that means reading the provider's SOC 2 every year, after its annual audit.
• Lock-in comes from what you build on. Plain virtual servers move between providers fairly easily. A unique service, such as a provider's own AI platform, can tie a system to that provider, so leaving would mean rebuilding it.
• Viability asks whether the vendor will still be there. If a provider hosting critical systems goes bankrupt, you carry the damage. Check financial statements, track record and reputation.
• Escrow puts something with a trusted third party, to be released if needed. In IT, that's often source code or encryption keys. If a vendor that built custom software goes out of business, the escrow agent releases the code, so you can keep the system running.
• The supply chain goes deeper than your direct vendors. Weak security at a supplier can become your problem, and attackers have used vendors and software updates to reach their real targets.
• For guidance, ISO/IEC 27036 covers security in supplier relationships, and its part 4 deals with cloud services. NIST SP 800-161 covers supply chain risk management practices.
• Our call: it can be fine, but go in with eyes open. A unique service raises lock-in risk, so record it, keep the data exportable, and know what leaving would cost.
• Make sure the contract guarantees access to your data on exit.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); ISC2 CCSP Certification Exam Outline, effective 1 August 2026; NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management

What you're building

One workbook that pulls Domain 6 together for a cloud service: the laws in play, whether you need a data protection impact assessment, the breach clocks, the contract terms, the risk register and the vendor review. Compare your answers with Aldermoor's, then fill in the blank copy for a service of your own.

What each sheet records

• Laws in scope: each market, the data, the law, your role and your key duty, with a column for counsel to confirm. Laws differ between jurisdictions, so start from your own data.
• DPIA screen: the three examples in GDPR Article 35 where an assessment is required, plus a catch-all, because the list isn't exhaustive. Any Yes means the assessment comes before the processing starts.
• DPIA record: each step of the processing, the rule it triggers, the risk to people, the control and the owner. An assessment must describe the processing, assess necessity and risks, and set out measures.
• Breach clocks: who tells whom, by when, under each regime and contract. Under the GDPR a controller tells the authority without undue delay and, where feasible, within 72 hours, and a processor tells the controller without undue delay. Under HIPAA, notice comes without unreasonable delay and no later than 60 days after discovery.
• Contract checklist: the clauses to look for and which document carries them, the MSA, SOW or SLA. A row turns red while a clause is missing.
• Risk register: each risk, its treatment, the owner and the metric that shows whether the treatment works.
• Vendor review: the latest report, whether its scope covers the services you use, lock-in, viability and escrow. A row reads Hold while the scope or viability check reads No.

A note on Aldermoor's entries

Aldermoor is fictional. Its entries are our calls, and its names and terms are invented; the 24-hour notice and 30-day exit terms are our suggestions. This is not legal advice: every law in the first sheet waits for counsel to confirm it.

Sources

CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy); Regulation (EU) 2016/679 (General Data Protection Regulation); 45 CFR 164.402 to 164.410 (HIPAA Breach Notification), via Cornell LII

In this lesson

Pulling the course together into a one-page board report.

Key points

• Risk appetite is the broad amount of risk an organisation is willing to accept, and it's set by its most senior leaders. So, in our reading, a board report should show the risks to the business, what's being done about them, and any risk that needs the board's decision.
• Each risk above the appetite needs a decision: reduce it, transfer it, avoid it, or accept it. Risk limits are set by senior leadership. So in our reading, accepting a risk above the appetite is the board's call, not the security team's.
• Our call: the board. Security advises, but the appetite that risk acceptance must fit within is set by senior leadership. Next: how to sit the CCSP exam.

Sources

NIST IR 8286Ar1: Identifying and Estimating Cybersecurity Risk for Enterprise Risk Management; CCSP Common Body of Knowledge reference (ISC2 official textbook, licensed private copy)

In this lesson

The exam format, pacing, reading questions and using the practice exams.

Key points

• The exam lasts three hours, with between a hundred and a hundred and fifty items, and you need seven hundred out of a thousand to pass. It's adaptive, so each exam is tailored to how you're doing.
• Expect more than plain multiple choice. ISC2 says items can include drag and hotspot formats, calculations, order response and scenario-based questions.

Sources

ISC2 CCSP Certification Exam Outline, effective 1 August 2026; ISC2: CCSP Exam Going CAT; ISC2: before your exam (policies and procedures)