Domain III of the CIPM exam (Privacy Operational Lifecycle, ~36% of the exam) tests four specific workflows: vendor management, data subject request handling, data protection impact assessments, and incident response. These are not tested as theory — the exam gives you a realistic organisational scenario and asks what a competent privacy programme manager should do at a specific step in the workflow. Knowing the framework is not enough; you need the operational sequence.
The CIPM is frequently described as the "operational" IAPP certification, but that description undersells how specific the operational content gets. It is not enough to know that vendor management is part of a privacy programme — the exam expects you to know what the vendor onboarding assessment covers, what provisions belong in a Data Processing Agreement, what happens when a vendor's DPA terms are unacceptable, and how to handle vendor offboarding in a way that satisfies data deletion requirements.
This article covers the four operational workflows in Domain III that generate the most exam questions, with the decision points, sequencing, and scenario examples that matter most.
Workflow 1: Vendor Management and Data Processing Agreements
The vendor management lifecycle is the most tested operational workflow on the CIPM. It spans four phases: onboarding assessment, contract review, ongoing monitoring, and offboarding. The exam tests decision-making at each phase.
Before engaging a vendor that will process personal data, conduct a privacy risk assessment. This covers: what personal data the vendor will access, where it will be processed (including sub-processors and data transfers), the vendor's security posture, their own compliance status, and whether they have had previous data breaches or regulatory actions. Risk assessment output determines whether the engagement proceeds, what DPA provisions are needed, and what ongoing monitoring is required.
A DPA (under GDPR, required by Article 28) must include: subject matter, duration, nature and purpose of processing, type of personal data, categories of data subjects, and controller obligations and rights. Key DPA provisions the CIPM exam tests: sub-processor restrictions (vendor cannot engage sub-processors without controller authorisation), security obligations including breach notification to controller without undue delay, return or deletion of data on contract termination, and cooperation with audits.
Everything you need to prep for the 2026 CIPM, in one place.
Cram guide, 300 practice questions, and a career guide — put together so you're not hunting across five different resources.
Get the Complete Pack →A signed DPA does not end the vendor privacy programme obligation. Ongoing monitoring includes: annual or periodic security questionnaires or audits, review of vendor sub-processor changes (which require controller consent under a restrictive DPA), monitoring for vendor security incidents that could affect your data, and tracking vendor compliance status for regulatory changes. The exam will give you scenarios where monitoring is inadequate and ask what went wrong in the programme design.
When a vendor relationship ends, the privacy programme must ensure: return or confirmed destruction of personal data, confirmation that sub-processors have also destroyed data, documentation of the destruction for audit purposes, and removal of the vendor from the organisation's processing records. The exam tests whether candidates know that offboarding is a defined programme activity — not something that happens automatically when a contract expires.
A company's privacy manager is reviewing a DPA proposed by a cloud analytics vendor. The vendor's standard DPA permits the vendor to engage new sub-processors with 30 days' notice to the controller, and states that the controller's failure to object within that period constitutes consent. The privacy manager believes this sub-processor clause is insufficient.
What should the privacy manager do?Negotiate the clause to require explicit written consent before the vendor may engage new sub-processors — not a deemed consent mechanism based on the controller's silence. Under GDPR Article 28(2), processors may not engage sub-processors without prior specific or general written authorisation of the controller. A deemed consent provision does not satisfy the "specific or general written authorisation" requirement when the controller has not actively provided it. If the vendor refuses to modify the clause, the privacy manager should escalate to legal counsel and assess whether the engagement can proceed given this compliance gap.
Workflow 2: Data Subject Request Handling
Data Subject Request (DSR) handling is a programme management function, not a legal analysis function. The legal requirements define the obligation; the programme manager designs and runs the process. The CIPM tests the process — intake, identity verification, routing, response quality, and documentation — not just knowledge of the rights themselves.
DSRs can arrive through multiple channels — a web form, email, phone, in-store, through a social media message. The programme must have a defined intake process that captures all channels, assigns a request ID, logs the receipt date (the clock starts here), and routes to the appropriate team. Missing an informal DSR received outside the designated channel and failing to log it is a programme failure — not a legal technicality.
Before fulfilling a DSR, the organisation must verify the requestor is who they claim to be — without collecting more data than necessary for verification. The verification approach should be proportionate to the sensitivity of the data at stake. For a low-sensitivity access request, matching the requestor against a known account may suffice. For a deletion request involving health data, stronger verification is appropriate. The CIPM exam tests whether the verification approach is proportionate — over-verification (requiring government ID for access to a newsletter subscription) is a programme error, not a safe harbour.
After locating the data and determining the applicable rights, the response must be: complete (all systems containing the subject's data must be checked, including backups and archives with applicable caveats), accurate, in a format the subject can use, and delivered within the applicable timeline. A quality control review step before sending the response — checking completeness, accuracy, and format — is a programme best practice that the CIPM recognises. Sending an incomplete access response because one business unit was not included in the search is a programme design failure.
When a request is manifestly unfounded (no legitimate purpose, clearly vexatious) or excessive (repetitive requests of the same type), the organisation may charge a reasonable fee or refuse. The exam tests whether candidates know that this is an available option — and that the burden of proving the request is manifestly unfounded or excessive rests with the organisation. Document the reasoning thoroughly before invoking this option.
DSR response timelines are frequently tested. Under GDPR: 30 days from receipt, extendable by a further 60 days for complex or numerous requests, with notice to the requestor within the original 30 days explaining the extension and the reasons. The exam will give you scenarios with specific dates and ask whether the response was on time — or whether an extension was properly handled.
Workflow 3: Data Protection Impact Assessments (DPIAs)
DPIAs are legally required in specific circumstances but are also a programme management decision — determining when to conduct one, how to run it, and what to do with the output. The CIPM tests both the trigger conditions and the process.
| DPIA Trigger | Example | Programme Action |
|---|---|---|
| Systematic and extensive profiling with significant effects | Automated credit scoring, employee performance profiling | DPIA mandatory before launch |
| Processing special categories at large scale | Health data analytics, genetic data research | DPIA mandatory; DPA consultation if high residual risk |
| Systematic monitoring of public areas | CCTV covering public spaces, location tracking | DPIA mandatory |
| New technology with uncertain risks | Facial recognition, IoT devices collecting behavioural data | DPIA strongly recommended; supervisory authority lists may make it mandatory |
| Data matching across multiple sources | Combining loyalty programme data with social media data | Assess against supervisory authority high-risk list |
The DPIA process itself is testable. A competent DPIA includes: a description of the processing and its purposes, an assessment of the necessity and proportionality of the processing, an assessment of the risks to data subjects, and the measures to address those risks. The output is a risk-rated assessment — and if residual risk remains high after risk mitigation, the controller must consult with the supervisory authority before proceeding.
A retail bank wants to implement an AI-powered loan decisioning system that will automatically approve or reject loan applications for retail customers based on 40+ data points including transaction history, spending patterns, and social media data. The technology team says the system will launch in six weeks. The privacy manager is asked to review.
What should the privacy manager do first?Require a DPIA before the system launches. This scenario triggers at least two mandatory DPIA conditions: systematic and extensive profiling with significant effects (credit denial is a legal effect on individuals), and the use of special category proxies (transaction history may reveal health, religion, or other special category information). The programme manager should also flag that the automated decision-making without human review may trigger Article 22 obligations. The six-week timeline is a programme risk, not a privacy risk — it does not reduce the DPIA requirement. If the DPIA reveals high residual risk, the DPA must be consulted before launch, which adds further time.
Workflow 4: Incident Response
Privacy incident response is a distinct function from information security incident response, although the two overlap. The CIPM tests the privacy programme manager's role in incident response — not the technical security response, but the decision-making about notification, documentation, and programme remediation.
When a potential privacy incident is reported (by security, a vendor, an employee, or a data subject), the privacy programme manager conducts an initial assessment: what personal data was involved, how many individuals, what categories of data, and what the likely impact is. This assessment determines urgency and whether the incident rises to the level of a notifiable breach under applicable law.
Not every privacy incident is a notifiable breach. Under GDPR, notification is required when the breach is "likely to result in a risk to the rights and freedoms of natural persons." Low-risk incidents — encrypted data lost with no evidence of decryption, accidental internal disclosure immediately corrected — may not require notification but must still be documented. The programme manager makes this determination with legal counsel and documents the reasoning thoroughly.
If notification is required, timelines are strict. Under GDPR: 72 hours from awareness to DPA notification (where feasible). Individual notification "without undue delay" when the breach poses a high risk. The exam tests whether candidates know the 72-hour clock runs from when the controller "becomes aware" — not from when the security team first detects the incident. Awareness is when the controller has sufficient certainty that a breach has occurred, not when investigation is complete.
Regardless of whether notification was required, every breach must be documented in the organisation's breach register under Article 33(5). The post-incident review assesses root cause, programme gap, and remediation — and the output feeds back into the privacy programme's risk register and controls framework. The exam recognises post-incident review as a defined programme activity with documented outputs, not an informal debrief.
Everything you need to prep for the 2026 CIPM, in one place.
Cram guide, 300 practice questions, and a career guide — put together so you're not hunting across five different resources.
Get the Complete Pack →Data Retention and Destruction — The Fourth Operational Area
Data retention is a programme management function that intersects with legal obligations, technical architecture, and vendor management. The CIPM tests retention at the programme level: how a retention schedule is designed, maintained, and enforced.
| Retention Programme Component | What the CIPM Expects |
|---|---|
| Retention schedule design | Retention periods set by data category, not by system — driven by legal minimums, regulatory requirements, and business need. Schedule reviewed periodically and updated when laws change. |
| Legal hold process | Suspension of normal retention and destruction when data may be relevant to litigation or regulatory investigation. Legal hold must reach all systems containing the held data. |
| Destruction process | Defined process for each media type (secure deletion for electronic, cross-cut shredding or incineration for paper). Destruction documented — who destroyed, when, what data category. Certificate of destruction obtained from third-party destruction vendors. |
| Vendor retention alignment | Vendor DPAs must reflect the controller's retention requirements. Vendor data must be destroyed on contract termination with documented confirmation. |
| Backup and archive carve-outs | DSR deletion obligations extend to backups — with the recognised exception that overwriting backup media on its normal rotation cycle is an acceptable approach for most regulators, provided the data is quarantined from active use in the interim. |
The CIPM exam's operational coverage reflects what privacy programme managers actually do in well-run privacy functions. Candidates who have spent time in privacy operations roles — running vendor reviews, handling DSR queues, managing incident responses — often find that the exam validates their experience rather than testing new content. Candidates who come from legal or policy backgrounds without operational experience find Domain III the hardest section, precisely because it cannot be answered from legal knowledge alone.
For the complete CIPM domain structure and study hour allocation, see the CIPM Study Guide 2026. For the sample questions that show the operational format in practice, see the CIPM Sample Questions guide.