Balancing Security, Privacy and Business Enablement Questions

Frame the question as a decision with a range. Privacy says: keep one year, not five (GDPR Art 5(1)(e), the storage limitation principle: keep identifiable data "no longer than is necessary"). The burden is on us to justify five years, so I would measure what the extra four years buy.

Step 1: backtest by window. A backtest retrains the model on past data and checks how it would have performed. Train the same model on the last 1, 2, 3 and 5 years of history, evaluate each on the same recent holdout period (a stretch of recent data kept out of training so every model is scored on the same unseen data), and plot the metric against window length. Check seasonality (a pattern that repeats every year, such as a December sales peak): one year of data contains only one December, so the model cannot tell a real seasonal peak from a one-off, while three years contain three.

Step 2: convert to money, with a range (illustrative numbers). The crux is how a model metric becomes revenue: take the lift the model delivered in past A/B tests or holdouts (revenue per user with the model vs without), assume the 1-year model delivers the same share of lift as its backtest score relative to the 5-year model, and get the range from repeating the backtest across several holdout periods and random seeds, so the range reflects real variation rather than a guess. If possible, confirm with a small live test of the 1-year model against the current one. The figures below are assumed for illustration, not measured. Suppose the model drives $6.0M a year of incremental revenue. If the 1-year model keeps 94% of that, the loss is 6.0 x 0.06 = $0.36M a year; across a plausible 90% to 97% range it is $0.18M to $0.60M. Say what the uncertainty is.

Step 3: net it against what the shorter retention gives. Lower storage and compute cost, and lower exposure. Illustrative breach expectation (the assumed $4M breach cost and 2% yearly chance are placeholders to replace with your own estimates; ALE = SLE x ARO, single loss expectancy times annual rate of occurrence): $4M x 0.02 = $80k a year; with a fifth of the records (one year of five), about $16k, so about $64k less. That is a rough scaling, since breach cost does not shrink in proportion to records. Net on these assumed numbers: the revenue loss of $0.18M to $0.60M a year is several times the roughly $64k breach-cost saving (0.36 / 0.064 is about 5.6x at the midpoint), so on expected money alone keeping five years of raw data wins. That is why the case for shortening cannot rest on this ledger: Art 5(1)(e) is a legal duty to justify retention, expected-loss figures understate regulatory and trust costs, and option (b) below is built to keep most of the lift while cutting the raw data. Also test the opposite risk: older data can describe a market that no longer exists (drift), so the backtest curve may flatten or even rise at shorter windows, in which case the loss is smaller or zero.

Step 4: present options, not a verdict: (a) keep 5 years of raw data; (b) 1 year raw plus 5 years of aggregated or de-identified features (summary numbers, such as weekly totals per region, with names and IDs removed; Recital 26, the part of the GDPR preamble on what counts as anonymous, says data that cannot identify people by any means reasonably likely to be used falls outside the GDPR, but test that claim, since pseudonymized data, where identifiers are swapped for codes that can be linked back, does not); (c) 1 year only. Show cost range, privacy gain and what you recommend. Mine is (b), tested in the backtest.

Who decides: the business owner and the DPO (Data Protection Officer, the person who advises on GDPR compliance), with legal confirming the retention justification.

Direct answer

I decide by asking one question first: does the rule require the explanation to exist before the first affected decision, or can the required outcome be delivered another way? If a hard legal gate says "no decision without a specific reason", I do not ship the unexplainable model as the decision-maker. I ship a version that can give the reason: either a model that is interpretable by construction makes the decision, or the opaque model scores and a validated attribution method supplies the reasons. The second route counts as explainable only if those reasons are tested to be faithful to what drove the score; if they cannot be shown to be, the opaque model does not decide alone. Counsel confirms what the rule demands. Engineering decides how to meet it.

What the rules require

• US credit (ECOA, the Equal Credit Opportunity Act, a US law against discrimination in lending, and its Regulation B, the rule that carries it out): a creditor that denies credit must tell the applicant the specific, principal reasons. The CFPB (Consumer Financial Protection Bureau, the US consumer-finance regulator) has said that using complex algorithms, including machine learning, does not excuse this and that a model too opaque to explain is not a defence.
• EU GDPR Article 22: a person has the right not to be subject to a decision based solely on automated processing that has legal or similarly significant effects. Where the contract or explicit-consent exceptions apply, the controller must offer human intervention, a way to state the person's view, and a way to contest the decision.

Decision criteria

What the shipped version looks like

1. Reason codes, the short standard phrases printed on the decision letter, must come from the model that actually made the decision. There are two routes. Route one: an interpretable model decides, for example a scorecard (points added or subtracted per input), and its own largest negative contributions are the reason codes. Route two: the opaque model scores and an attribution method (a technique that estimates how much each input pushed this one applicant's score up or down) produces the reason codes. Attribution reasons are approximations of the model's behaviour, so I test that they are stable and faithful (they reflect what really drove the model, not merely sound plausible) on held-out cases (past applications not used to build the model) before relying on them. A separate, simpler model that only imitates the opaque score is not a third route: its reasons describe the imitator, not the decision, so it could explain the opaque model only if tested on held-out cases to reproduce the opaque model's decisions and drivers, and otherwise the interpretable model must be the decider.
2. Adverse or borderline outcomes go to a trained human reviewer (human-in-the-loop: a person checks or makes the final call) with the reasons shown. The human can overrule and the person can contest.
3. Launch to a small share of traffic, first in shadow mode (the model scores but humans still decide), then live with monitoring of approval rates by group and of reason-code drift.
4. Documentation: model card (a short record of the model's purpose, data, limits and test results), reason-code mapping approved by compliance, and a written record of what was shipped and why.

Worked example

A lender's scorecard starts every applicant at 700 points and the approval cut-off is 620 (illustrative numbers). This applicant has 92% credit utilisation (share of available credit in use), minus 60 points; a 14-month credit history, minus 45; stable income, plus 10; one recent inquiry, 0. Total: 700 - 60 - 45 + 10 = 605, below 620, so the application is declined. Reason codes are the largest negative contributions, in order: "credit utilisation is high" (-60) and "credit history is short" (-45). The letter states those two. For a complex model, the attribution method produces the same kind of per-input contributions, which is why they must be tested for faithfulness. The reviewer checks the case before the letter goes out.

What would change my call

If the regulator or counsel says the explanation method is not acceptable for this product, I delay. If explanations are only recommended and the harm is reversible, I ship advisory-only sooner. Sign-off: compliance and counsel on the explanation approach, the product owner on residual risk.

Direct answer. I would negotiate by finding the real product goal behind "face images", offering designs that deliver it without collecting raw faces on our servers, and requiring a data protection impact assessment before any collection. If leadership insists on raw collection, I escalate in writing and set non-negotiable conditions; I would not ship an unlawful design, and counsel decides what is lawful.

What the rules say. Article 9 is the natural starting point for this question. Under GDPR Article 9, "biometric data for the purpose of uniquely identifying a natural person" is special category data (a sensitive class such as health, biometrics or beliefs that gets stricter treatment), which is prohibited unless an exception applies, such as explicit consent (Article 9(2)(a)): a specific, separate, clearly worded yes for this purpose. Silence, pre-ticked boxes and inactivity never count as consent (Recital 32), and a consent request must be clearly distinguishable from other terms (Article 7(2)), so bundling it into general terms fails; explicit consent additionally needs an express statement, such as a clicked or typed agreement to this named use. Counsel also confirms the lawful basis (the legal ground the GDPR requires for any processing). Whether a given face image counts as biometric depends on what is done with it; if we create face templates (numeric descriptions of facial geometry used to match one face to another) to recognise people, it likely does. Recital 51 says photographs are biometric data only when processed through specific technical means allowing the unique identification or authentication of a person. That is a question for counsel. Article 25(2) requires that by default only necessary data is processed, and Article 35(3)(b) requires a DPIA (data protection impact assessment, a structured risk review done before processing starts; the Article 35(7) content is a description of the processing and its purposes, necessity, risks, and safeguards) for large-scale processing of special category data.

Negotiation steps

1. Ask what outcome they want. Avatars? Try-on? Mood-based content? Each can often be done without storing faces.
2. Offer alternatives, from least to most intrusive
   • User-selected avatars or preferences instead of inferring from a face (no face data at all).
   • Do the processing on the device and send only a non-identifying result (for example a chosen style), never the image.
   • Transient processing: image used in memory, not stored, no template created.
   • If storage is necessary: explicit opt-in consent, short retention, encryption with separate key management (the keys held in a different system and by different people than the data), deletion on request, and no use for other purposes (purpose limitation, Article 5(1)(b): data collected for one purpose is not reused for another).
3. Do the DPIA and bring the results into the roadmap conversation.
4. Phased pilot. A small opt-in group, measured benefit, then scale only if the DPIA and metrics hold.

If leadership insists on raw collection. Put the risks and options in writing to the executive sponsor and counsel. Required conditions before launch: completed DPIA (with prior consultation of the regulator, meaning asking the supervisory authority for its view before launch, if residual risk stays high, as Article 36 provides), valid explicit consent, retention limit, access controls and a kill switch. An executive signs the risk acceptance. If counsel says a design would be unlawful, I do not implement it.

A related case: social-graph data. A social graph is the map of who connects to whom in a product, such as friends or followers. If product asked to use it for personalization, legal's concern would be inference of sensitive attributes (for example health or beliefs) from who connects to whom. Same approach: define allowed uses, ban inferring sensitive categories, run a phased pilot with a review gate before scale.

What would change my call. A product need that truly requires identification, with a clear lawful basis.

Position: I would not pick a winner between "aggressive" and "strict". I would turn the argument into a measured choice, then propose a tiered design that keeps most of the revenue and removes the riskiest data.

Terms. Profiling means automatically using personal data to predict or sort people (here, what each shopper will buy). A cohort is a group of users sharing traits. A proxy is an innocent-looking field that stands in for a sensitive one (a postcode can hint at ethnicity). The DPO (Data Protection Officer) is the person who advises the company on privacy law and is not allowed to be the one who decides the business risk.

1. Split the data by purpose and risk (data minimization means collecting only what a stated purpose needs; GDPR Art 5(1)(c) says "adequate, relevant and limited to what is necessary")

• Tier A: first-party behaviour on our own product (views, purchases). Low risk, and often much of the uplift (the test in step 3 checks this).
• Tier B: granular cohorts and cross-site or purchased data. Re-identification risk: a cohort of "women aged 30-34 in one postcode who bought X" can shrink to a handful of people. Set a minimum cohort size (illustrative floor: 50 users) and aggregate below it.
• Tier C: sensitive attributes or proxies (health, religion, sexual orientation, ethnicity; Art 9 lists these). A broad model that uses them or infers them needs explicit consent (or another Art 9(2) condition, which rarely fits marketing), so I would exclude them by default.

2. Legal permissibility, ethics, expectation (counsel decides the legal call)

• Consent (Art 6(1)(a)) or legitimate interests (Art 6(1)(f), the company's own business interest as a legal basis, which does not apply when the user's rights outweigh it). Under Art 21, a user can object to profiling for direct marketing at any time and then it must stop.
• Targeted advertising in stricter markets: assume opt-in consent. Ask "would a user be surprised?" If yes, treat it as a red flag even where it is arguably lawful.
• Privacy-safe alternatives: contextual targeting, on-device models, aggregate or cohort signals, first-party data only.

3. Quantify the benefit, not the fear. Run an A/B test: the minimal-data model vs the rich-data model. With 500,000 users per arm and a 2.0% baseline conversion, differences under about 0.055 percentage points are within chance (computed below), so a "win" smaller than that proves nothing.

standard error of the gap = sqrt(2 x p x (1-p) / n)
                          = sqrt(2 x 0.02 x 0.98 / 500,000) = 0.000280 = 0.028 points
95% threshold             = 1.96 x 0.028 = 0.055 points

Intuition: with this many users, random luck alone moves the gap by about 0.03 points either way, and the 95% rule asks for about twice that before calling a difference real. To detect a real effect reliably (80% power, meaning an 80% chance of catching it if it exists), the gap needs to be about 0.078 points (2.8 x 0.028).

Fines and other costs. Statutory fines are ceilings, not expected cost: for a company with 800M turnover the Art 83(5) ceiling is 32M (4% of 800M, higher than 20M). Use them to show severity, but the stronger argument is the cost of a stop-processing order (a regulator instructing the company to halt the processing, which would switch off the personalization model) and retraining the model.

4. Landing position: ship Tier A now, Tier B with cohort floors and a DPIA (data protection impact assessment, automatically required under Art 35(3)(a) where profiling is systematic and extensive AND the decisions based on it have legal or similarly significant effects on people; ordinary product recommendations may fall short of that wording, but Art 35(1) requires an assessment for any processing likely to be high risk, and large-scale behavioural profiling with purchased data often is, so I would run one anyway), Tier C off. The DPO advises, the product owner accepts the remaining risk in writing, legal confirms permissibility. The GDPR articles matter in this order: 5(1)(c) minimization and 6 lawful basis first, then 35 DPIA, with 9 and 21 as hard limits and 83 as severity context.

What flips my call: the test shows Tier C adds large lift AND users give explicit consent AND counsel agrees; then I would revisit with extra safeguards.

Direct answer. I decide by separating the tests into what each one protects against, size the risk of skipping each, and counter with a faster path that keeps the checks that matter most. I would not say a flat no. I also would not agree silently; if the business still wants to skip after seeing the options, the owner signs the acceptance.

Step 1: What is being skipped? "Security tests" bundles different things: static analysis (SAST, scanning source code for flaws), dependency scanning (checking libraries against known vulnerabilities), dynamic testing (DAST, attacking the running app), and validation tests such as authorization checks. They do not carry equal risk.

Step 2: Size the risk (illustrative numbers).

• What changed in this release: a copy change carries much less risk than a new payment or permission path.
• Exposure: internet-facing, number of users, data touched.
• Simple expected-loss sizing: probability times impact. Illustrative: if I judge a 5% chance that an exploitable flaw is present, a 30% chance it is found and exploited in the exposure window, and a $400,000 impact, the expected loss is 0.05 x 0.30 x 400,000 = $6,000. These inputs are judgement, so I show the range and compare with the cost of delay rather than treating $6,000 as a fact.
• Comparison (illustrative): if a one-week slip costs about $15,000 in lost sales and team time, the $6,000 expected loss alone would favour shipping, but expected value hides the tail: a 1-in-67 chance (0.05 x 0.30 = 1.5%) of a $400,000 loss is the exposure the owner is accepting, which is why the counter-offer keeps the cheap checks and the rollback rather than skipping everything. A release that touches authentication changes the numbers sharply; I would not skip there.

Step 3: Counter-offer.

• Run the fast, high-value checks in the pipeline (dependency scan, SAST on changed files, authorization tests on touched endpoints).
• Defer the slow checks (full DAST scan) but run them against production-like staging immediately after release, with a rollback ready.
• Reduce exposure: feature flag the new functionality, or release to a small share of users first (a canary release) and widen if monitoring is quiet.
• Add compensating controls (a control that lowers risk when the ideal check is skipped): extra alerting and a short-lived rollback plan.

Conditions to accept versus postpone (customer demanding the skip for a market window). Accept only if the change is low risk, a compensating control is in place, and the skipped checks are scheduled with a date. Postpone if the change touches authentication, payments or personal data, or if no safe rollback exists. A customer's urgency is a business input, but it does not change the technical risk; the decision-maker signs.

Who signs. Product owner accepts the residual risk in writing; security records it with a follow-up date.