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 scope the DPIA around the full data journey of the recommender: the purchase history, the third-party demographic data bought to enrich it (enrichment means adding extra attributes about each customer), the profile and model built from them, and what leaves the system. I expect the highest-scoring risks to be profiling that infers more than people expect and re-identification when third-party data is joined, with over-collection scoring lower (Medium, 12) but feeding several other rows, which is why fixing it early pays off. I would prioritize the mitigation backlog by risk score first, then by effort and by how much each fix reduces the score. A DPIA (data protection impact assessment) is the structured risk assessment the GDPR requires for processing likely to be high risk, Article 35(3) names three triggers, and regulators' screening criteria add profiling and combining datasets, so a recommender built on joined purchase and third-party data usually needs one, even though ordinary product recommendations may not meet the Article 35(3)(a) test of decisions with legal or similarly significant effects.

Scoping

• Map the flow: source (purchase history, enrichment API), join keys (the fields, such as email or customer ID, used to match one person's records across datasets), feature store (a shared table of precomputed inputs the model reads), model, outputs shown to users, retention and deletion, and any cross-device linkage (matching one person across phone and laptop) or transfer to another country.
• Define the purpose precisely ("recommend products on our site") so extra uses are visible.
• Involve the product owner, data scientists and engineers, the privacy lead or DPO (data protection officer, the person who advises on privacy-law compliance), security, and legal. For a financial-product recommender, add compliance, because recommendations can affect people's finances and legal gets the residual-risk write-up.
• Check the lawful basis for each data source (the legal reason, such as consent or contract, that permits using it), and what the third party says about the origin of its data.

Risks expected to matter most (illustrative scoring, L x I on 1-5)

Impact here means severity of harm to individuals, not cost to the company.

Prioritizing the backlog
Rank by score, then pick the fix with the largest score reduction per unit of effort. Illustrative, with effort in engineer-days: minimizing enrichment fields cuts profiling 16 to 8 (L 4 to 2), over-collection 12 to 6 and re-identification 15 to 10, a total drop of 8 + 6 + 5 = 19 for 5 days, or 3.8 points a day. Retention and deletion jobs cut one row from 12 to 6 for 4 days, 1.5 a day. Access controls plus a re-identification test cut one row from 15 to 10 for 10 days, 0.5 a day. These scores overlap on the re-identification row: once minimization has taken it from 15 to 10, the access-control item starts from 10, so its real gain is smaller than 5 points and 0.5 a day is an upper bound. Re-score after each fix. Minimization comes first because it cuts several risks at once: request only the enrichment fields the model needs, drop sensitive categories, and coarsen demographics (age bands instead of birth dates). Retention and deletion jobs are a separate item and come second, at 1.5 points a day. Then add opt-out and transparency, then access controls and a re-identification test (try to link records in the enriched data back to named people using only the other fields available; the share you can match measures the risk). Cross-border transfer needs counsel to choose the legal mechanism.

Residual risk and sign-off
Re-score after the measures. If a High remains, the DPO advises, and under Article 36 the regulator may need to be consulted before launch. Document residual risk plainly for legal and the accountable executive.

Pitfall. Treating the model as the only risk and ignoring the enrichment data's origin.

Direct answer

I would run a short, scored privacy risk assessment in the first week (risk assessment here means rating each risk by likelihood and harm), treat the fixed launch date as a constraint on scope (what ships) rather than on safety, commit to the mitigations that bring every High risk down before launch, defer only items whose absence leaves a risk at Low or Medium with an interim control, and write the remaining risk into a signed acceptance record owned by a named business executive. Where GDPR (the EU privacy law) applies and the processing is likely to be high risk to individuals, Article 35 requires a data protection impact assessment (DPIA, a structured written assessment of risk to people) before the processing starts. The company, as controller, decides whether a DPIA is legally required, taking the advice of the data protection officer where one is designated (Article 35(2)) and of counsel (the company's legal adviser); engineering supplies the facts, rates the risks and proposes how to treat them.

1. Assess the risk (week 1)

• Describe the processing: what data, why, who sees it, where it goes, how long it is kept. Article 35(7) requires the description, a necessity and proportionality check, a risk assessment for individuals, and the safeguards. Article 35(9) also asks the controller (the organization deciding why and how the data is used, here your company) to seek the views of data subjects (the people the data is about, here the app's users) or their representatives where appropriate, so a small user-research check belongs here.
• Score each risk as likelihood (1-5) times severity of harm to the individual (1-5). Note the scale is harm to people (stalking, discrimination, distress), not harm to the company. Bands used here (illustrative): 15 or more High, 8 to 14 Medium, 7 or less Low. The privacy lead and the accountable executive agree the cut-offs before scoring; 15 is just under the 16 you get from likelihood 4 x severity 4, so a likely and seriously harmful risk always lands High, and the exact line matters less than fixing it in advance.

2. Worked example: a feature that starts collecting precise location (illustrative, launch in 10 weeks)

Both High risks (R1 at 16, R4 at 20) are at or above the 15 line, and after treatment none remains High. Residual risk is the risk left after treatment: the accountable executive may accept the remaining Medium scores because they are inside the bands leadership set and each has an owner, controls and a review trigger.

3. Commit versus defer

• Commit before launch (launch blockers): everything that moves a High risk down (R1 retention, R4 opt-in and coarsening), plus R2 vendor stripping, R3 role-based access with access logging, and R5 encryption with pseudonymous IDs and a separate store, because they are cheap and hard to retrofit once data exists (and the logging is the interim control for the deferred alerting below).
• Defer with an interim control: automated anomaly alerting on staff access (interim: R3 access logging at launch plus a manual monthly log review owned by the privacy lead, first review one month after launch and then monthly until the alerting ships) and a user-facing location-history viewer (interim: deletion via support request). Deferral is allowed because the residual score does not depend on these items.
• If the date and the blockers cannot both fit, cut scope (launch to a smaller cohort, or ship without the opt-in sharing feature). Do not drop a blocker. I would change this call only if a blocker proves infeasible, in which case the risk goes back to the executive for a fresh decision.

4. Delivery plan with owners and timeline (illustrative)

Each row has one named owner and a date, and the plan is tracked as ordinary delivery tickets so privacy work competes visibly with feature work.

5. Record the residual risk leadership accepts

The acceptance record lists R4 (8, Medium) and R5 (8, Medium) as accepted, with the reasoning, the controls in place, the deferred items and their dates, and a review trigger (a change in the data collected, a vendor change, or an incident). The accountable executive (for example the product VP) signs, with privacy counsel or the DPO consulted. Under GDPR Article 36, if the DPIA indicates high risk and the controller's own measures cannot reduce it (the Article 36(1) wording is high risk "in the absence of measures taken by the controller to mitigate the risk", read in practice as high residual risk after the measures the controller can itself take), the controller must consult the supervisory authority (the independent public body that enforces GDPR in each EU country) before processing, and the authority has up to eight weeks to respond (extendable by six, and the clock can be suspended while the authority waits for information it asked for). That wait is why a High residual risk would move the launch date: it cannot simply be signed off internally. Here no High risk remains, so consultation is not triggered on these scores; counsel confirms that, with the DPO (data protection officer, the independent privacy adviser) consulted, and also checks whether national law adds a prior-consultation duty for this kind of processing (Article 36(5) lets member states do so for some public-interest processing).

Pitfalls

• Scoring risk to the company instead of harm to individuals.
• Accepting a risk with no named owner or review date.
• Deferring a control that a High score depends on.

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.

Short answer. Risk appetite is the broad amount and type of risk the company is willing to pursue to meet its goals, set by the board. Risk tolerance is the measurable limit around a specific objective that engineers can check themselves against. Appetite says "we accept little risk with customer data"; tolerance says "no critical vulnerability stays open on an internet-facing system for more than 7 days".

In practice. Appetite is a few plain statements per risk area, owned by the board or executive team, reviewed yearly. Tolerance turns each statement into thresholds that are measured and have an owner. If a team cannot tell whether it is inside the tolerance, the tolerance is not operational.

Setting both for a global SaaS company (all numbers illustrative):

Making it usable by engineering

• Express tolerances as automated checks (build pipeline gates, which stop a release when a check fails, and dashboards) rather than documents.
• A risk acceptance authority matrix (who may sign off on how much risk) tied to a score, where the score is likelihood (1 to 5) times impact (1 to 5): Low (1 to 4) by the team lead, Medium (5 to 9) by the engineering director, High (10 to 16) by the executive sponsor with the security lead, Critical (20 to 25) not acceptable beyond a short period without the executive team.
• Pre-approved patterns so teams do not ask for permission each time: for example, a standard way to store customer data with encryption already configured, which any team may use without a risk review.
• Review thresholds when the business changes; tolerance that never fires is probably set too loose.

Machine learning systems. If the company trains machine learning models, they need their own tolerances: no personal data in training sets without a completed privacy assessment, a limit on measured performance gaps between user groups (for example, accuracy for one region or language far below the average), a required review when drift (the model's inputs or accuracy shifting away from what it was trained on) crosses a set threshold, and an escalation path to the privacy lead and executive sponsor for incidents such as a model leaking training data. Metrics: share of models with a completed assessment, count of open model-risk exceptions (approved departures from these tolerances), time from drift alert to review.

Pitfall. A single "low risk appetite" statement with no tolerances, so every team decides alone.