Home / Blog / CIPM Domain 6 Guide
Domain 6 • 12-18% of Exam

CIPM Domain 6: Responding to Requests and Incidents

📅 Updated January 15, 2025 ⏱️ 19 minute read 🎯 Domain Specific 📚 Study Guide

🎯 Domain 6 Overview

What This Domain Tests: Your ability to handle data subject rights requests (DSARs), respond to privacy complaints, manage privacy and security incidents, conduct breach assessments, notify regulators and individuals appropriately, and implement post-incident improvements. This domain is where privacy program preparation meets operational reality.

Weight: 12-18% of the CIPM exam (approximately 11-16 questions)

Key Focus: Operational response management—handling the day-to-day requests and crisis situations that test whether your privacy program actually works. Domain 6 is about execution under pressure and legal timelines.

Why Domain 6 Is Critical

All the planning, governance, and controls from Domains 1-5 are tested in Domain 6. When an individual exercises their rights or when a breach occurs, you must respond quickly, correctly, and in compliance with strict legal requirements. Mistakes here have immediate, tangible consequences: regulatory fines, lawsuits, reputation damage, and lost customer trust.

Domain 6 is unique because it's the most time-sensitive and legally prescriptive domain. GDPR's 72-hour breach notification requirement and 30-day DSAR response deadline don't care about your internal processes or resource constraints. You must have efficient, well-practiced workflows ready to execute when needed.

What Makes Domain 6 Challenging

  • Strict Timelines: Legal deadlines are non-negotiable (72 hours, 30 days, etc.)
  • Complex Rights: Multiple overlapping rights with different requirements and exceptions
  • Multi-Jurisdictional: Rights and breach notification rules vary significantly across regulations
  • Identity Verification: Balancing security with access, preventing fraud
  • Incident Severity Assessment: Determining if breach meets notification thresholds
  • Cross-Functional Coordination: Incident response requires IT, legal, comms, leadership alignment

Core Topics in Domain 6

1. Data Subject Rights Overview

Privacy regulations grant individuals various rights over their personal data. Rights differ by jurisdiction, but many follow GDPR's framework.

Right of Access (GDPR Article 15)

What it means: Individuals can request confirmation that you're processing their data and obtain a copy of that data.

What you must provide:

  • Copy of personal data being processed
  • Purposes of processing
  • Categories of data
  • Recipients or categories of recipients
  • Retention period or criteria for determining period
  • Source of data (if not collected from individual)
  • Information about automated decision-making

Timeline: 1 month (extendable to 3 months for complex requests)

Right to Rectification (GDPR Article 16)

What it means: Individuals can request correction of inaccurate personal data.

What you must do:

  • Correct inaccurate data without undue delay
  • Complete incomplete data (if relevant to processing purpose)
  • Notify recipients of corrections unless impossible or disproportionate effort

Timeline: 1 month

Right to Erasure / "Right to be Forgotten" (GDPR Article 17)

What it means: Individuals can request deletion of their personal data under specific circumstances.

Grounds for erasure:

  • Data no longer necessary for original purpose
  • Consent withdrawn and no other legal basis exists
  • Individual objects and no overriding legitimate grounds
  • Data processed unlawfully
  • Legal obligation requires erasure
  • Data collected from children for information society services

Exceptions (when you can refuse):

  • Exercise of freedom of expression/information
  • Compliance with legal obligation
  • Public health purposes
  • Archiving in public interest, research, or statistics
  • Establishment, exercise, or defense of legal claims

Right to Restriction of Processing (GDPR Article 18)

What it means: Individuals can request you limit processing to storage only (no active use).

When this applies:

  • Data accuracy is contested (restrict while verifying)
  • Processing is unlawful but individual opposes erasure
  • Data no longer needed but individual needs it for legal claims
  • Individual has objected (restrict pending verification of grounds)

During restriction: You can store data but not process it (except with consent or for legal claims)

Right to Data Portability (GDPR Article 20)

What it means: Individuals can receive their data in machine-readable format and transmit it to another controller.

When this applies:

  • Processing is based on consent or contract
  • Processing is carried out by automated means

Format requirements:

  • Structured, commonly used, machine-readable format (CSV, JSON, XML)
  • Where technically feasible, transmit directly to another controller

Right to Object (GDPR Article 21)

What it means: Individuals can object to processing in certain situations.

Direct Marketing: Absolute right to object—must stop immediately

Legitimate Interest Processing: Must cease unless you demonstrate compelling legitimate grounds that override individual's interests

Public Interest/Official Authority: Must cease unless compelling legitimate grounds

Research/Statistics: Must cease unless processing necessary for public interest task

Rights Related to Automated Decision-Making (GDPR Article 22)

What it means: Individuals generally have the right not to be subject to solely automated decisions with legal or significant effects.

When automated decisions are allowed:

  • Necessary for contract performance
  • Authorized by law with appropriate safeguards
  • Based on explicit consent

Required safeguards: Right to human intervention, express view, and contest decision

2. CCPA/CPRA Rights Comparison

California privacy laws grant similar but distinct rights. Understanding differences is important for the exam.

Right CCPA/CPRA Requirement Key Differences from GDPR
Right to Know Access to categories and specific pieces of personal information collected, sold, or disclosed Similar to access right but explicitly includes "sold or shared" category
Right to Delete Request deletion of personal information Similar to erasure but different exceptions (business/legal purpose)
Right to Opt-Out of Sale/Sharing Stop sale or sharing of personal information for cross-context behavioral advertising No GDPR equivalent; uniquely addresses data monetization
Right to Correct Request correction of inaccurate information (CPRA) Similar to rectification, added in CPRA (2023)
Right to Limit Use of Sensitive Personal Information Restrict use and disclosure of sensitive personal information (CPRA) GDPR has special category data rules but not this specific right
Response Timeline 45 days (extendable to 90 days) GDPR: 30 days (extendable to 90 days total)

3. DSAR Processing Workflow

A systematic process ensures consistent, compliant handling of data subject requests.

Complete DSAR Handling Process

1Receive and Log Request
  • Accept requests through any channel (email, web form, phone, mail)
  • Log in request management system with unique ID
  • Record receipt date (starts timeline clock)
  • Acknowledge receipt within 1-3 business days
  • Clarify request type if ambiguous
2Verify Identity
  • Use reasonable means to confirm requester is who they claim to be
  • Match identifying information to your records (email, account details, etc.)
  • For high-risk requests (deletion, sensitive data), use stronger verification
  • Don't request more information than necessary for verification
  • If cannot verify: Refuse request and explain why
3Assess Validity and Scope
  • Confirm request is valid (proper identity, clear ask)
  • Determine which specific rights are being exercised
  • Identify applicable regulations (GDPR, CCPA, etc.)
  • Clarify scope if request is overly broad or unclear
  • Check if any exemptions apply
4Search and Collect Data
  • Search all systems where personal data may reside
  • Include: Production databases, backups, archives, logs, emails, documents
  • Use data inventory (Domain 3) to ensure comprehensive search
  • Document search process and systems checked
  • For deletion requests: Identify all data instances to be deleted
5Review and Redact
  • Review data for third-party personal information
  • Redact others' personal data that's not relevant to request
  • Remove privileged or confidential business information if applicable
  • Check for exemptions (e.g., legal privilege, trade secrets)
  • Ensure data provided is understandable (add context if needed)
6Prepare Response
  • For Access Requests: Compile data in accessible format (PDF, spreadsheet, etc.)
  • For Deletion Requests: Execute deletion across all systems, document completion
  • For Rectification: Correct data, notify relevant recipients
  • For Objection: Stop processing or explain compelling grounds to continue
  • Include all required information (purpose of processing, retention period, etc.)
7Deliver Response
  • Respond within legal deadline (30 days GDPR, 45 days CCPA)
  • Use secure delivery method (encrypted email, secure portal)
  • Confirm delivery to correct individual
  • If extending deadline: Notify individual within original deadline period
  • If refusing: Explain reason, cite exemption, inform of complaint rights
8Document and Close
  • Document entire process: request, verification, search, response
  • Maintain records for regulatory inquiries
  • Close request in tracking system
  • Update metrics (response time, type, outcome)
  • Identify any process improvements needed
⚠️ Common DSAR Mistakes:
  • Missing Backups: Forgetting to search backup systems and archives
  • Incomplete Deletion: Deleting from production but leaving in backups indefinitely
  • Over-Verification: Requesting excessive information that creates barriers
  • Missing Deadlines: Not tracking timelines carefully or extending without notice
  • Exposing Third-Party Data: Failing to redact others' personal information
  • Poor Documentation: Not maintaining records of DSAR processing

4. Identity Verification for DSARs

Balancing access rights with security is one of the biggest challenges in DSAR processing.

Identity Verification Principles

Risk-Based Approach:

  • Low Risk (Access to Public Information): Minimal verification (email confirmation)
  • Moderate Risk (Access to Personal Data): Standard verification (match identifying details)
  • High Risk (Deletion, Sensitive Data, Children): Enhanced verification (multiple factors, ID documents)

Acceptable Verification Methods:

  • Matching request details to existing account information
  • Sending verification link to registered email
  • Account login with existing credentials
  • Answering security questions
  • Providing government-issued ID (for high-risk requests)
  • Comparing signature to records on file

What Not to Do:

  • Request information you don't already have (creates new data collection)
  • Set verification bar so high it effectively denies access
  • Apply same verification to all request types regardless of risk
  • Retain verification documents longer than necessary
💡 Third-Party Requests: Individuals can authorize representatives (lawyers, family members, etc.) to make requests on their behalf. Verify both the representative's identity and their authority to act for the individual. Require written authorization unless individual is a child or lacks capacity.

5. Privacy Incident Detection and Classification

Not every security event is a reportable privacy breach. Understanding classifications is crucial.

Incident Classification Levels

Security Event (No Personal Data Impact):

  • Attempted unauthorized access that failed
  • System vulnerability identified before exploitation
  • Phishing attempt with no credential compromise
  • Action: Document, remediate vulnerability, no regulatory notification

Privacy Incident (Limited Impact):

  • Unauthorized access to small amount of low-risk data
  • Minimal likelihood of harm to individuals
  • Data already publicly available or non-sensitive
  • Action: Document, investigate, internal notification, likely no regulatory notification

Privacy Breach (Moderate Impact):

  • Unauthorized access to moderate amount of personal data
  • Some risk of harm but not severe
  • Data not highly sensitive but still personal
  • Action: Full investigation, likely regulatory notification (especially under GDPR), possible individual notification

Major Data Breach (High Impact):

  • Large-scale unauthorized access, theft, or exposure
  • Sensitive data involved (financial, health, credentials)
  • High likelihood of significant harm to individuals
  • Action: Immediate containment, regulatory notification (within 72 hours under GDPR), individual notification, public disclosure, executive involvement, possible legal counsel

6. Breach Response Process

Effective breach response requires pre-planned processes executed under time pressure. (Note: This was covered in Domain 2 governance; Domain 6 emphasizes operational execution.)

Breach Response Timeline

0h
Detection and Initial Response

Immediate Actions (Hours 0-4):

  • Confirm incident is real (not false alarm)
  • Activate incident response team
  • Begin containment to stop ongoing data exposure
  • Preserve evidence for investigation
  • Start incident documentation
24h
Initial Assessment

First 24 Hours:

  • Scope the breach: What data? How many individuals? How exposed?
  • Assess severity and likelihood of harm
  • Determine if notification thresholds are met
  • Brief executive leadership
  • Begin preparing notification content (if needed)
72h
Regulatory Notification (GDPR)

Within 72 Hours of Awareness:

  • Notify supervisory authority if breach presents risk to rights/freedoms
  • Provide: Nature of breach, categories of data/subjects, likely consequences, measures taken/proposed
  • If information not yet available: Provide in phases, explain delay
  • Document notification and response
30d
Individual Notification (If Required)

Timeline Varies by Jurisdiction:

  • GDPR: "Without undue delay" if high risk
  • US State Laws: Vary (some "without unreasonable delay," others specify days)
  • Notify affected individuals in clear, plain language
  • Explain what happened, what data involved, what they should do
  • Provide contact information for questions
90d
Remediation and Review

Post-Incident Activities:

  • Complete root cause analysis
  • Implement technical and organizational fixes
  • Conduct lessons learned review
  • Update incident response plan based on experience
  • Train staff on identified gaps
⚠️ Critical: The 72-Hour Clock Starts When You Become "Aware"

Under GDPR, the 72-hour notification clock starts not when the breach occurred, but when you become aware of it. "Awareness" means when you have reasonable certainty a breach involving personal data has occurred. Don't delay investigation hoping to push the clock—awareness is determined objectively, and regulators will scrutinize when you should have known.

7. Breach Notification Content Requirements

What you communicate matters as much as when you communicate it.

Regulatory Notification (To Supervisory Authority)

Required Elements Under GDPR Article 33:

  1. Nature of the breach: What happened? (unauthorized access, loss, destruction, etc.)
  2. Categories and approximate numbers:
    • Categories of data subjects affected
    • Approximate number of individuals affected
    • Categories of personal data records
    • Approximate number of records
  3. Contact details: Name and contact information of DPO or other contact point
  4. Likely consequences: Possible harm to individuals from the breach
  5. Measures taken or proposed:
    • Actions taken to address breach
    • Steps to mitigate possible adverse effects

Individual Notification (To Affected Persons)

Required When: Breach likely to result in high risk to rights and freedoms

Required Elements Under GDPR Article 34:

  • Clear and plain language: Avoid technical jargon
  • Nature of the breach: What happened in understandable terms
  • Contact information: DPO or contact point for questions
  • Likely consequences: What harm might result
  • Measures taken: What organization did to address breach
  • Recommended actions: What individuals should do to protect themselves (change passwords, monitor accounts, etc.)

Exceptions (When Individual Notification Not Required):

  • Appropriate technical protections were applied (e.g., encryption rendered data unintelligible)
  • Subsequent measures taken ensure high risk no longer likely
  • Would require disproportionate effort (then public communication required instead)

8. Complaint Handling

Privacy complaints must be addressed systematically, whether from individuals or regulatory authorities.

Complaint Management Process

Types of Complaints:

  • Direct to Organization: Individual contacts you with privacy concern
  • To Supervisory Authority: Individual files complaint with DPA, who investigates
  • Public Complaints: Social media, news outlets, consumer advocates

Handling Process:

  1. Acknowledge: Confirm receipt within 1-3 business days
  2. Investigate: Gather facts, review relevant systems and processes
  3. Assess: Determine if complaint is valid, identify root cause
  4. Resolve: Take corrective action if complaint justified
  5. Respond: Explain findings and actions taken (or why complaint was unfounded)
  6. Document: Maintain records of complaint and resolution
  7. Improve: Implement systemic changes if complaint reveals broader issues

Response Timing: While not always legally specified, best practice is 30-45 days for complaint resolution

💡 Regulatory Complaints: When a supervisory authority contacts you about a complaint, treat it seriously. Respond promptly (within requested timeframe), provide complete information, and cooperate fully. Regulatory investigations can escalate to enforcement actions if you're unresponsive or uncooperative.

9. Post-Incident Review and Continuous Improvement

Every incident and DSAR provides learning opportunities to strengthen your privacy program.

Lessons Learned Process

Post-Incident Review Meeting (Within 30 Days of Resolution):

  • Attendees: Incident response team, affected business units, leadership
  • Agenda:
    1. What happened? (timeline reconstruction)
    2. How did we detect it? (was detection adequate?)
    3. How did we respond? (what worked well?)
    4. What went wrong? (gaps in response)
    5. Root cause analysis (why did it happen?)
    6. What should we do differently? (improvements)

Common Improvement Areas:

  • Technical Controls: Strengthen security measures that failed
  • Detection Capabilities: Improve monitoring and alerting
  • Response Procedures: Update incident response plan based on experience
  • Training: Address knowledge gaps revealed during incident
  • Communication: Improve notification templates and processes
  • Data Management: Reduce data retention or improve data minimization

Documentation and Follow-Through:

  • Document lessons learned and action items
  • Assign ownership and deadlines for improvements
  • Track implementation of corrective actions
  • Update policies, procedures, and training materials
  • Share learnings across organization (without revealing sensitive details)

Common Domain 6 Exam Question Types

Question Pattern: Rights Identification

Format: "An individual requests [specific action]. Which data subject right are they exercising?"

What They're Testing: Ability to recognize different rights based on request description

How to Approach: Key words matter: "copy of data" = access; "delete" = erasure; "stop marketing" = object; "fix wrong info" = rectification; "transfer to competitor" = portability

Question Pattern: Notification Timelines

Format: "How quickly must [type of notification] occur under [regulation]?"

What They're Testing: Knowledge of specific legal deadlines

How to Approach: Memorize key timelines: GDPR regulatory notification (72 hours), GDPR DSAR response (30 days, extendable to 90), CCPA DSAR response (45 days, extendable to 90). Don't confuse regulatory notification with individual notification.

Question Pattern: Exemptions and Exceptions

Format: "Can an organization refuse [specific request] based on [circumstance]?"

What They're Testing: Understanding when rights can be limited or refused

How to Approach: Rights are not absolute. Common exceptions: legal obligations, legal claims, public interest, freedom of expression, security of processing. Know specific exceptions for each right.

Question Pattern: Breach Severity Assessment

Format: "[Scenario] occurs. Does this require regulatory notification?"

What They're Testing: Ability to assess whether breach meets notification thresholds

How to Approach: Under GDPR, notify if breach "likely to result in risk to rights and freedoms." Consider: data sensitivity, number affected, harm likelihood. When in doubt on exam, questions usually indicate severity clearly.

Study Tips for Domain 6

Domain 6 Mastery Checklist

  • ✓ Memorize all GDPR data subject rights (Articles 15-22) and what each means
  • ✓ Know key differences between GDPR and CCPA rights
  • ✓ Master the 8-step DSAR processing workflow
  • ✓ Memorize critical timelines: 72 hours (GDPR breach), 30 days (GDPR DSAR), 45 days (CCPA DSAR)
  • ✓ Understand when to notify regulators vs. individuals for breaches
  • ✓ Know common exemptions and exceptions to rights
  • ✓ Learn identity verification principles and risk-based approach
  • ✓ Understand breach classification levels and notification requirements
  • ✓ Study required content for regulatory and individual notifications
  • ✓ Know complaint handling process and post-incident review
⚠️ Common Study Mistakes for Domain 6:
  • Confusing the different data subject rights (they sound similar but are distinct)
  • Missing timeline differences between GDPR and CCPA
  • Not understanding when the 72-hour clock starts ("awareness" not "occurrence")
  • Treating all breaches as requiring individual notification (only if high risk)
  • Forgetting that rights have exemptions and are not absolute
  • Overlooking identity verification requirements
  • Not understanding the difference between refusing a request vs. extending timeline

Practice Questions for Domain 6

Question 1: Rights Recognition

Q: A customer requests their personal data in CSV format so they can import it into a competitor's service. Which GDPR right is being exercised?

A) Right of access
B) Right to rectification
C) Right to data portability
D) Right to erasure

Correct Answer: C

Explanation: The key indicators are: (1) machine-readable format (CSV), and (2) intention to transfer to another controller (competitor). This is exactly what data portability enables. Right of access provides data but doesn't require machine-readable format or facilitate transfer. This right only applies when processing is based on consent or contract.

Question 2: Breach Notification Timeline

Q: An organization discovers on Monday at 10am that unauthorized access to customer data occurred the previous Friday. When does the 72-hour GDPR notification clock start?

A) Monday at 10am (when organization became aware)
B) Friday (when breach occurred)
C) Monday end of business (when investigation complete)
D) Tuesday (next business day after discovery)

Correct Answer: A

Explanation: Under GDPR Article 33, the 72-hour clock starts when the organization becomes "aware" of the breach, not when it occurred. "Aware" means having reasonable certainty that a breach involving personal data has happened. In this case, Monday at 10am. The organization must notify the supervisory authority by Thursday at 10am (72 hours later), even if full investigation isn't complete.

Question 3: Right to Erasure Exception

Q: A customer requests deletion of their purchase history. The organization is subject to a tax audit requiring retention of financial records for 7 years. Can the organization refuse the deletion request?

A) Yes, due to legal obligation to retain records
B) No, right to erasure is absolute
C) Yes, but only if customer consents to continued retention
D) No, records must be anonymized instead

Correct Answer: A

Explanation: GDPR Article 17(3)(b) provides an exception to the right to erasure when processing is necessary for compliance with a legal obligation. Tax record retention is a clear legal obligation in most jurisdictions. The organization should explain this to the customer and specify when the data will be deleted after the retention period expires. The right to erasure is NOT absolute—it has several exceptions.

Master Domain 6 with Practice Questions

Test your knowledge of data subject rights, DSAR processing, and incident response with 100+ Domain 6-specific practice questions. Perfect your understanding of timelines, exemptions, and operational response.

Key Takeaways for Domain 6

  • Rights Are Not Absolute: Every right has exemptions—know when you can refuse
  • Timelines Are Strict: 72 hours, 30 days, 45 days—these are legal deadlines, not guidelines
  • Clock Starts at Awareness: For breaches, timeline begins when you become aware, not when breach occurred
  • Identity Verification Matters: Balance security with access; use risk-based approach
  • Documentation Is Critical: Record everything—regulators will ask for evidence of compliance
  • High Risk = Individual Notification: Under GDPR, notify individuals only if breach likely results in high risk
  • Process Over Panic: Pre-planned workflows enable effective response under pressure
  • Learn From Every Incident: Post-incident reviews drive continuous improvement

Connection to Other Domains

Domain 6 is where all previous domains are tested operationally:

  • From Domain 1: Framework defines rights fulfillment and incident response as program objectives
  • From Domain 2: Governance structures (incident response plans, DSAR procedures) are executed here
  • From Domain 3: Data inventory enables efficient DSAR response—you can't find data you don't know about
  • From Domain 4: Protection controls determine breach severity; encryption may eliminate notification requirement
  • From Domain 5: DSAR and incident metrics track operational performance and drive improvement
  • Back to All Domains: Incidents and requests reveal program gaps, triggering updates to framework, governance, assessments, and controls

Domain 6 completes the privacy program lifecycle. Requests and incidents test whether everything you've built actually works when it matters most.

Final Exam Preparation

You've now covered all six CIPM domains. Here's how to bring it all together:

Your Final Study Plan

  1. Week 1-2: Review all domain guides, focusing on weak areas identified in practice tests
  2. Week 3-4: Take 3+ full-length practice exams under timed conditions
  3. Week 5: Review incorrect answers, understand why you missed them
  4. Week 6: Light review of key concepts, focus on memorization items (7 PbD principles, timelines, etc.)
  5. Day Before: Quick review of domain summaries (1 hour), then rest and mentally prepare
  6. Exam Day: Execute your test-taking strategy, trust your preparation!

Complete Your CIPM Study Journey