Overview
Domain 6 covers the legal and governance context of cloud computing. It starts with legal requirements and cloud-specific legal risks: conflicting international legislation, legal frameworks, eDiscovery and forensic requirements, with ISO/IEC standards for each. It covers privacy: the difference between contractually protected and regulated data, country-specific legislation, standard privacy requirements and privacy impact assessments. It covers audit in a cloud setting: internal and external controls, assurance challenges, types of audit report, scope restrictions, gap analysis, audit planning and specialized compliance regimes. It closes with enterprise risk management in the cloud, including data roles and transparency requirements, and outsourcing and contract design.
The domain matters because moving to the cloud moves operations but not accountability. Every control in Domains 2 to 5 is ultimately judged against the legal, regulatory and contractual obligations defined here.
How it's tested
Questions describe a legal demand, a privacy situation, an audit need or a contract negotiation and ask for the MOST appropriate report, the party responsible, or the FIRST step. Many hinge on one precise distinction, such as controller versus processor, Type I versus Type II, or regulated versus contractual data.
-
Choose the assurance
An assurance need is stated, and you must pick the report or evidence that fits its audience, scope and period.
-
Who is accountable?
A data handling or breach situation is described, and you must identify the controller, processor, owner or custodian and their duties.
-
Jurisdiction and contract
Data crosses borders or a provider relationship changes, and you must choose the legal step or contract clause that protects the customer.
A European retailer uses a US-headquartered cloud provider and stores all data in an EU region. It asks whether US authorities could still demand access. Storage location is not the only factor, because laws can reach providers based on where they are incorporated or controlled. The best answer involves assessing conflicting legal obligations, using contractual commitments on handling government requests, and protecting data with keys the customer controls.
Subdomains 5
Official subdomains from the ISC2 outline, in outline order.
6.1 Articulate legal requirements and unique risks within the cloud environmentConflicting laws, cloud legal risks, legal frameworks, eDiscovery and forensic requirements.
- What it means
- This covers how cloud services expose organizations to the laws of several jurisdictions at once, the legal risks that result, the frameworks and guidance that apply, eDiscovery (with references such as ISO/IEC 27050 and CSA guidance), and forensic requirements, with references such as ISO/IEC 27037, 27041, 27042 and 27043.
- What to understand
- Laws can conflict, for example one jurisdiction requiring disclosure while another prohibits transfer. eDiscovery in the cloud depends on knowing where data is and on the provider's ability to search, preserve and produce it. ISO/IEC 27037 covers identifying, collecting, acquiring and preserving digital evidence, while the others cover assuring methods, analysis and interpretation, and investigation processes.
- How it shows up
- Questions describe a legal request for cloud data or a cross-border conflict and ask for the BEST first step or the relevant standard.
- Common confusion
- Assuming the data's storage location alone decides which laws apply. Provider nationality, customer location and data subjects' location can all bring other laws into play.
6.2 Understand privacy issuesContractual vs. regulated data, country laws, jurisdictional differences, privacy standards and PIAs.
- What it means
- This covers telling regulated private data, such as PHI and PII protected by law, from data protected only by contract, knowing country-specific laws such as FERPA, PIPEDA, the GDPR, HIPAA and India's Digital Personal Data Protection Act, understanding jurisdictional differences, applying standards such as ISO/IEC 27018 and the Generally Accepted Privacy Principles (GAPP), and conducting privacy impact assessments (PIA).
- What to understand
- Regulated data carries legal obligations and penalties, while contractual data carries the obligations of the agreement. ISO/IEC 27018 addresses protection of PII in public clouds where the provider acts as a PII processor. A PIA should be completed before new processing begins, not afterwards.
- How it shows up
- Questions ask whether a data set is regulated or contractual, which standard fits a cloud provider processing PII, or when a PIA should be done.
- Common confusion
- Treating all sensitive data as regulated. Payment card data, for example, is protected mainly through contractual industry requirements rather than a single statute.
6.3 Understand audit process, methodologies, and required adaptations for a cloud environmentAudit controls, assurance challenges, report types, scope, gap analysis, planning, ISMS and regulated industries.
- What it means
- This covers internal and external audit controls, how audit requirements affect cloud use, assurance challenges of virtualization and cloud, report types such as SSAE-based SOC reports and ISAE 3402, restrictions in audit scope statements, gap analysis, audit planning, the internal ISMS and controls system, policies, stakeholder involvement, compliance regimes such as NERC CIP, HIPAA, HITECH and PCI, and the impact of distributed IT across jurisdictions.
- What to understand
- Customers usually cannot audit large providers directly, so they rely on third-party reports, and must read each report's scope, period and exclusions. SOC 1 covers controls relevant to financial reporting, SOC 2 covers security, availability, processing integrity, confidentiality and privacy for restricted users, and SOC 3 is a general-use summary. Type II reports test operating effectiveness over a period.
- How it shows up
- An assurance need is described, and you must pick the right report type, or identify what a scope exclusion means for the customer.
- Common confusion
- Choosing a SOC 3 for detailed assurance. It is a public summary without the detailed control descriptions and test results auditors need.
6.4 Understand implications of cloud to enterprise risk managementProvider risk programs, data roles, transparency requirements, risk treatment, frameworks, metrics and risk environment.
- What it means
- This covers assessing a provider's risk management program, distinguishing data roles (owner, controller, custodian, processor, steward), meeting regulatory transparency requirements such as breach notification, the GDPR and SOX, choosing risk treatments, using risk frameworks and metrics, and assessing the service, vendor, infrastructure and business risk environment.
- What to understand
- The controller decides the purposes and means of processing and stays accountable. The processor acts on the controller's instructions. Using a provider changes how risk is managed but does not remove the customer's accountability. Under the GDPR, a controller must notify the supervisory authority of a qualifying personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it.
- How it shows up
- A breach or data handling scenario is described, and you must identify the controller and processor, their duties, or the required notification.
- Common confusion
- Treating the cloud provider as the controller because it holds the data. In most customer workloads the customer is the controller and the provider is a processor.
6.5 Understand outsourcing and cloud contract designBusiness requirements, vendor management, contract management and supply chain management.
- What it means
- This covers business requirements documented in service-level agreements (SLA), master service agreements (MSA) and statements of work (SOW), vendor management including assessments, lock-in, viability and escrow, contract terms such as right to audit, metrics, definitions, termination, litigation, assurance, compliance, data access, cyber insurance, data ownership and security requirements, and supply chain management with references such as ISO/IEC 27036.
- What to understand
- The contract is the customer's main lever over a provider, so terms must be set before signing. Key protections include clear data ownership, data return and deletion at termination, breach notification duties, assurance rights and measurable SLAs with remedies. Escrow protects access to software or materials if a vendor fails.
- How it shows up
- A provider relationship is ending, failing or under negotiation, and you must choose the clause or vendor management step that protects the customer.
- Common confusion
- Assuming SLA credits compensate for real business losses. Credits are usually limited to a portion of fees, far below the cost of an outage.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Data controller vs. processor
The controller decides why and how personal data is processed. The processor processes it on the controller's behalf.
- Remember
- In typical cloud use, the customer is the controller and stays accountable.
- Tested as
- Breach and accountability questions.
- Trap
- Naming the provider as controller because it stores the data.
-
Data owner, custodian and steward
The owner is accountable for the data, the custodian handles and protects it day to day, and the steward manages its quality and proper use.
- Remember
- Ownership stays with the business.
- Tested as
- Data role questions.
- Trap
- Assigning ownership to IT.
-
SOC 1 vs. SOC 2 vs. SOC 3
SOC 1 covers controls relevant to financial reporting. SOC 2 covers security and related trust services criteria for restricted users. SOC 3 is a general-use summary.
- Remember
- Use SOC 2 for detailed security assurance.
- Tested as
- Report selection questions.
- Trap
- Choosing SOC 3 for detailed review.
-
Type I vs. Type II
Type I reports on control design at a point in time. Type II reports on operating effectiveness over a period.
- Remember
- Type II gives stronger assurance.
- Tested as
- Assurance strength questions.
- Trap
- Treating Type I as evidence of ongoing operation.
-
Regulated vs. contractual data
Regulated data is protected by law, such as PHI under HIPAA. Contractual data is protected by agreements, such as card data under PCI requirements.
- Remember
- The source of the obligation determines enforcement and penalties.
- Tested as
- Privacy classification questions.
- Trap
- Calling PCI DSS a law.
-
ISO/IEC 27018
A code of practice for protecting PII in public clouds where the provider acts as a PII processor.
- Remember
- It extends ISO/IEC 27001 and 27002 controls for cloud PII processing.
- Tested as
- Privacy standard questions.
- Trap
- Confusing it with ISO/IEC 27017, which covers cloud security controls generally.
-
GDPR breach notification
Controllers notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a qualifying breach.
- Remember
- Processors must notify the controller without undue delay.
- Tested as
- Transparency requirement questions.
- Trap
- Thinking the processor notifies the regulator on the controller's behalf by default.
-
eDiscovery
Identifying, preserving, collecting and producing electronic information for legal proceedings.
- Remember
- In the cloud it depends on knowing data location and on provider capabilities and contract terms.
- Tested as
- Legal request scenarios.
- Trap
- Assuming the provider will search and produce data without contractual provisions.
-
ISO/IEC 27037
Guidance on identifying, collecting, acquiring and preserving digital evidence.
- Remember
- It is the evidence-handling standard named in the forensics item.
- Tested as
- Forensic standard recognition.
- Trap
- Confusing it with 27050 for eDiscovery.
-
Escrow
A third party holds software or materials to be released if the vendor fails to meet defined conditions.
- Remember
- It addresses vendor viability risk.
- Tested as
- Vendor management questions.
- Trap
- Assuming it protects customer data held in SaaS.
-
Privacy impact assessment
An assessment of how a new system or process affects personal data and privacy.
- Remember
- It should be done before processing begins.
- Tested as
- Timing questions.
- Trap
- Doing it after launch.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
SOC 1 vs. SOC 2 vs. SOC 3
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SOC 1 | Controls at a service organization relevant to customers' financial reporting | Aimed at financial auditors | Using it for security assurance |
| SOC 2 | Controls relating to security, availability, processing integrity, confidentiality and privacy | Detailed, restricted-use report for informed users | Ignoring the difference between Type I and Type II |
| SOC 3 | General-use summary of a trust services examination | Public, with little detail | Relying on it for detailed control review |
Controller vs. processor vs. custodian
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Controller | Decides the purposes and means of processing personal data | Carries primary accountability and notification duties | Assigning the role to the provider by default |
| Processor | Processes personal data on the controller's instructions | Bound by contract and by its own legal duties | Assuming it carries no obligations |
| Custodian | Handles and protects data day to day | Operational responsibility, not ownership | Confusing custody with ownership |
SLA vs. MSA vs. SOW
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| SLA | Measurable service levels and remedies | Defines performance expectations and credits | Assuming credits cover real losses |
| MSA | Overarching legal terms for the relationship | Governs liability, confidentiality and general terms | Omitting security and data clauses |
| SOW | Specific work, deliverables and timelines | Describes a defined piece of work | Treating it as the main legal agreement |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Provider is the controller
- What candidates pick
- Hold the cloud provider primarily accountable for a breach of customer personal data.
- Why it looks right
- The provider stores and processes the data.
- Why it's wrong
- The customer usually decides why and how the data is processed, so it is the controller and carries primary accountability and notification duties.
Clue to watch for The data belongs to the customer's own customers or employees.
-
SOC 3 is enough
- What candidates pick
- Accept the provider's public SOC 3 for an auditor's detailed review.
- Why it looks right
- It is an independent report and easy to obtain.
- Why it's wrong
- SOC 3 is a summary for general use. Detailed review needs a SOC 2, preferably Type II.
Clue to watch for The need is detailed control design and testing results.
-
Region equals jurisdiction
- What candidates pick
- Store data in a local region to avoid foreign legal demands.
- Why it looks right
- Data residency is often presented as the answer.
- Why it's wrong
- Laws can reach providers based on their incorporation or control, regardless of where data sits.
Clue to watch for The provider is headquartered in another country.
-
SLA credits as protection
- What candidates pick
- Rely on SLA credits to compensate for business losses from outages.
- Why it looks right
- The SLA promises compensation.
- Why it's wrong
- Credits are usually a small share of fees. Resilience design, insurance and contract terms are needed for real protection.
Clue to watch for The scenario involves a critical service with major business impact.
-
Escrow protects SaaS data
- What candidates pick
- Use software escrow to guarantee access to data if a SaaS vendor fails.
- Why it looks right
- Escrow is designed for vendor failure.
- Why it's wrong
- Software escrow typically covers code or materials, not the customer's live data. Data return and portability clauses address that.
Clue to watch for The concern is getting your data back, not the vendor's code.
-
PIA after launch
- What candidates pick
- Conduct a privacy impact assessment once the new system is running.
- Why it looks right
- The real data flows are then known.
- Why it's wrong
- A PIA should be done before processing begins, so privacy risks can shape the design.
Clue to watch for A new system or new use of personal data is being planned.
Answer framework
Use these steps to reason through any Domain 6 legal, risk or contract scenario.
- Identify every jurisdiction involved, including where the data sits, where the provider is controlled, and where the data subjects are.
- Classify the data and its obligations, separating regulated data such as PHI and PII from data that is protected only by contract.
- Assign data roles, determining who is controller, processor, owner and custodian, and therefore who carries each legal duty.
- Match assurance needs to the right evidence, checking report type, Type I or Type II, scope, period and exclusions.
- Prefer answers that secure protections in the contract before signing, such as data ownership, return, audit rights, notification and termination terms.
Practice question
Want more like this? The CCSP practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Do not let the low weight lead you to skim this domain. Start with data roles in 6.4, because controller and processor questions recur across privacy, breach and contract scenarios. Then learn the SOC report family in 6.3 thoroughly, including report type, audience, Type I and Type II, and why scope exclusions matter.
Next, study privacy in 6.2: the regulated versus contractual distinction, the laws named in the outline, ISO/IEC 27018 and when a PIA happens. You need to know what each law broadly protects, not its articles.
Candidates commonly underestimate 6.1's standards list and 6.5's contract terms. Make a short table matching each ISO/IEC standard number to its purpose, and list the contract clauses that protect a customer at entry, during service and at exit.
Afterwards, revisit Domains 2 and 5 with this domain in mind. Retention, logging, forensics and incident communication there are all shaped by the legal obligations covered here, and mixed practice shows whether you can connect them.
FAQ
How much of the CCSP exam is Domain 6?
Legal, Risk and Compliance carries 13% under the outline effective 1 August 2026, the lowest weight of the six domains.
Do I need to be a lawyer to pass this domain?
No. You need to understand what major laws and standards are for, who carries which obligation, and how contracts and audits protect a cloud customer. Legal detail at article level is not the focus.
Is the cloud provider the data controller?
Usually not. For the customer's own data, the customer decides the purposes and means of processing and is the controller, while the provider acts as a processor.
Which SOC report should I ask a provider for?
For detailed security assurance, a SOC 2 Type II report, which tests operating effectiveness over a period. SOC 1 covers financial reporting controls, and SOC 3 is a public summary.
Does keeping data in one country protect it from foreign laws?
Not necessarily. Laws can reach providers based on where they are incorporated or controlled, so contracts, key control and legal assessment also matter.
Which privacy laws are named in the outline?
Examples include FERPA, PIPEDA, the GDPR, HIPAA and India's Digital Personal Data Protection Act, along with standards such as ISO/IEC 27018 and GAPP.
How does Domain 6 connect to the rest of the exam?
It defines the obligations that controls in every other domain must satisfy, from data retention and logging to forensics, incident communication and provider selection.
Other Cybersecurity certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- CompTIA SecurityX (CASP+) Same subject: Domain 1: Governance, Risk, and Compliance (20%)
- CompTIA Cybersecurity Analyst+ Study guide
- Microsoft Security Operations Analyst Associate Study guide
- Certified Ethical Hacker Study guide
- Penetration Tester Study guide
- Systems Security Certified Practitioner Study guide
- Certified in Risk and Information Systems Control Study guide
- CompTIA PenTest+ Study guide
- Azure Security Engineer Associate Study guide
- CISM (Certified Information Security Manager) Study guide
- CISSP Study guide
- CompTIA Security+ Study guide
- Certified Information Systems Auditor Study guide
Test your Domain 6 knowledge
You have covered conflicting laws, privacy, audit reports, data roles and cloud contracts. Test whether you can pick the right report, role and contract protection under exam conditions.