Three Frameworks, One Company
A retailer operates in 12 countries through three business units. Each unit has built its own privacy framework: separate DSAR intake, separate retention schedules, separate vendor questionnaires. Legal drafts notices, marketing runs consent banners, the CISO owns security controls, and each unit's operations team handles requests locally. A recent internal review found the same vendor assessed three different ways and a retention schedule that deletes marketing data at 24 months in one unit and 60 months in another. Customer complaints about unfulfilled access requests are rising. The CPO has authority to set policy but no authority over unit headcount.
1. How should the CPO decide what to centralize versus federate?
Read the worked answer
Use one test: centralize what must be identical to be defensible or efficient; federate what must be local to be lawful or workable.
Centralize: the control catalog and its evidence requirements, retention principles and the schedule baseline, vendor risk tiering and the questionnaire, DSAR workflow and the tracking system, the record of processing activities schema, and training content. These are duplicated effort today and inconsistency across them is itself the risk.
Federate: statutory interpretation for local notices, local regulator relationships, the decision on legal basis where local law constrains it, and the operational execution inside each unit's systems.
Because the CPO lacks headcount authority, centralization must be sold as removing work from the units, not adding it. Consolidating three vendor questionnaires into one tiered questionnaire is a headcount-neutral win for every unit head and buys credibility for the harder asks.
2. Legal, Marketing, the CISO, and Unit Operations all touch consent. How should the CPO resolve the ownership conflict?
Read the worked answer
The problem is not ambiguity about who 'owns privacy' - everyone agrees the CPO does. It is that four functions each own a fragment of one process with no handoff contract.
Resolve it by separating three things that are usually conflated in a RACI:
- Accountable - one name per outcome. For consent: the CPO is accountable for the consent standard and for evidence that it is being met.
- Responsible - who does the work. Marketing operates the banner and consent record; Legal writes the underlying notice language; Engineering implements the tag behavior.
- Consulted / Informed - the CISO is consulted on the integrity of consent records, not accountable for consent.
Write the RACI at the level of discrete outcomes ('a consent state change is reflected in downstream processing within X hours'), not functions ('consent'). Fragment-level RACIs are where ownership arguments go to die. Publish the handoffs, then test one end-to-end to prove the model works before rolling it out to all 12 countries.
3. What is the strongest argument for making a single record of processing activities the framework's foundation?
Read the worked answer
Because almost every other framework component is a query against it. Retention schedules, DPIAs, transfer registers, DSAR fulfillment routes, and vendor scope all depend on knowing what data is processed, where, why, by whom, and for how long. Three units maintaining three partial inventories guarantees that retention decisions and vendor assessments diverge - which is exactly the symptom the review found.
Practically, this argues for sequencing: build one inventory with a mandatory minimum schema (purpose, categories, recipients, transfers, retention, system owner) and make it the intake gate for new processing. That way the inventory stays current through the change process rather than through an annual refresh nobody completes. It also gives the CPO the first real evidence base for reporting to the board, which matters for the next budget conversation.