Security, Privacy and Compliance Risk Assessment Questions

Direct answer. A DPIA (data protection impact assessment) is a structured assessment, done before a processing activity starts, of the risks that processing creates for the people whose data is used, and of the measures that reduce them. Under the EU GDPR (General Data Protection Regulation), Article 35 requires one when processing is likely to result in a high risk to individuals' rights and freedoms. A good DPIA changes the design before shipping. Whether a given case legally requires one is a call for the privacy lead or counsel; engineering and product supply the facts.

Deciding whether a feature needs one
Article 35(3) names three cases where one is required: systematic and extensive evaluation of people by automated processing, including profiling, on which decisions with legal or similarly significant effects are based; large-scale processing of special categories of data (especially sensitive data such as health, ethnicity, religion or biometrics, which the GDPR treats more strictly) or criminal-offence data (records of convictions and offences); and systematic large-scale monitoring of a publicly accessible area. National regulators publish further lists. In practice, a product manager (PM) asks these screening questions: does the feature profile or score people; use new technology; combine datasets; process sensitive data or data of children or other vulnerable people; or operate at large scale? Two or more yes answers usually means do the DPIA. A short written "screening" outcome, even a no, is itself worth keeping.

What a good one contains (Article 35(7))

• A systematic description of the processing and its purposes.
• An assessment of necessity and proportionality (could we reach the goal with less data, and is the intrusion justified by the benefit; is each data item needed, and for how long).
• An assessment of the risks to individuals, scored on likelihood and severity of harm to them.
• The measures to address those risks, including safeguards and security.
  Also seek the DPO's advice (the data protection officer, the person an organization designates to advise on and monitor its GDPR compliance) where one is designated, and the views of the affected people where appropriate (Article 35(2) and (9)). If the risk stays high after the measures, Article 36 requires consulting the regulator before processing begins.

How findings change what engineering ships
Each risk becomes a tracked item with an owner and due date, and anything blocking is a release condition. Examples: remove a data field that is not necessary, shorten retention, pseudonymize identifiers (replace them with tokens), add an opt-out, restrict access. Residual risk is re-scored after the measures and signed off by the accountable executive.

What engineers and PMs hand over
A data-flow diagram, a field-level data inventory, retention periods, vendors and where data goes, and security controls. The DPIA package: flow diagram, risk register, residual score, sign-offs.

Worked example. A predictive personalization model that turns purchase history and browsing into homepage recommendations. Screening: profiles people, yes; uses new technology (machine learning), yes; combines datasets, yes; sensitive data (inferred health interests), yes; large scale, yes. Five of five, so a DPIA. Data flow: purchase and browsing events, then a feature table, then the model, then recommendations shown to users. Risk row, on 1-5 scales with High at 15 or more: inferring health interests, likelihood 4 x severity 5 = 20, High. The finding leads to removing health-related features from training, a decision engineering can ship in the sprint. Re-scored with that change, likelihood falls to 1, so residual risk is 1 x 5 = 5, Low, and severity stays at 5 because a health inference would still be serious if it occurred.

Pitfall. Writing the DPIA after launch, or filing it without changing anything.

Direct answer. I would run the DPIA (data protection impact assessment, a structured risk assessment of processing personal data) in this order: define the purpose and bring the right people in, map the data flows from CRM (customer relationship management) records and behavioral events into the new pipeline, assess risks to the individuals, agree measures, and sign off only when named conditions are true. Joining CRM identity to behavioral events is the risky step because it turns anonymous activity into a profile of a known person.

Who is involved
The marketing owner (states purpose and need), a data engineer (knows the real flows), a security architect (controls), the privacy lead or data protection officer (DPO, an independent privacy adviser that some organizations must appoint), legal for lawful basis (the legal reason, such as consent, that permits using the data) and consent rules, and the product or analytics owner who will run the pipeline. In a European analytics platform the DPO's advice is required where one is designated.

Mapping flows and assessing risk

1. Inventory sources and fields (email, account ID, device ID, page events) and where each is stored.
2. Draw the join: which key links CRM to events, who can query the joined table, where results go, how long it is kept.
3. List threat scenarios: a leak of the joined table; analysts or vendors seeing more than needed; cookie-based tracking without valid consent; function creep (using the data for a new purpose); retention without limit; re-identification of supposedly anonymous exports.
4. Score each by likelihood and severity of harm to individuals, then choose measures.

Illustrative scores, on 1-5 scales with High at 15 or more:

The two High rows are blocking: each needs a delivered measure before sign-off.

Template questions (with sample checkboxes)

• What is the specific purpose, and is each field needed for it? [ ] Yes [ ] Removed fields noted
• What is the lawful basis, and is consent captured for tracking? [ ] Documented
• Is the join key pseudonymized (replaced with a token)? [ ] Yes
• Who can access the joined data? [ ] Role-based, reviewed quarterly
• Retention period and automated deletion? [ ] Set
• Are vendors under a data processing agreement, and where is data hosted? [ ] Confirmed
• Can people opt out or ask for access and deletion? [ ] Tested

Technical and organizational measures (safeguards in software, such as encryption and access rules, and in process, such as training and written policies)
Tokenize identifiers (replace them with random stand-ins), separate the join table from raw CRM, limit access, aggregate before analysts see it, log queries, and agree a written purpose and a review date.

What has to be true before sign-off

• Lawful basis and consent mechanism (the cookie banner or sign-up checkbox that records agreement before tracking starts) confirmed by privacy and legal.
• Each blocking risk has a delivered measure, verified in test (for example, an analyst without access cannot query the join). Evidence looks like a dated log or screenshot of a denied query from a test analyst account, with the tester's name.
• Retention and deletion are working.
• Residual risk is documented and accepted by the accountable executive; if it is still high, Article 36 of the GDPR requires prior consultation with the regulator.

Pitfall. Approving on the strength of promised measures that are not yet built.

Direct answer. I would run a structured, time-boxed assessment in five steps: inventory what exists, map how personal data flows, identify threats and weaknesses against those flows, score and rank risks on one agreed scale, then assign each risk an owner and a treatment and report what is left: residual risk, the score after the planned controls, set against inherent risk, the score before any control. PII here means personally identifiable information: data that identifies a person, such as name, email, address or account number. A platform that ingests, stores and analyzes it concentrates risk, so I expect the highest risks to be about who can reach raw PII, and about copies nobody knows exist.

1. Scope and inventory (week 1)

• Agree scope and the scoring scale with the platform owner and the security lead. Get a named executive sponsor, because the risks will cross teams.
• List assets: ingestion sources, storage layers (lake, warehouse, backups), analytics tools, notebooks, exports, and the people and service accounts with access. For a SaaS platform also list every third-party service that receives data (sub-processors, the vendors that handle data on our behalf).
• Classify data by sensitivity (for example, direct identifiers, financial, special categories, the especially sensitive kinds that law treats more strictly, like health) and note volume and how many people are affected.

2. Map data flows
Draw source, ingestion, storage, transformation, analytics, outputs and deletion. Mark trust boundaries (where data crosses teams, networks or vendors). Threat sources to consider at each step: external attackers, a malicious or careless insider, a compromised service credential, a vendor failure, and plain error such as a misconfigured bucket.

3. Identify and score
Use a 1-5 likelihood scale and a 1-5 impact scale, score = likelihood x impact, and define bands up front: High is 15 or more, Medium is 8 to 14, Low is 7 or less. Impact should include harm to the individuals, not only cost to us.

These numbers are illustrative. In a real assessment I would calibrate each one with evidence (access reports, scan results) rather than opinion, and I would expect the order to move after a first look at actual access lists.

4. Owners and treatments
Each risk gets one accountable owner who can spend money or change the system, usually a data platform lead or a data owner (the business person accountable for a dataset, as distinct from the platform owner who runs the system), not the security team (security advises and verifies). Treatment is a decision per risk: mitigate (cut access, mask or tokenize PII (hide part of a value, or swap it for a random stand-in), encrypt, add logging), transfer (contractual terms, cyber insurance for a residual slice), avoid (stop collecting a field nobody uses) or accept (only with a named executive, within the organization's risk appetite, meaning how much risk leadership has agreed it can live with, and a review date). A Medium risk can be accepted by an executive with authority over that area; a High risk goes to the senior sponsor.
Rank 1 example: restrict raw PII to a small approved group, give analysts pseudonymized views (identifiers replaced by tokens), and review access quarterly.

5. Re-score and report residual risk
After the treatment plan, re-score assuming the planned controls work. If the access fix lowers likelihood from 4 to 2, residual is 2 x 5 = 10 (Medium), and I say so plainly, noting that impact does not fall because the data is still sensitive. Report to leadership a short ranked list: risk, inherent score, treatment and date, residual score, owner, and decisions needed (for example, accepting a Medium risk until Q3). Re-assess on a schedule and after major changes. Counsel decides whether any finding triggers a legal duty such as a data protection impact assessment (a formal review of how personal data is used) or breach analysis.

Pitfalls. Scoring before inventory, giving the security team ownership of every risk, and presenting residual risk as zero.