Sales says your data-loss block stops legitimate customer exports daily - do you demote the policy to monitor?

## The question underneath the question A block that stops legitimate work every day looks like a tuning problem and usually is not one. The first move is to classify the hits, because three different things wear the same badge in the console. - **False positives.** The rule was wrong about the content - a pattern matched order identifiers, or a fingerprint matched template boilerplate shared by every document built from the indexed source. Demoting to monitor does not fix this; it merely moves a wrong rule somewhere quieter, where it will produce the same wrong verdicts and nobody will notice. - **Benign true positives.** The content genuinely is the sensitive class and the movement genuinely is authorised - marketing sending a segmented customer list to the agency that has a contract to process it, or a data engineer exporting 2.1 million rows nightly under a signed migration. The rule is right and the behaviour is fine. This is not a detection defect; it is a mismatch between where the control sits and how the business legitimately operates. - **Real violations**, currently buried in the volume of the other two. Only the second category argues for loosening, and it argues for it honestly. ## Why loosening can be the right answer Two arguments carry weight with an executive, and neither is *the analysts are tired*. **People route around a block.** The employee stopped mid-deadline does not abandon the task; they find a path you cannot see. A photo of the screen, a personal webmail tab on a personal phone, a document retyped into a note. A block that is routinely wrong therefore does not merely cost goodwill - it actively **reduces visibility**, pushing activity from a channel you instrument onto channels you do not. Monitor mode on a channel you can see can genuinely beat prevention on a channel people have abandoned. **A control the business fights gets switched off eventually, and worse.** The choice is rarely block versus monitor; it is a considered demotion with conditions versus an emergency exemption granted under pressure at the end of a quarter. ## The settings between block and monitor An experienced answer does not treat this as binary. - **Split by destination.** Keep the block where the risk actually is - movement into personal accounts and unsanctioned services - and monitor movement into destinations the company controls. Most of the daily pain usually lives on the sanctioned side. - **Block with justification.** The user is stopped, must type a business reason, and may proceed. Friction is preserved, prevention is preserved for anyone unwilling to put their name to a reason, and the analyst gets a human sentence on the incident instead of a guess. Repeated overrides by one person become a signal in their own right. - **Change the action rather than the verdict.** On the mail path, forcing encryption or adding an approver keeps the data flowing while changing who can read it. ## If you do demote, what you demand in return Monitor mode is telemetry, not a control. Saying so plainly is the point of the whole conversation. 1. **A named accepting owner.** The residual risk belongs to whoever owns the data - the business or data owner - not to the security team, and certainly not to the analyst who closed the incidents. Record who accepted it, what they accepted, and when it is reviewed. 2. **Cumulative visibility.** Per-event thresholds are exactly what a patient actor stays under: forty records a day, every day, trips nothing and adds up to the whole customer base in a year. Ask for an aggregate view per user over weeks, not a bigger single-event rule. 3. **Retention that outlives the discovery.** If nobody will look at monitor events for months, retain them for months. Monitor events you cannot go back and read give you the illusion of coverage. 4. **A measurement and a date.** After the change, what fraction of hits are still benign, and did anything real appear? Bring that number back, because it is the only way anyone learns whether the demotion was right. ## The scoped-exception distinction One identified, time-bounded activity with a named owner - the signed migration exporting millions of rows for six weeks - is a different decision from permanently changing the posture of a policy for everybody. Handle a known project as a specific arrangement that ends when the project does; reserve a genuine mode change for the case where the *ordinary* daily work of a department is what the control is fighting. ## What you will be asked afterwards If data leaves through the loosened policy next quarter, the questions are: who decided, what did they know, what did you put in place instead, and did you check. A decision you can produce, with a named accepter, a compensating monitoring, a review date and a measurement, is a defensible engineering call. The same demotion made informally by the SOC to clear its queue is the finding.