By Yair Knijn · June 25, 2025

The service-desk manager whose filter rollout generated 300 tickets a day and a queue of silent overrides

He turned the filter on for roughly 1,400 endpoints over a weekend and walked into a ticket queue Monday that had quadrupled. His rollout plan covered security and deployment. It said nothing about what actually consumed his team that week: people who could no longer reach a site they needed, and a desk with no fast way to fix it.

False positives are not an edge case the techs mop up between real work. They are the steady state of category-based filtering. What decides whether a rollout survives is not how few you get, but how the desk resolves each one.

Why aggressive category blocking floods the service desk

Category engines classify domains by host, path, and content signals, and at the margins they get it wrong. The textbook case is a substring match firing on a clean domain because cunt sits inside Scunthorpe. Multiply that across a marketing team's design references, finance's regional bank portals, and engineering's package mirrors, and a fresh strict profile produces hundreds of "I can't reach X" tickets in week one.

None of those are security incidents. They land in the same queue as password resets and printer faults, picked up by a tech with thirty seconds and forty more tickets queued.

The 'just whitelist it' anti-pattern and the holes it leaves

Under that load, the fastest move wins: drop the domain into an allow list and close the ticket. No second reviewer, no reason recorded, no expiry. The user is unblocked, the queue ticks down by one, and a hole opens in the policy that nobody can see.

Three weeks in, the global allow list held close to 280 entries. Some were wildcards a tech had widened to silence a repeat caller. At least one was a file-sharing domain a user had talked their way past. He could not say who added what, or whether it was still needed, because the override was the record, and the record said nothing.

A review queue that is fast for users and auditable for you

The fix is not stricter techs. It is a false-positive path faster than the ad-hoc whitelist, so the governed route becomes the lazy route. A user who hits a block sees a request form on the block page itself, carrying the blocked URL, the category that fired, the requester, and the timestamp with nothing retyped. Microsoft's own Global Secure Access guidance agrees: route exceptions through self-service requests, not hand-edited allow lists.

• The form pre-fills URL, category, requester, and time, so the reviewer judges rather than investigates.
• Each exception carries an expiry, so a one-off unblock does not harden into policy.
• Approvals are scoped to a group, so unblocking one team's tool does not open it for all 1,400 endpoints.

Turning every override into evidence, not a private favor

Run the exception through a queue and you keep an audit trail: who requested, who approved, against which category, for how long. That is what an ISO 27001 control review or a NIS2 access-governance check expects you to produce, and what a pile of hand-edited allow-list lines can never reconstruct.

Measuring false-positive rate as a rollout health metric

Track exception requests per hundred users per week and watch the slope. High but falling means the policy is tuning toward your environment. Flat and high means a category is miscalibrated for a whole group, so split the profile rather than approve the same domain forty times. Near zero in week one is not a win; it usually means users stopped reporting, which is how quiet workarounds start.

ClearScreen puts the request form on the block page and routes every false positive into a review queue with an expiry and an approver, scoped per policy group so one tenant's exception never leaks to another. The override becomes evidence, not a hole in your allow list. See how the review path works on the features page.