Defending a do-not-fix: every support agent can read any customer account and you propose logging over redesign - how do you make that case to a privacy officer?

## Get the vocabulary straight first Four words get conflated in this conversation, and a privacy officer will notice if you conflate them. - **Threat** - what could go wrong: a support agent, or someone who has taken over an agent's session, reads the personal data of customers they have no business reason to touch. - **Vulnerability** - the flaw that permits it: the console authorises on role alone, so any authenticated agent can retrieve any account. - **Risk** - the rated consequence: the likelihood of that happening times what it costs in regulatory exposure, customer harm and trust. - **Control** - what you do about it. Logging is a **detective** control: it records and attributes after the fact and deters people who know they are recorded. Scoping access to the open case is a **preventive** control: the capability stops existing. The entire defence turns on saying which of those two you are proposing and refusing to blur it. A candidate who says "we mitigated it with logging" without that distinction has already lost the officer, because the officer's job is to know the difference. ## What the compensating control legitimately changes Detective controls do move risk, and it is worth being specific about how, so the argument does not sound like hand-waving. - **Time to detect** falls from never to one review cycle - or to minutes, if an alert fires on out-of-case bulk access. - **Attribution** becomes possible: a specific account, at a specific time, against a specific customer, with a stated reason. - **Deterrence** rises for the ordinary case - a curious agent looking up a celebrity or an ex-partner - because the lookup is visibly attributable. - **Blast radius stays exactly the same.** A determined insider, or an attacker who has phished an agent's credentials, can still read every account. You get to know about it afterwards. Say that last point out loud, before the officer says it for you. Volunteering the limit of your own proposal is what makes the rest of the briefing credible. ## The evidence standard An officer cannot verify an assurance; they can verify evidence. Bring: - **Coverage** - the list of access paths to this data, and which ones write a log. If a maintenance query path, a reporting export or a direct database route bypasses the logging, the officer will find it eventually, and finding it themselves is what turns a reasonable decision into a credibility problem. - **The review that actually happens** - who reads the reports, on what cadence, what an anomaly triggers, and whether the review has ever produced an action. A quarterly attestation nobody performs is not a control; it is a claim. - **Retention** long enough to be useful: logs that age out before the review cycle detect nothing. - **The declined option, priced** - what scoping access to the open case actually costs in engineering time and lead time, and what it would break in the support workflow. If the redesign is two quarters and cross-team, say so; the officer is entitled to weigh that. ## Framing it as their decision The most common way this conversation fails is tone. A do-not-fix presented as already decided reads as security telling privacy what the privacy risk is, in privacy's own domain. Present it as an option set: prevent now at this cost, prevent later on this date with this interim narrowing, or accept with this detection in place and this residual exposure. Then let them choose and co-sign. **Offer an interim narrowing** so the choice is not binary. Masking sensitive fields until a case is opened, blocking bulk export outright, requiring a typed reason on any out-of-case lookup, and rate-limiting lookups per agent are all cheap, and each one shrinks the residual without waiting for the full redesign. And give the decision an end. Name the triggers that reopen it: a coverage gap you cannot close, evidence the review is not being performed, a growth in the number of agents, a new data category landing in the console, or a new contractual commitment. Without triggers, an accepted risk becomes permanent by default, and the officer knows it. ## When acceptance is not on the table Sometimes the answer is not a better argument. If a regulation, a data-processing commitment or a signed customer contract already requires access to be scoped or minimised, the organisation has already decided, and no internal sign-off overrides it. Recognising that **before** the meeting is the senior move: you arrive with a dated remediation plan plus interim narrowing, not with a case for accepting. Spending the meeting defending an acceptance you were never entitled to offer costs you the relationship you will need for the next twenty models. ## The arguments that collapse - "No support agent would ever do that." This rates the threat on assumed motive rather than capability, and it gives the officer nothing to verify. Capability is checkable; character is not. - "It is all logged" - when three access paths are not. - "We reviewed the logs" - when nobody has opened the report since it was built. - Presenting the residual as zero. It is not zero; it is bounded and detected, which is a defensible thing to say and a very different thing to claim.