CCSP cheat sheet — every exam topic on one page

Cloud Concepts, Architecture and Design

CCSP Cloud Computing Concepts: Definitions, Roles, Characteristics and Building Blocks

• NIST SP 800-145 defines cloud as shared, configurable resources rapidly provisioned and released with minimal management effort or provider interaction; it sets out 5 characteristics, 3 service models and 4 deployment models.
• A private cloud with self-service and metering is cloud; a service where provider staff must act on each request is not.
• ISO/IEC 17788 adds multi-tenancy to NIST's five: tenants, their computations and data isolated and inaccessible to one another, including departments of one organisation.
• Resource pooling gives location independence: customers choose a country or region, not a host, so residency is met with in-country regions plus contract terms.
• Elasticity means releasing capacity as well as adding it; with measured service it turns a traffic flood into a bill (EDoS), which a scaling ceiling plus budget alerts bounds.
• Roles follow activity: a SaaS provider built on IaaS is a customer upstream and answers its own customers' assurance requests; auditors, developers and brokers are partner sub-roles, and one firm cannot independently audit controls it built.
• Brokers intermediate (enhance one service), aggregate (combine a fixed set) or arbitrage (choose flexibly among providers).
• The customer, as data owner, stays accountable; contracts, indemnities, insurance, brokers and SOC 2 reports shift responsibilities or money, not accountability, and regulators' binding rules override contract terms.
• VMs give each tenant its own kernel in a pooled service, containers share the host kernel; SDN overlays give tenants their own address spaces beyond the 4,094-VLAN limit; storage is decoupled from compute.
• Orchestration chains automated tasks into one workflow with no person in the loop, which is what delivers self-service and complete, usable elasticity.

CCSP Cloud Reference Architecture: Roles, Service Categories, Deployment Models and Shared Considerations

• ISO/IEC 17789 (now ISO/IEC 22123-3) places parties by activity, not employer: the integrator and business manager are customer sub-roles, the inter-cloud provider is a provider sub-role, and the developer, auditor and broker are partner sub-roles
• Capabilities types say what the customer can do (use the provider's apps, run its own code on provider runtimes, provision compute, storage and network); a service category can combine several types
• SaaS, PaaS and IaaS are recognised by the lowest layer the customer controls; control of the operating system is available only in IaaS
• Exclusive use decides the deployment model: a third-party-hosted cloud used by one organisation is private, and one shared by organisations with common concerns is community
• Hybrid means distinct infrastructures bound together for portability (for example bursting); multi-cloud means public cloud services from more than one provider, integrated and managed by the customer; one environment can be both
• Interoperability is exchanging and using information, portability is moving data and applications, and reversibility is retrieval plus provider deletion of customer and derived data, including backups, after an agreed period
• Availability, resiliency and performance each need their own metric; only tested failover proves resiliency, and an SLA is enforceable only when its metric, scope and measurement can be verified by the customer
• Service credits rebate part of the fee and do not cover business loss; outsourcing transfers work, never accountability
• When customer audits are refused, use independent attestations: SOC 2 Type II for detail, SOC 3 only as a summary; a carved-out subservice organisation needs its own assurance
• Confidential computing protects data in use with attested TEEs; quantum threatens public-key cryptography now through harvest-now-decrypt-later, while AES-256 keeps a margin; unpatchable IoT is contained by segmentation and a gateway; containers share a kernel; keep personal data off immutable ledgers

CCSP Cloud Security Concepts: Key Management, Access Control, Sanitization, Network and Virtualization Security

• Key custody decides who can decrypt: BYOK means you make the key and the provider uses it; an external key manager gives you a veto and revocation; only client-side encryption leaves the provider technically unable to decrypt, and holding keys yourself makes their availability your problem
• In envelope encryption the KEK wraps data keys; rotating the KEK re-wraps the DEKs or keeps old KEK versions for existing ones, and leaves the data untouched
• No standing privilege: just-in-time admin rights approved by someone else, limited to the task, with separate admin identities and break-glass accounts that alert on every use
• Workloads should hold no static secrets: use platform identities, short-lived credentials and mutual TLS rather than IP-based trust
• On shared cloud storage, sanitize with cryptographic erase; it needs tenant-specific keys and destruction of every key copy, including replicas and escrow
• Security groups filter address, port and protocol, never payloads; reference groups, not address ranges, to segment autoscaling tiers
• Flow logs show who talked; mirrored packets show what was said; pinned TLS cannot be intercepted, so exempt it narrowly
• Sign-in geofencing is bypassable by VPN; data residency needs policies that restrict where resources and backups are created
• Containers share the host kernel; untrusted multi-tenant code needs sandboxed runtimes or lightweight VMs, and dedicated hosts address VM-escape and side-channel co-residency risk
• Hygiene means a documented baseline checked continuously, customer patching of IaaS guests, time-bound exceptions with compensating controls, and immutable images that are replaced, not patched in place

CCSP Secure Cloud Design Principles: Data Lifecycle, BIA, BC/DR, Shared Responsibility and DevOps Security

• Classify at Create: every later lifecycle control reads the label; Use needs access control and monitoring (or confidential computing against the host), and Share uses DLP to decide whether data leaves and IRM to control it afterwards
• Plan Destroy at Store: data encrypted under customer-controlled keys can be crypto-shredded across every replica, and key versions must live as long as the data under them
• The BIA comes first: it identifies critical processes and sets the MTD, RTO and RPO that BC/DR strategies, purchases and contracts must meet
• The RTO must fit inside the MTD; the RPO picks the data mechanism and the RTO picks how warm the site must be; fix only the objective that fails, and never adjust the MTD to match the technology
• Control value = (ALE before - ALE after) - annual cost; ROI = (benefit - cost) / cost; choose the greatest net value, not the greatest risk reduction
• Zones survive a data center failure, regions survive a regional one, and only a second provider survives the provider; cross-provider recovery fails on proprietary dependencies, not data copies
• Parallel tests run real work at the recovery site while production continues; full interruption stops production; for SaaS, get the provider's DR evidence and tabletop your own response
• Portability moves things, interoperability makes them work together, reversibility gets you out cleanly; fight lock-in with open standards and abstraction, and lock-out with your own current exports
• Physical security is always the provider's; data, identities and access configuration are always the customer's, even when the provider chose a weak default
• A well-architected review is a self-assessment, not assurance; policy-as-code guards the pipeline, drift detection catches changes around it, and pipelines should use federated, short-lived, scoped credentials

CCSP: Evaluating Cloud Service Providers, Common Criteria and FIPS 140

• Criteria come first, from regulations, data classification and risk; certifications are evidence for criteria, never the criteria
• A mandatory criterion is pass/fail: extra certifications cannot offset it, and silent evidence does not relax it
• Every certificate covers only its scope: check the ISO/IEC 27001 scope statement and SoA exclusions, the AOC's listed services, the CC TOE and the FIPS module version
• Confirm status with the issuer or register; ISO/IEC 27001:2013 certificates ended on 31 October 2025, and a SOC 2 bridge letter is a management assertion
• CSA STAR Level 1 is a CAIQ self-assessment; Level 2 is third-party: Certification (ISO/IEC 27001 + CCM) or Attestation (SOC 2 + CCM)
• For card data, get the service provider AOC and responsibility matrix, and monitor the provider's status at least every 12 months
• A provider's certification covers only its own controls; CUECs and customer-configured controls need the customer's own evidence
• An EAL measures evaluation rigour, not security functions; compare functions in the Security Target
• A CC certificate applies only to the evaluated version, configuration and assumed environment; new versions need a maintenance report
• FIPS 140: Level 2 tamper evidence + role-based, Level 3 tamper response + identity-based; validation means a CMVP certificate for that version, used in approved mode

CCSP: AI and Machine Learning in Cloud Security, SOAR and AI Regulation

• Supervised learning needs labels and reproduces known classes; unsupervised anomaly detection needs none and finds novel behaviour as "unusual", not "malicious"
• UEBA scores deviation from a learned baseline: misuse already under way during the learning window becomes normal, and a changed environment needs a new baseline
• On rare-event data accuracy and specificity mislead; recall measures missed attacks, precision measures wasted alerts, and lowering the threshold raises recall and lowers precision
• Drift is gradual change after a sound start; non-representative training data fails from day one; validate any pre-trained model on your own labelled telemetry first
• Poisoning changes training data, evasion fools a deployed model, extraction copies it, inversion recovers data and membership inference tests a known record; differential privacy limits what outputs leak
• Verify datasets with a signature checked against a key from the originator, keep lineage from source to model, normalise timestamps to UTC and alert on silent source gaps
• SOAR adds orchestration, automation and response to the SIEM's alerts; automate enrichment and reversible steps, gate high-impact ones, give the platform least privilege and test playbooks outside production
• Historical bias survives removing a protected field through proxies; explaining one decision needs an interpretable model or a local explanation, because model-level information describes only average behaviour
• GDPR Article 22 covers solely automated decisions with legal or similarly significant effects and requires human intervention and contest under its contract and consent exceptions; a DPIA comes before high-risk profiling
• The EU AI Act tiers by use: workplace emotion inference is prohibited, recruitment screening is high-risk, chatbots carry transparency duties; ISO/IEC 42001 is the certifiable AI management system, the NIST AI RMF is guidance led by Govern

Cloud Data Security

CCSP Cloud Data Concepts: Data Lifecycle Phases, Data Dispersion and Data Flows

• The lifecycle is Create, Store, Use, Share, Archive, Destroy; Store comes before Use, and Share comes before Archive.
• Create covers generating new content and altering existing content (CCSP material adds acquired data): edited data starts in Create, where ownership and classification are set.
• Store happens almost with Create, so at-rest controls must already be in force when the first record is written.
• Use is viewing or processing without change; Share is making data accessible to others (other users, customers, partners), even inside your own tenant.
• Archived data must stay readable: preserve formats, software and keys for the whole retention period.
• Map controls to the path each data type actually takes, in every location it reaches; phases can be skipped and Archive can return to Use.
• Erasure coding gives resilience, not secrecy: encrypt, then disperse, and keep the key available independently of any one location.
• In a k-of-n design, n - k is the outage tolerance and k is what an attacker must collect; fewer than k fragments per provider keeps any one provider from rebuilding.
• Fragments are still your data: residency and transfer rules apply to every location holding one.
• Data flow diagrams show where data goes; keep them current through change review, mark trust boundaries wherever trust changes, and include support, logging, backup and replication flows with their locations.

CCSP Cloud Data Storage Architectures: Storage Types and Their Threats

• Volume, ephemeral and raw storage are block devices updated in place; object and archive storage store whole objects reached through an API.
• Ephemeral storage is, by default, lost with its instance, so it holds only disposable or regenerable data; uploads and databases need object or volume storage.
• A volume usually lives in one zone; recover from a zone failure by restoring a snapshot into another zone, and set the RPO by snapshot frequency.
• Snapshots of a running system are crash-consistent, and every snapshot restores the whole volume, including files deleted before it was taken.
• Raw (pass-through) LUNs depend on SAN zoning and LUN masking and fall outside hypervisor backups and VM disk encryption.
• Archive tiers trade slower retrieval (hours on many tiers) or higher retrieval charges, plus minimum storage durations, for low cost; retrieval time must fit the RTO.
• IaaS storage is volume and object, PaaS is structured and unstructured, SaaS is information storage and content/file storage; the customer always keeps data access decisions.
• Preventive exposure controls are an account-wide public-access block, short-lived signed links and an organisation policy that denies sharing snapshots outside it.
• Backups that must survive stolen top-level credentials need immutable, compliance-mode copies in a separate trust boundary; replication copies corruption, so keep point-in-time copies too.
• Provider-managed encryption at rest protects lost or stolen media, not data read through any authorised path.

CCSP Data Security Technologies: Encryption, Key Management, Hashing, Masking, Tokenization and DLP

• Each encryption control covers one data state; fix the state where the exposure is. Confidential computing protects data in use with existing code but trusts the hardware and attestation; homomorphic encryption trusts no hardware but is slow and needs redesigned computations
• Key control ladder: provider-managed, customer-managed, BYOK (imported; customer can revoke; provider services keep working), HYOK/external (keys never at the provider; customer infrastructure must stay online). Client-side encryption blinds native provider services
• Envelope encryption: DEKs encrypt data locally, a KEK in the key service wraps them; the master key never leaves the service and KEK rotation leaves bulk ciphertext untouched
• Validation belongs to a module, not an algorithm: evidence is a current CMVP certificate for the module in use, running in approved mode. Validation level and administrative control are separate questions; single-tenant cloud HSMs give the customer sole administration
• A digest proves integrity only if the attacker cannot replace it; store passwords with a per-user salt and a slow function such as Argon2id
• Hashes and HMACs give integrity, not non-repudiation; that needs a signature with a private key only the signer controls
• Static masking makes safe non-production copies; dynamic masking gives role-based views of live data without duplication; pseudonymized data is still personal data, and anonymization must deal with quasi-identifiers
• Tokenization removes token-only systems from PCI DSS scope; vaultless format-preserving encryption avoids a central lookup but makes the key the asset to protect
• DLP runs discovery, then monitoring, then enforcement, new rules in monitor-only mode first; network DLP is blind to TLS without inspection, and the channel and device decide between endpoint, inline proxy and API deployment
• Retrieve secrets at runtime with a workload identity, prefer short-lived per-service credentials, automate certificate renewal from a central inventory, and after key compromise rekey and revoke

CCSP: Cloud Data Discovery for Structured, Unstructured and Semi-Structured Data

• Discovery comes first: locate the data and learn what it contains, then classify, then protect.
• Label-based discovery misses unlabelled and mislabelled data; metadata-based discovery is misled by names; content-based discovery is accurate but costly, so layer the three.
• Structured data starts from the schema, but only inspecting (or sampling) stored values finds sensitive data in misnamed or free-text columns.
• Match the technique to the target: patterns for fixed formats, lexical analysis for topics, hashes for exact copies, OCR before anything on scanned images.
• Semi-structured data (JSON, XML, email) is parsed record by record, and a value's key path tells the scanner what to expect; validation such as the Luhn check cuts false positives.
• Tuning must not trade false positives for false negatives: use broad context and format validation, and treat a sharp drop in alerts as a reason to check for misses.
• Sampling suits triage; it cannot prove that rare sensitive objects are absent.
• Transparent at-rest encryption does not block an authorised scanner; client-side encrypted fields and password-protected files are uninspected, so their sensitivity is unknown.
• In SaaS, discovery runs through provider APIs and exports the contract grants, so settle that access during procurement. The customer stays responsible for knowing its data.
• Data location covers every copy, including backups, snapshots, exports and logs, and where data can be accessed from; encryption does not change where data is stored.

CCSP: Cloud Data Classification Policies, Data Mapping and Labeling

• Classify by the impact of compromise (confidentiality, integrity, availability), legal obligations and business value, never by storage location, format or usage.
• The data owner assigns and changes the level in every service model; custodians, providers, tools and users implement it.
• Use one organization-wide scheme scoped by data content, with a few clear levels, examples and a stated default for unclassified data.
• Handling requirements per level make classification actionable; when a service falls short, the owner accepts or rejects the risk, and the level is never lowered to fit a tool.
• Derived data starts at its most sensitive input's level (high-water mark); aggregation can raise it, and only an owner review can lower it.
• Reclassify when sensitivity changes (new sensitive fields, publication) as well as on schedule, and fix the label at its source rather than adding exceptions to controls.
• Map between schemes to the stricter level when there is no exact match, and map the classification field in every migration.
• Data maps record categories, systems, every location including backups and replicas, purposes and all applicable regulations.
• Resource tags stay with the container; embed labels in the data to follow copies, and label at the granularity where sensitivity differs.
• Enforce allowed tag values at creation, restrict who may change classification tags, and keep tag values content-free.

CCSP: Information Rights Management (IRM) in the Cloud

• IRM is the control that persists with the object: encryption plus a usage policy enforced by the opening client wherever the file goes.
• A copied or forwarded protected file stays useless to anyone the policy does not include, because each open needs a license from the rights service.
• Granular rights (view, edit, print, copy, save-as/export, forward, change rights) each govern one action; replication restrictions stop new unprotected copies, and their enforcement depends on the client.
• IRM cannot stop a photograph of the screen; watermarks deter and attribute, and audit logs show who opened what and when but cannot clear or convict a viewer.
• Dynamic policy control changes rights centrally after distribution; expiration needs no one to act and is enforced even offline; revocation waits until the client next checks with the service.
• The offline license period is the worst-case delay for revocation; short license validity speeds revocation at the cost of offline use.
• Provision rights to directory groups, deprovision by disabling the account, review group membership, and federate with partners' IdPs for changing external teams.
• Use non-overridable central templates tied to labels for content that must always carry the same rights, author-set rights for ad hoc sharing, and attribute conditions for device or location rules.
• Identity proofing before certificate issuance, per-device revocation, online revocation checks and HSM protection of the licensor key are the core certificate controls.
• BYOK gives lifecycle control while provider features keep working; only a customer-held second key makes the provider technically unable to open content, and it breaks search and previews.

CCSP: Data Retention, Deletion, Archiving and Legal Hold

• A retention schedule gives each record series a period, a trigger event, a disposition, a legal basis and an owner who reviews it periodically.
• Legal and regulatory obligations set minimum periods; the GDPR's storage limitation principle caps personal data at no longer than its purpose needs, and pseudonymized data stays in scope.
• Reconcile conflicts per record series: overlapping minimums keep the longest, and the Article 17(3)(b) legal-obligation exception keeps only the required records, for that purpose only.
• Enforce schedules with automated mechanisms in the service that holds the data, and make sure the mechanism counts from the policy's trigger event, not the upload date.
• Defensible deletion is authorized, routine, hold-checked and recorded in a disposal record.
• NIST SP 800-88: clear resists simple recovery, purge defeats laboratory recovery (cryptographic erase qualifies), destroy also makes the media unusable; SSDs need sanitize commands or destruction, never degaussing.
• Deletion covers every copy; immutable backups are kept beyond use and left to expire, and a provider's deletion is proven by a contractual deadline, backups in scope and a certificate of deletion.
• Archives need integrity hashes and restore tests, indexes, preserved metadata, separate request-based access and location commitments that cover every tier.
• The duty to preserve starts when litigation is reasonably anticipated; a hold is scoped to custodians, sources and period, and suspends deletion without restarting retention.
• Releasing a hold means removing it in every system and notifying custodians; expired records then become disposable unless another hold still covers them.

CCSP: Auditability of Data Events, Chain of Custody and Non-Repudiation

• Default provider audit logs record management-plane actions; object- and row-level data events usually need logging explicitly enabled.
• In IaaS the customer logs its own applications and databases; in PaaS it enables the service's built-in audit feature; in SaaS it depends on provider APIs and contract terms, secured before go-live.
• Only a unique identity creates accountability: retire shared accounts, and carry federated identities into shared role sessions.
• IP addresses show the connecting system (often a load balancer, NAT or VPN), and geolocation estimates the address's location, not the person's; correlate anomalies before acting.
• Synchronise clocks to a common source and record in UTC: one fixes drift, the other fixes daylight-saving ambiguity.
• Decide events and attributes from requirements first; log regulated stores completely rather than sampling; mask sensitive values and pseudonymise identities where privacy demands it.
• Store logs in a separate account with write-only delivery and immutability; only signed, hash-chained digests let a third party verify nothing was altered or removed.
• Set log retention per category from documented requirements; storage limitation bounds it, but a legal record-keeping duty sets a valid necessary period.
• Non-repudiation needs a digital signature with a key under the signer's sole control; hashes, HMACs and TLS do not provide it.
• A chain of custody records every holder, time, purpose and action, with hashes taken at collection; when the provider collects evidence, its steps and hashes start the chain.

CCSP AI and ML Data Set and Model Privacy and Security

• Embeddings, feature stores and model weights derived from sensitive data inherit at least that data's classification and access rules.
• Training a model on personal data is a new purpose: check compatibility, lawful basis and notice before any technical design. Pseudonymized data is still personal data.
• Minimize at the source, and redact identifiers inside free text; column removal, encryption and output filtering do not do that job.
• Federated learning keeps records local but updates can leak them; add secure aggregation and differential privacy. Lower epsilon means more noise, stronger privacy and usually lower accuracy.
• Models and synthetic data can memorize real people. Fix the training data, use output scanning only as an interim control, and test synthetic data for disclosure, not just fidelity.
• Deleting source records does not erase what a model learned; lineage from data set versions to model versions makes erasure deadlines achievable.
• For provider AI services, confirm use of prompts for training first, then retention and the location of retained data.
• Retrieval-augmented assistants must check each document's current permissions for the asking user at query time.
• Verification checks a model was built as specified; validation checks it is fit for purpose on independent, representative data. Calibration aligns confidence with observed correctness.
• Validate content before training, keep write-once snapshots referenced by ID and hash, sign models with a key only the approval step can use, load third-party models as untrusted code, and make the pipeline require a second person to approve promotion.

Cloud Platform & Infrastructure Security

CCSP Cloud Infrastructure and Platform Components Explained

• In public cloud the provider secures facilities, hosts and media under IaaS, PaaS and SaaS; customers rely on in-scope SOC 2 Type II and ISO/IEC 27001/27017 evidence, not site visits.
• A report's assurance stops at its scope; a bridge letter extends a SOC report in time, up to the present, never to extra systems or sites.
• BMCs bypass the hypervisor, so they belong on an isolated management network; measured boot with TPM attestation proves a host's boot chain to the scheduler, secure boot only enforces locally.
• The SDN controller and its APIs are a single point of failure and of compromise: cluster it, isolate it and authenticate both northbound and southbound interfaces.
• VXLAN's 24-bit identifier solves VLAN exhaustion, but overlays separate without encrypting or authenticating; add encryption in transit and restrict tunnel traffic to authorized endpoints.
• Management, migration, storage and tenant traffic each get their own network; on shared uplinks use a VLAN per type with QoS and access rules.
• Intra-host VM traffic never reaches physical sensors; inspect it with distributed firewalls or virtual-layer tools.
• Reservation = guaranteed floor (checked at power-on), limit = ceiling even when idle, shares = priority only under contention.
• Dedicated hosts remove other tenants, bare metal removes the provider hypervisor, confidential VMs protect data in use from the provider; nested virtualization keeps the provider hypervisor underneath.
• Maintenance mode evacuates workloads and refuses placements while the host stays monitored; blocking placements alone, snapshots or pausing still mean downtime at reboot, and hot patching cannot replace evacuation for reboot-requiring updates.
• The management plane is the widest-reaching target: protect it with privileged access workstations, MFA, network restrictions, named least-privilege accounts and full logging, and keep N+1 capacity so maintenance mode can evacuate hosts.

CCSP Secure Data Center Design: Tenant Partitioning, Location, HVAC, Connectivity and Resilience

• VLANs separate layer 2 but run out at 12 bits; VRFs give each tenant its own routing table (overlapping ranges, no NAT); VXLAN overlays give 24-bit segment IDs over IP but do not encrypt.
• Close VLAN hopping with access ports at the tenant edge and an unused native VLAN on trunks.
• Dedicated hosts isolate hardware while keeping cloud elasticity; controls that protect data on shared hardware do not meet a no-sharing requirement. On a SAN, zoning controls who reaches which ports and LUN masking controls which volumes a host sees.
• Put the management plane on an out-of-band network reached only through hardened jump hosts with MFA and session recording; make it physically independent if it must survive production failures.
• People who touch the hardware should not also log in to it: remote hands for physical tasks, remote console for logical ones.
• Site selection covers natural and man-made hazards and hazard independence between sites; close sites for synchronous replication plus a distant site for regional survival.
• Location decides which laws reach the data, the operator's home jurisdiction can reach it too, and residency covers every backup and every administrative access path.
• Build for control, colocate to own hardware without a building, use cloud for speed and elasticity; verify the controls that transfer with contracts and independent assurance.
• Fix airflow with hot/cold aisles, containment and blanking panels before adding cooling; too dry means static, too humid means condensation, so control dew point.
• Spare components protect capacity; independent paths remove single points of failure. Tier III is concurrently maintainable, Tier IV fault tolerant, and cooling needs ride-through and power-side diversity just like IT.

CCSP: Cloud Infrastructure Risk Assessment, Threats and Risk Treatment

• A risk needs an asset, a threat and a vulnerability: the threat acts, the vulnerability is the weakness it uses, and the harm is the impact.
• Use qualitative ratings when data is thin or the list is long; use quantitative analysis when you have loss data and a spending decision. Many teams rate qualitatively, then quantify the top risks.
• SLE = AV x EF; ALE = SLE x ARO; a safeguard is worth ALE before minus ALE after minus its annual cost. Convert every frequency to a yearly rate first.
• Inherent risk ignores all controls; residual risk counts every control, including the provider's. Re-rate residual risk when a control it depends on changes.
• The service model changes who treats a risk, not who is accountable. Keep provider-treated risks in the register and judge them from independent, in-scope, current assurance.
• VM escape is lowered only by a small, patched hypervisor; type 2 hypervisors have the larger attack surface. Side channels need co-residency, so dedicated hosts treat them.
• Management-plane credentials carry the highest impact: remove standing admin power with federation, MFA, just-in-time elevation, short-lived pipeline roles and a tightly controlled break-glass account.
• Misconfiguration needs continuous posture checks and deploy-time guardrails, plus drift detection for out-of-band changes; metadata-service SSRF is reduced in likelihood by hardening the metadata service and in impact by least-privilege roles.
• EDoS keeps the service up but drains money: filter at the edge, cap scaling and alert on spend.
• Insurance and SLA credits transfer cost, never accountability. Acceptance is a documented, dated decision by the risk owner; untreated is not accepted.

CCSP: Planning and Implementing Cloud Infrastructure Security Controls

• Whoever controls the space implements physical security: the provider in public cloud, the operator for shared colocation infrastructure, the tenant for its own cage, the customer for its premises and edge sites.
• An assurance report covers only its stated scope; where a location cannot be secured, protect the data itself with device-bound encryption.
• Pick physical controls by what they verify: vestibules count people, extra factors confirm the person, cameras and logs only record; doors allow free egress while entry stays controlled.
• Aspirating smoke detection warns earliest; pre-action sprinklers need detection before water flows; clean agents suit occupied electronics rooms that pass integrity testing, CO2 only unoccupied ones.
• NAT hides the source, a private endpoint privatises the path, and egress filtering or an endpoint policy decides the destination; management interfaces belong on an out-of-band network.
• Every encryption layer protects only the span between its endpoints; private circuits are not encrypted, and evidence of encryption comes from controls the customer operates.
• Zoning and LUN masking decide which hosts see storage; Kerberos authenticates NFS users; SMB signing and pre-authentication integrity protect integrity, SMB encryption protects confidentiality.
• Defend at the exhausted resource: volumetric floods at the provider edge, layer 7 floods with a WAF, economic denial of sustainability with per-client rate limits and quotas.
• Accountability needs individual identities; top-level root and management-account identities need phishing-resistant MFA and minimal use; vendors assume roles with a customer-unique external ID.
• Choose the audit source by the question; log every account and Region centrally into write-once storage with integrity digests, and correlate on synchronised time and a shared identity key.

CCSP: Business Continuity and Disaster Recovery Planning (RTO, RPO, RSL)

• Business continuity keeps critical functions running (people, processes, workarounds); disaster recovery restores the IT systems and data. In SaaS, the customer's own plan is mostly continuity.
• RTO is how fast service returns, RPO is how much data may be lost (measured backward), RSL is how much capacity must run in disaster mode. Copying more often moves RPO; restoring faster moves RTO; the standby's size sets RSL.
• Judge each objective at its worst case, find which one fails and why, and fund only the change that closes every gap; if nothing fails, nothing needs to change.
• Synchronous replication gives near-zero RPO at the cost of write latency over distance; split zone-level synchronous from region-level asynchronous protection and have the business accept the residual RPO.
• Replication copies corruption and ransomware, and a delayed replica only covers damage noticed within its delay; keep versioned point-in-time backups retained for the whole detection and restore range.
• Keep recovery copies outside the production blast radius and under retention nobody can lift (compliance mode) for longer than attacker dwell time.
• Keys, key custodians and quorum cards, identity and DNS are recovery dependencies; the critical path of dependent steps decides the achievable RTO.
• Reserve the recovery capacity the RSL needs; quotas and on-demand launch are not guarantees during a regional event, and active-active meets the RSL only if survivors absorb the lost load.
• Plan creation runs scope, requirements, analysis, risk assessment, design, implementation, test, report and revise; invocation needs pre-agreed criteria, a named authority and a decision deadline of RTO minus failover time.
• Tests use the normal recovery mechanisms and report achieved time, data loss and capacity against RTO, RPO and RSL; a missed objective goes to the business owner to fix and retest, never redefined. An SLA availability percentage is not an RTO.

Cloud Application Security

CCSP Application Security Awareness: Cloud Development Basics, Pitfalls and the OWASP, API, LLM and CWE Top Lists

• Except in SaaS, the security of the code you deploy is yours; PaaS moves only the operating system and runtime to the provider.
• Lift-and-shift moves the code, not the perimeter it relied on; components that authenticate nobody become exposed.
• A provider's certificate or SOC 2 report covers the provider, not the application you put on it.
• Build developer training from your own recurring findings, by role, and scale it with a security champion in every team.
• Top 10 lists raise awareness; ASVS is what you verify and contract against; no one is certified against the OWASP Top 10.
• ASVS level is a risk decision per application; most should strive for Level 2, the most sensitive for Level 3.
• In Top 10:2025, SSRF sits under Broken Access Control, open cloud storage and missing cookie flags under Security Misconfiguration, and failing open under Mishandling of Exceptional Conditions.
• API authorization: wrong object = BOLA, wrong field = BOPLA, wrong operation = BFLA; attacker wants the flow's result = API6, burns resources = API4.
• For LLM apps, assume prompt injection will succeed: limit agency, keep secrets out of the system prompt, treat output as untrusted, isolate tenants in vector stores and rate-limit inference.
• CWE names the kind of mistake, CVE a specific flaw; the CWE Top 25 ranks weaknesses by frequency times severity in real CVE data.

CCSP Secure SDLC: Business Requirements, Phases, Waterfall vs. Agile and DevSecOps

• Security starts at requirements: the later a flaw is found, the more it costs to fix.
• Define before you design, and assess before you contract; the data owner sets the classification that drives protection requirements.
• A security requirement is measurable and implementation-neutral; if it cannot be tested, it is a goal.
• A requirements traceability matrix links every requirement to design, code and test, including requirements added mid-project.
• Design review checks the architecture against requirements; peer review checks each change against the coding standard; tests come from requirements and cannot find what requirements omit.
• Every change re-enters the lifecycle, and new data or regulation triggers reassessment even with no code change.
• Disposal is planned: settle retention and legal hold first, then sanitize, then remove DNS records, credentials and keys.
• Waterfall handles late changes through formal change control; agile puts security in the definition of done and every sprint, never just a hardening sprint.
• Spiral is risk-driven per cycle; the V-model pairs each phase with a test level; DevSecOps automates checks in the pipeline and makes code owners fix their findings.
• SSDF groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, Respond to Vulnerabilities. Whoever writes the code runs its SDLC.

CCSP Applying the Secure SDLC: Cloud Risks, Threat Modeling and Secure Coding

• The provider isolates its infrastructure; in a shared schema, cache or queue, tenant separation is application code, enforced centrally from the authenticated tenant identity.
• Against CSP insiders, encrypt sensitive fields with keys held outside the provider; where the provider must have access, make it customer-approved, time-limited and logged to the customer.
• Platform, control-plane and database logs cannot name end users behind a shared service identity: the application must emit audit events to append-only storage.
• Residency covers every copy, including replicas, backups, logs, caches and indexes; compelled disclosure follows the provider, so customer-held keys are what make disclosed data unreadable.
• Threat model during design, update the model whenever architecture or data flows change, and start with flows that cross trust boundaries.
• STRIDE maps to properties: Spoofing-authentication, Tampering-integrity, Repudiation-non-repudiation, Information disclosure-confidentiality, Denial of service-availability, Elevation of privilege-authorization.
• DREAD ranks threats but is subjective (fix it with per-factor scoring criteria and calibration); PASTA is the seven-stage risk-centric process; ATASM is Architecture, Threats, Attack Surfaces, Mitigations.
• Fix injection by separating code from data (bound parameters, argument lists), including inside stored procedures; filters, WAFs and least privilege only compensate.
• SSRF defence validates the resolved address of every hop and requires tokens for metadata calls; a committed secret is compromised and must be rotated, moved to a secrets manager and scanned for.
• ASVS is a leveled, cumulative catalogue of testable requirements (Level 2 for most applications); SAFECode guides how to run secure development; CM means reviewed, versioned changes and pinned, tagged builds.

CCSP: Cloud Software Assurance and Security Testing (SAST, DAST, IAST, SCA)

• Functional tests check that a feature does what it should; non-functional tests check performance, scalability, resilience, usability and security under realistic conditions.
• Load testing proves capacity at the expected peak; failover testing proves continuity when a site or component is lost, and needs an environment that has more than one.
• Every fixed security flaw should become an automated regression test so a later change cannot silently reintroduce it.
• SAST reads code without running it (early, more false positives, blind to runtime config); DAST attacks the running app without code (needs a safe staging target and credentials); IAST watches from inside (precise, but only on paths tests exercise).
• SCA inventories every component including transitive dependencies, matches known vulnerabilities and flags licence obligations; retain the component list of each released build.
• Security gates should stop the build only for serious, high-confidence findings and track lower ones as work items; a gate that fails on everything gets bypassed.
• An unfixable finding goes through formal risk acceptance with a compensating control and an expiry, never a disabled gate or a false-positive label.
• Abuse cases invert use cases into what an actor must not be able to do, and each becomes a test.
• QA assures the process independently of developers; a release whose security requirements lack passing tests does not meet its criteria.
• Test only your side of the shared-responsibility line, under the provider's testing policy; rely on attestation for the hypervisor and SaaS internals, and use consistently masked or synthetic data in test.

CCSP Verified Secure Software: API Security, Software Supply Chain and Open Source

• Use scoped OAuth 2.0 tokens when an API acts for a user, mutual TLS for service-to-service authentication with no shared secret, and never put credentials in URLs; rotate any key that was logged.
• Authorization is a server-side entitlement check on every object, using values the server trusts (token claims, stored records); identifiers that are hard to guess are not authorization.
• Validate every request on the server against a per-endpoint allowlist of permitted fields; client-side checks do not stop direct calls, and type checks do not stop mass assignment.
• Key rate limits and quotas to the authenticated client, not the source IP, and return HTTP 429 when they are exceeded.
• TLS protects one connection; when intermediaries handle the message, use message-level signing or encryption (WS-Security for SOAP). Encryption gives confidentiality, a signature gives origin and integrity.
• Inventory every exposed API and version: discover shadow APIs first, then retire or patch deprecated versions.
• Assess suppliers before sharing data or signing, tier them by data access and criticality, and use ISO/IEC 27036 for supplier-relationship security.
• Hashes prove integrity against a reference, signatures add publisher authenticity, and only build provenance addresses a compromised build; an SBOM inventories components and VEX states which listed CVEs are exploitable.
• GPL obligations follow distribution; AGPL v3 also covers network use. Confirm that commercial licences permit cloud deployment before migrating.
• In IaaS the customer patches everything inside its instances, marketplace images included; plan for end of support and use source code escrow for vendor failure.

CCSP Cloud Application Architecture: WAF, Sandboxing and Kubernetes

• A WAF inspects HTTP request content and can virtually patch a known flaw, but it cannot enforce business authorization such as record ownership.
• Roll out WAF rules in detection-only mode on real traffic, tune out false positives, then block.
• DAM watches privileged database users independently of native auditing; network sensors miss local and encrypted sessions, host agents do not.
• XML firewalls validate schemas, cap entity expansion, reject DTDs to stop XXE and verify WS-Security signatures; gateway authentication does not make content safe.
• API gateways centralise authentication, throttling and per-credential quotas; services still authorize each request themselves.
• Whoever terminates TLS sees plaintext and validates client certificates: offload centralises keys, re-encryption keeps every hop encrypted, layer 4 pass-through keeps TLS end to end.
• To hide data from database administrators and the provider, encrypt the field in the application; search it with an HMAC blind index, never a plain hash.
• Sandboxes contain unknown flaws and observe untrusted files, but malware can detect or outwait them.
• Patch containers by rebuilding the image under a new tag or digest and rolling it out; daemon socket access and privileged mode are host root.
• Kubernetes defaults are open: disable unneeded token mounts, encrypt Secrets with an external KMS, enforce network policy with a supporting plugin, and use Pod Security Admission (warn and audit, then enforce).

CCSP Cloud IAM Design: Federation, SSO, MFA, CASB and Secrets Management

• The IdP authenticates and signs; the relying party verifies the signature with the IdP's signing certificate from metadata, and a multi-tenant app must bind each tenant to its own IdP's issuer and key.
• SAML and OpenID Connect are for sign-in; OAuth 2.0 is delegated authorization with scopes; SCIM provisions accounts.
• Public clients (mobile and single-page apps) use the authorization code flow with PKCE; the implicit and password grants are deprecated, and their refresh tokens must be rotated or sender-constrained.
• An ID token proves sign-in to the client (audience = client ID); an access token authorizes an API call, and every API must check audience and scopes, not just signature, issuer and expiry.
• Partner IdPs vouch for identity; your application keeps authorization by mapping partner claims to an allowlist and refreshing them at each sign-in.
• Release only the attributes each application needs, and use a pairwise identifier when an app must recognise users without correlating them across apps.
• SSO centralizes control and concentrates risk: protect the IdP with phishing-resistant MFA and few admins, and end live app sessions with revocation signals and single logout.
• MFA means two different categories; only origin-bound FIDO2 / passkeys resist real-time phishing proxies, and number matching stops push fatigue.
• CASB: forward proxy for any app from managed devices, reverse proxy for sanctioned apps from unmanaged devices, API mode for stored data and tenant settings, logs for discovery.
• No secrets in code, images or manifests: use workload identity to remove secret zero, read secrets at runtime, revoke a leaked key first, use per-tenant keys for crypto-shredding, rotate signing keys with overlapping key IDs, and use a private CA for internal names.

Cloud Security Operations

CCSP Building Secure Cloud Infrastructure: HSM, TPM, Secure Defaults, Virtual Hardware and Guest Tools

• HSM keys should be born inside the module as non-extractable and backed up only as wrapped blobs; whoever holds the wrapping key controls recovery.
• Tamper evident shows an intrusion afterwards; tamper responsive zeroizes keys during it, so keep another protected copy that one incident cannot reach.
• Keep in-scope keys on a module running solely in approved mode; serve non-approved legacy needs from a separate module holding nothing in scope.
• Applications authenticate to an HSM as crypto users; M-of-N quorum stops one crypto officer acting alone, and N minus expected absences must still reach M.
• A TPM measures boot into extend-only PCRs; sealing releases a key only on the measured state, so any approved firmware change needs a reseal.
• A vTPM's secrets live in the VM's encrypted files: the VM runs only where its key provider is reachable, and every clone copies the vTPM identity.
• Secure by default means protection is on out of the box: default deny, no default credentials before exposure, unneeded services off.
• Verify management tool installers by the vendor's signature, replace self-signed certificates, federate admins, vault a break-glass account and scope each service account.
• Forged transmits guards what a VM sends; MAC address changes and promiscuous mode guard what it receives. Scope exceptions to a dedicated port group.
• Encrypt above the layer you must keep out: guest-level encryption with customer-held keys hides data from the hypervisor, and data read through the hypervisor leaves decrypted.

CCSP Operating Cloud Infrastructure: Access, Hardening, Patching and Availability

• Route administrative access through one hardened bastion and replace standing access with approved, expiring just-in-time grants.
• Disable SSH password authentication in favour of keys, require RDP Network Level Authentication, and federate consoles and admin tools to one identity provider with SSO.
• VLAN IDs are 12 bits (4,094 usable); overlays such as VXLAN use a 24-bit identifier. DHCP snooping stops rogue DHCP servers; DNSSEC gives integrity and origin authentication, not confidentiality.
• Remove TLS 1.0 and 1.1 from what the server accepts; forward secrecy comes from ephemeral (EC)DHE key exchange, which every full TLS 1.3 handshake uses.
• Stateless network ACLs need explicit rules for return traffic to ephemeral ports; an IDS on a mirror only alerts, while an inline IPS can block.
• Check the provider's testing policy before any cloud vulnerability scan, and use authenticated scans to find missing patches and weak settings.
• Hardening is a cycle of baseline, drift monitoring and remediation, for hypervisor hosts as well as guests; immutable rebuilds prove every instance came from one approved build.
• Customers patch the guest OS only in IaaS; when a patch cannot go in yet, apply a vendor mitigation or compensating control and monitor.
• Maintenance mode is for planned work, HA restart for unplanned host failure, admission control guarantees restart capacity, dynamic optimization rebalances continuously, and anti-affinity keeps redundant VMs apart; only guest-level clustering survives guest crashes and guest patch reboots.
• Snapshots and replication are not backups; keep separate, immutable copies, back up host configuration and the management plane, and test restores.

CCSP Operational Controls and Standards: ITIL, ISO/IEC 20000-1 and Service Management

• ISO/IEC 20000-1 certifies a service management system and ISO/IEC 27001 an ISMS; ITIL is guidance, so organizations cannot be ITIL certified, and a certificate covers only its stated scope.
• COSO is for internal control over financial reporting, COBIT for governance of enterprise IT, CIS Controls IG1 for a prioritized starting set, NIST CSF 2.0 (with Govern) for program outcomes, and SP 800-53 baselines follow RMF categorization.
• Incidents restore service fast; problems remove causes. Priority is impact plus urgency, and a known error with a workaround stays open until a permanent solution is found.
• Standard changes are pre-authorized, normal changes are assessed by a change authority, and emergency changes get expedited authorization and later review; a proven repetitive normal change can become standard.
• Unrecorded changes are found by reconciling audit logs with change records; a security-weakening one is an incident first, while a known harmless fix is recorded as a retrospective emergency change.
• The CMDB's CI relationships drive change impact analysis; in elastic clouds keep it accurate with automated discovery, and compare running configuration to approved baselines.
• Deployment puts components into production; release makes features available, so with feature flags customer-use approval sits at the release decision.
• SLAs are with customers, OLAs with internal teams and underpinning contracts with external suppliers, and targets should measure the customer's end-to-end experience.
• Availability = MTBF / (MTBF + MTTR); multiply serial components, use 1 - product of unavailabilities for redundant ones; plan quotas and reservations ahead of known peaks.
• Security impact assessment and continuity impact (including recovery environments) belong inside change evaluation; improvements are proven only against a baseline outcome measure.

CCSP Cloud Digital Forensics: Evidence Collection, Preservation and Management

• Collect from most to least volatile (RFC 3227): memory and live state, temporary file systems, disk, then remote logs and archival media; an expiring log retention window is its own deadline.
• Stopping, rebooting or terminating a VM destroys memory, and stopping or terminating also wipes instance-local ephemeral disks, so capture both live with trusted tools from a clean volume and document the footprint.
• Contain without destroying: detach from auto-scaling and load balancing, then isolate the running workload with controls that also drop established sessions; pause containers rather than stopping them.
• IaaS disk evidence is a provider snapshot copied to a separate forensic account; use multi-volume crash-consistent snapshots for data that spans volumes.
• Integrity without a write blocker comes from untouched snapshots, block-device read-only handling and hashes compared with the value recorded at acquisition; encryption is confidentiality, not integrity.
• Forensic reach follows the service model: IaaS customers image memory and disks; PaaS, FaaS and SaaS evidence comes from provider logs, exports and features such as point-in-time restore.
• Multitenancy rules out host memory, physical disks and shared network captures; use guest memory, volume snapshots and virtual traffic mirroring instead.
• Provider-side evidence is secured by contract before an incident: contracted retention, preservation, tenant-scoped log extracts and investigative support; assurance reports are not case evidence.
• Store evidence in an isolated account with strict write-once retention, logged least-privilege access and keys controlled outside the compromised environment; give every item a unique inventory ID.
• Dispose of evidence only when counsel confirms retention duties and legal holds have ended, and settle the lawful transfer basis before personal data in evidence crosses a border.

CCSP Communication with Relevant Parties: Vendors, Customers, Partners and Regulators

• Settle who communicates, to whom, through which channel, how fast and with whose approval in a communication plan before any event, and update it whenever a system moves to a provider.
• Timeliness and control together: make approval always available (more than one empowered approver, wording agreed in advance) rather than removing sign-off.
• Tailor every message to its audience from one verified, approved fact base; the board hears business consequences, remaining risk versus appetite, and the choices it must make.
• Customer incident notices: early, verified facts, a next-update time, impact and actions; no exploit detail while the flaw is exploitable and never other tenants' names.
• Use the provider's contractual security and vulnerability-disclosure channels first, assess its notices through your own change process, and register function-based, monitored account contacts.
• Verify vendor or partner requests to change contacts or bank details using contact details already on record; SPF and DKIM authenticate a domain, not an organization.
• Under GDPR the processor tells the controller without undue delay (Art. 33(2)), in phases if needed; the controller notifies the authority and data subjects, and gets advance notice of sub-processor changes it can object to (Art. 28(2)).
• Outsourcing does not outsource accountability: the regulated customer answers its regulator through a designated liaison and engages it before signing a material outsourcing contract.
• Partner incident duties belong in an interconnection security agreement; TLP labels set onward sharing, and only the source can relax them.
• One spokesperson for the media, insurers told early under policy conditions, law-enforcement decisions taken with counsel and in writing, an out-of-band channel ready in advance, and a contemporaneous log of every notice.

CCSP Security Operations: SOC, SIEM, Incident Response and Testing

• A hybrid SOC gives round-the-clock coverage while keeping decisions and tuning in house; with any outsourced SOC, the contract must say how fast the provider escalates and what it may do without your approval.
• The customer's SOC monitors the layers the customer controls: guest OS and up in IaaS, application and platform logs in PaaS, tenant audit logs in SaaS.
• Threat hunting searches telemetry for compromise that triggered no alert; fix alert fatigue first by tuning or retiring the noisiest rules using triage outcomes.
• MTTD exposes attacker dwell time that fast containment figures hide; pair speed metrics with recurrence so closing tickets is not rewarded over eradication.
• SIEM correlates and alerts; SOAR runs playbooks across tools. Automate enrichment, and gate disruptive actions with analyst approval or guard checks.
• Anomaly detection finds unseen attacks at the cost of false positives; demote one misfiring IPS rule to detect-only rather than weakening the whole IPS. ML baselines learned during abnormal periods treat that activity as normal.
• Monitor the monitoring: notice feeds that stop reporting, find running hosts that nothing is watching, and catch firewall or security-group rules that differ from the approved code.
• Honeytokens give near-zero false-positive alerts; a high-interaction honeypot needs egress restriction so it cannot attack third parties.
• Keep the full record in cheap archive storage and feed the SIEM what its rules use; translate new feeds into the shared field model on arrival; give indicators a shelf life and lean on technique-based detections. STIX is content, TAXII is transport.
• Cloud IR succeeds in preparation (responder access, provider contacts, notification terms, central log forwarding); validate and scope before acting, contain without destroying evidence, and revert every control-plane change the intruder made.

Legal, Risk and Compliance

CCSP Cloud Legal Requirements and Risks: Conflicting Laws, eDiscovery and Forensics

• Cloud data can be subject to the laws of the storage country, the provider's home country, every subprocessor's country, the customer's country and the data subjects' countries at once; region choice is residency, not sovereignty.
• The CLOUD Act reaches data in a US provider's possession, custody or control wherever it is stored; providers can move to quash or modify on comity grounds, and executive-agreement partners can serve qualifying orders directly on US providers.
• GDPR Article 48 recognises foreign orders for EU personal data only when based on an international agreement such as an MLAT; civil evidence across borders runs through the Hague Evidence Convention, which blocking statutes point to.
• If any provider-operated service can use the key (provider-managed, customer-managed or imported key material), the provider can be compelled to decrypt; only keys held outside the provider leave it with ciphertext.
• Notice-of-demand clauses fail under gag orders; redirect-and-challenge commitments keep the customer able to respond.
• Seizure of shared hardware is an availability risk treated with recovery outside the order's reach; subprocessor risk starts with the subprocessor list and locations; export control follows the person who can see the data.
• Criminal cases are brought by the state and need proof beyond reasonable doubt; civil contract and tort claims need a balance of probabilities; Budapest is cybercrime cooperation, Wassenaar is dual-use export control.
• eDiscovery duties follow control: the customer must preserve and produce ESI it can obtain from a provider, from the moment litigation is reasonably anticipated; collect natively with metadata and hashes, proportionately.
• ISO/IEC 27050 is eDiscovery (1 concepts, 2 governance, 3 code of practice, 4 technical readiness); ISO/IEC 27037 is first response; 27041 method assurance; 27042 analysis; 27043 the overall investigation process; 27035 incident management.
• In SaaS the provider holds the internal evidence, so forensic readiness means contract terms on which logs are kept, for how long and how they are delivered.

CCSP Privacy Issues: GDPR, HIPAA, PIPEDA, ISO/IEC 27018, GAPP and PIAs

• Regulated data (PII, PHI) carries statutory duties no contract can waive; contractual data (PCI DSS card data) is binding through agreements and enforced by the acquirer and card brands, not the PCI Council
• PHI depends on the holder as well as the content: covered entity or business associate only; employer-held staff records and Safe Harbor de-identified data are not PHI
• A cloud provider that stores ePHI is a business associate needing a BAA even with customer-held keys; the conduit exception covers transmission only
• Under PIPEDA the organisation stays accountable for data a processor handles abroad: comparable protection by contract plus transparency, but no separate consent, approval or localisation
• Obligations follow the organisation's establishment and the individuals' location; moving data to another region adds laws rather than removing them
• GDPR Article 3 reaches non-EU organisations that target or monitor people in the EU (location, not citizenship), usually requiring an Article 27 representative
• Transfers: adequacy (for the US, only DPF-certified organisations within their certified scope), SCCs with a transfer assessment, BCRs for intra-group, Article 49 derogations only for occasional cases
• Pseudonymised data is still personal data; minimise to what the purpose needs and keep identifiable data no longer than necessary
• ISO/IEC 27018 processors need express, unbundled consent for advertising use, notify customers of disclosure requests as the contract specifies, and disclose subcontractors and countries before use
• A PIA assesses risk to individuals, starts at design, is revisited on change, and under the GDPR a high-risk DPIA with unmitigated residual risk requires prior consultation before processing

CCSP Cloud Audit: SOC 1, 2 and 3 Reports, SSAE, ISAE, Gap Analysis and Audit Planning

• Internal audit must be independent of what it audits and report functionally to the audit committee; only an auditor independent of the whole organisation gives assurance outsiders can rely on
• A provider's report covers the provider's controls for its scope and period; the customer still needs its own evidence, including logs it retains for its own obligations
• Ephemeral and API-driven resources are audited through images, pipelines, retained logs and continuous control monitoring, not point-in-time samples
• SOC 1 = controls relevant to financial reporting; SOC 2 = Trust Services Criteria with test detail, restricted use; SOC 3 = general-use summary without test detail
• Type 1 = design as of a date; Type 2 = operating effectiveness over a period; security is always in a SOC 2, other criteria only if put in scope
• SOC 1 runs under SSAE 18 AT-C 320 and ISAE 3402 is its international twin; SOC 2 runs under AT-C 205 and ISAE 3000 (Revised) covers non-financial assurance internationally
• A carve-out report did not test the subservice provider, so get that provider's own report; SOC 1 and SOC 2 reports cannot be passed on to your own customers
• Gap analysis measures current state against a baseline; RCSA is cheap and frequent but not independent assurance
• Audit planning runs objectives, scope, conduct, lessons learned; scope follows the objective and reaches business owners, procurement, providers and local counsel
• An ISO/IEC 27001 certificate attests a management system, not a specific control; regulated entities (NERC CIP, HIPAA covered entities) stay accountable when they use a provider

CCSP Enterprise Risk Management in the Cloud: Data Roles, Risk Treatment and Frameworks

• A provider can operate controls and pay for losses, but accountability for the customer's risk and data never moves to it.
• A provider's methodology is how it finds and rates risk, its risk profile is what risk it carries now, and its appetite is how much risk its leadership will take.
• When the provider's appetite exceeds yours, the gap is yours to close with your own controls, contract terms or a different service, applied only where the gap exists.
• Without customer audits, map STAR Level 2, SOC 2 Type II and ISO/IEC 27001 evidence to your requirements; check a certificate's scope first and treat STAR Level 1 answers as claims.
• The data owner approves access and classification; the custodian implements it; the steward manages meaning and quality; a contract does not hand the owner's decisions to the provider.
• Under the GDPR, the processor tells the controller without undue delay, the controller has 72 hours from its own awareness to notify the authority, and every breach is documented even when encryption makes notification unnecessary.
• For SOX, management keeps the ICFR assessment: it uses the provider's SOC 1 Type 2 and must also operate the complementary user entity controls.
• Sharing shifts part of a risk's consequence and transfer shifts all of it; neither lowers likelihood or moves accountability, and SLA credits transfer almost nothing.
• ISO 31000 is generic ERM, ISO/IEC 27005 serves an ISMS, NIST SP 800-37 authorises systems, SP 800-30 conducts assessments and ENISA catalogues cloud-specific risks.
• A good KRI measures exposure against a threshold and is escalated on its trend, before the threshold is breached.

CCSP Outsourcing and Cloud Contract Design: SLA, MSA, SOW, Escrow and ISO/IEC 27036

• The MSA holds the standing legal terms, each SOW defines one engagement, and the SLA sets measurable service levels and remedies; an order-of-precedence clause settles conflicts between them.
• Online documents incorporated by reference should be frozen as they stood at execution, or the provider can lower its commitments mid-term.
• Agree what key terms such as 'incident' and 'response' mean before negotiating the deadlines or penalties that depend on them.
• Assess the vendor against the data's sensitivity before contracting, tier vendors by risk, and read an attestation's opinion, scope and carve-outs.
• Data export in open formats reduces lock-in for data, but proprietary services still have to be rebuilt; viability needs financial review, change-of-control rights and an exit plan.
• Escrow works only with current, verified deposits and a customer able to run the software; otherwise continuity rests on portable data and a rehearsed switch of provider.
• Hyperscale providers give assurance through attestations; regulated customers negotiate access rights exercised through pooled audits, and incident-triggered audit rights give timely evidence.
• Exit terms need transition assistance, data access during disputes, and certified deletion of all copies including backups.
• Define customer data to include logs and metadata, and limit the provider's use of it to delivering the service.
• A data-breach super-cap is needed for breach costs, and any insurance the provider must carry should be liability cover evidenced throughout the term; check that your own policy responds to provider incidents.