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)
| Risk | L | S | Score (band) | Treatment | Residual L x S (band) |
|---|
| R1 Precise location kept indefinitely | 4 | 4 | 16 (High) | Keep 30 days, then aggregate (combine into group totals so no one person is identifiable) or delete | 2 x 3 = 6 (Low) |
| R2 Location leaks to the analytics vendor | 3 | 4 | 12 (Medium) | Strip location from the events the analytics vendor's SDK (software library embedded in the app) sends | 1 x 4 = 4 (Low) |
| R3 Staff over-access | 3 | 3 | 9 (Medium) | Role-based access plus access logging | 2 x 3 = 6 (Low) |
| R4 Inference of home, workplace, sensitive places | 4 | 5 | 20 (High) | Off by default and opt-in, coarsened precision (location rounded to a wide area instead of exact coordinates), no sensitive-place retention | 2 x 4 = 8 (Medium) |
| R5 Breach of the location store | 2 | 5 | 10 (Medium) | Encryption, pseudonymous IDs (random codes in place of user identities, stored apart from the location data), separate store | 2 x 4 = 8 (Medium) |
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)
| Week | Item | Owner |
|---|
| 1 | Scored assessment and DPIA draft | Privacy lead |
| 2-4 | 30-day retention job, opt-in default, precision coarsening, no retention of sensitive places | Feature engineering lead |
| 3-5 | Vendor event filtering, role-based access with access logging, encryption, pseudonymous IDs and separate store | Platform engineer |
| 6 | Verification test against each blocker, DPIA review (DPO and counsel review the DPIA and advise) | Security architect |
| 8 | Launch readiness sign-off | Product owner |
| 10 | Launch | Engineering manager |
| Post-launch, weeks 14-18 | Alerting and history viewer | Feature engineering lead |
| Post-launch, from week 14, monthly | Manual access-log review until alerting ships | Privacy lead |
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.
