3.3 Roles, Responsibilities, Metrics & Continuous Legal Monitoring

II.B — Clarifying Roles and Responsibilities

The CIPM BoK treats role clarity as a governance control in its own right. Unclear ownership is the root cause of most privacy failures the exam presents — a breach that IT assumed Privacy would escalate, a vendor that Legal assumed Procurement had vetted, a regulator inquiry that no one owned because the privacy leader was on leave.

Privacy Team and Stakeholder Roles

The core roles the BoK expects you to define:

• Privacy Leader (CPO/DPO) — accountable for the program; reports to the board or senior executive; owns policies, plans, and regulator-facing communication.
• Privacy Analyst / Program Manager — runs day-to-day operations: DSR fulfillment, complaint triage, vendor assessments, training coordination, metrics reporting.
• Privacy Champions / Liaisons — embedded in business units; first-line privacy contact for product teams; not full-time privacy staff.
• IT Security — owns technical safeguards and incident detection; consults Privacy on privacy-impacting changes.
• Legal / GC — advises on legal interpretation, contracts, litigation hold, and regulator strategy; does not own the privacy program.
• HR — owns employee data, onboarding privacy training, and personnel aspects of investigations.
• Procurement / Vendor Management — owns vendor due diligence and contractual privacy terms before a vendor touches personal data.
• Records Manager — partners with Privacy on retention and disposal execution.

Roles for Data Sharing and Disclosure

Sharing and disclosure require distinct role definitions for internal and external use:

• Internal sharing — data owner approves; Privacy reviews purpose limitation; IT enforces access controls.
• External sharing (vendors/processors) — Procurement owns contract; Privacy approves the data protection agreement and transfer mechanism; Legal reviews liability; the business unit owns the business case and minimization.
• Regulator disclosure — Privacy Leader owns; Legal advises; business units supply data.
• Law enforcement disclosure — Legal owns the response; Privacy tracks the request; only compelled disclosures are made, and data subjects are notified where lawful.

Roles for Breach Response by Function

The BoK explicitly asks you to define breach-response roles by function, not by name:

RACI Matrix Excerpt

A RACI matrix is the exam-expected tool for clarifying ownership. R = Responsible (does the work), A = Accountable (owns the outcome and signs off), C = Consulted (provides input), I = Informed (receives results).

The most common governance failure is confusing R and A — a business unit is Responsible for delivering DSR data, but the Privacy Leader is Accountable if the deadline is missed.

II.C — Privacy Metrics for Oversight and Governance

Metrics are how the privacy program becomes visible and enforceable to each audience. The BoK is explicit: metrics must be created per audience, with a clear process describing their purpose, value, and reporting cadence.

Metrics by Audience

Anti-Pattern: One Dashboard for Everyone

A single privacy dashboard shown to the board, regulators, and business units simultaneously is a governance anti-pattern. The board does not need per-team DSR aging; business units do not need the program-maturity score. The exam rewards audience-specific metrics tied to a specific decision the audience owns.

Continuous Legal Monitoring

II.C requires establishing monitoring and enforcement systems to track multiple jurisdictions for changes in privacy law to ensure continuous alignment. This is not ad-hoc news scanning. A compliant monitoring system has:

• A defined scope — the jurisdictions the organization operates in or transfers data to.
• Source list — regulator publications, legislative trackers, IAPP updates, qualified counsel in each jurisdiction, and reputable legal-update services.
• Cadence — a defined review frequency (e.g., weekly for high-exposure jurisdictions, monthly for lower-exposure).
• Triage and impact assessment — each change assessed for impact on policies, controls, contracts, and training.
• Routing — impacts routed to the plan owner (retention, breach, DSR, complaint) for action.
• Enforcement — the privacy leader tracks change implementation to closure; metrics report open legal-monitoring actions to the steering committee.

Worked Scenario: Multi-Jurisdiction Legal Monitoring

A multinational retailer operates in the EU, the UK, California, Brazil, and India. On a Monday, the privacy analyst sees three updates in one weekly scan: (1) a new EU Court of Justice judgment narrowing legitimate interests for marketing analytics, (2) a California Privacy Protection Agency rulemaking on automated decisionmaking, and (3) a Brazilian ANPD guidance on international data transfers.

What does the monitoring system require?

1. Triage each change against the affected plans and policies — (1) affects the marketing-analytics purpose-limitation policy and the LIA template; (2) affects the DSR plan (new rights-type request) and the training plan; (3) affects the data-sharing and transfer policy and vendor contracts with EU-origin data.
2. Assign an owner and a due date for each impact assessment, not just 'Privacy will look at it.'
3. Route to plan owners — marketing policy owner, DSR operations lead, vendor management lead.
4. Track to closure and report aging to the privacy steering committee.
5. Update the records of processing and the training content once each change is implemented.

The governance failure mode is seeing the alerts, filing them, and never closing the loop — which is why the BoK pairs monitoring with enforcement systems.