Planning Privacy Risk at a Data Broker
Brightpath is a 260-person advertising-technology company that builds audience segments from purchased and licensed data: 12 sources, roughly 5 million profiles, plus first-party app data from 900 publisher partners. Its ISMS, certified to ISO/IEC 27001, uses a 5x5 asset-threat-vulnerability matrix over 380 assets with an annual cycle run by the security team. Privacy sits with a part-time DPO in Legal. When the PIMS project starts, the team copies three privacy rows into the existing register, scores them for "reputational damage to Brightpath" and sets an objective of "zero regulatory fines this year". The DPO objects that the register does not describe harm to the people in the segments, that purchased datasets have no documented lawful basis, and that the statement of applicability is still the 27001 document with a note saying "privacy controls are covered by GDPR compliance". The CISO wants planning finished in four weeks and asks what "good" looks like.
1. Critique the current planning approach and outline the artefacts that must change before implementation begins.
Read the worked answer
Three things are wrong, and each maps to a planning artefact.
Risk criteria. Scoring only "reputational damage to Brightpath" measures the wrong party. The privacy risk assessment must express likelihood and severity of harm to the individuals in the segments, alongside organisational impact, with defined scales and a documented acceptance threshold. Without that, treatment decisions have no defensible basis.
Unit of assessment. Assets are the wrong lens for privacy. The register should be organised by processing activity - segment creation, enrichment, profiling, licensing to buyers, retention, transfers to partners - because purpose, lawful basis, recipients and retention all vary by activity, not by server.
SoA. A 27001 SoA with a "GDPR covers it" footnote fails the standard. It must include the PIMS-specific controls applicable to Brightpath's roles, each with an applicability decision, justification and link to risk or legal obligation. Annex D's GDPR mapping is informative; it is not a control set and cannot substitute.
Also needed before implementation: a legal/regulatory obligations register, defined measurable objectives (for example "100% of data sources have a documented lawful basis and completed due diligence within 60 days"), a resource and competence plan, and a communication plan covering buyers and publishers. Four weeks is realistic only if the DPO and security team work the risk method together rather than in parallel.
2. How should Brightpath assess and treat the five million purchased profiles whose seller's lawful basis is unknown? Show the reasoning rather than just saying "do a DPIA".
Read the worked answer
Frame it as a decision with options, not a documentation exercise.
Assess. For each of the 12 sources: what was collected, from whom, for what original purpose, with what notice, and is Brightpath's use (segment building and licensing) compatible with it? Score severity of harm to individuals - is the data sensitive or inferential, does profiling produce significant effects, are vulnerable groups involved? Score likelihood given volume, recipient count and onward transfer. Record it in a DPIA where the processing is high-risk, and in the register either way.
Treat. Options, roughly in order of strength: stop using the source; restrict it to aggregated or de-identified outputs; re-contract with warranties, audit rights and indemnities plus technical suppression of sensitive categories; re-notice individuals and provide an effective opt-out; or accept the residual risk with a documented rationale, named owner and review date. Contractual warranties alone are the weakest option and should not be treated as eliminating risk.
Decide and record. The DPO and a business owner sign off, with a date and a trigger for re-assessment. If residual risk cannot be brought within the acceptance threshold, the correct outcome is to stop the processing - planning is precisely where that call belongs, before engineers build pipelines around the data.
Note that ISO/IEC 27701 requires you to identify and document obligations and lawful basis; it does not itself make the legal judgement, so take qualified legal advice and record that you did.
3. The CISO proposes keeping the 27001 statement of applicability and adding the line "privacy is managed under GDPR compliance". Evaluate that proposal.
Read the worked answer
It will not survive a stage 1 review.
The SoA is the bridge between the risk assessment and the controls the organisation actually operates. ISO/IEC 27701 extends the ISMS with PIMS-specific requirements and with control sets tied to the organisation's role - controller controls, processor controls and shared controls. Each of those must appear in the SoA with an applicability decision, a justification, and a reference to the risk or obligation it addresses. A footnote asserting compliance with a regulation is neither a control nor a justification, and it tells the auditor that no one has analysed applicability.
GDPR compliance and PIMS controls also answer different questions. The regulation states obligations; the standard states management-system requirements and controls, and includes areas the regulation leaves open, such as how you demonstrate operating effectiveness over time. The Annex D mapping is a convenience for readers, not a substitute for the SoA.
Practically, the CISO's instinct to avoid duplicate documents is sound. Keep one SoA, extended with the PIMS columns, and one risk method extended with privacy criteria. That is integration of management systems; what is proposed is replacement of analysis by an assertion, which is a different thing and a common cause of major nonconformities.