There is a CISO who has finally won the internal argument: data hygiene cannot live inside the security team alone. The owners of the data, the people who created the file, shared the link, or named the SharePoint site, are the only ones who hold the business context to decide what should stay, move, or go. They have to be in the loop, and the CISO is right to insist on it.
So the project lands on IT’s desk, and IT does what IT has always done with cross-functional workflows: it reaches for the ticketing system. ServiceNow, Jira, or whatever ITSM platform is already wired into the tenant. The DLP flags a risky file, a ticket is opened, the data owner is assigned, a form is filled, the case is closed. On paper, it looks like a clean process. In practice, it quickly turns into a graveyard.
The decisions only the data owner can make
Three categories of decision sit at the heart of any data hygiene program. All three require context that lives only with the person who created or still uses the data. None of them can be answered by IT, security, or legal without going back to the source.
Access review
The SharePoint site spun up three years ago for a now-completed project still carries fifteen people on its permissions list, several of whom have changed roles or left the company. Neither IT nor security can tell which of them still has a legitimate business reason to be there. Only the original owner can answer that question, and at the scale of a typical tenant, there are thousands of permission lists no one is reviewing on any meaningful cadence.
Share revocation
This is the quietest crisis in most M365 tenants. “Anyone with the link” shares accumulate by the thousands, external links to vendors, partners, and former employees never get pulled back, and a mid-size organization will routinely sit on tens of thousands of active external sharing links. Each one is an attack surface. And the only person who can say whether a share is still needed is the one who created it.
Archiving and end-of-life
Files untouched for five years are still indexed, still discoverable, and still part of every legal hold and every breach blast radius. Legal will not authorize bulk deletion without context, IT will not move data into cold storage without owner consent, so the files stay where they are while storage costs and exposure both keep climbing. The decision is trivial at the file level and paralyzing in aggregate, which is exactly why it never gets made. Multiplied across millions of files and tens of thousands of shares, this is the workload that needs to be distributed.
The question is whether ticketing is the right mechanism to distribute it. It is not, and here is why.
Why ticketing fails at this job
Ticketing pulls users out of their work and routes them into a separate portal, where they authenticate again, parse a description written by someone in security, and fill in a form before the case can close. Every step is friction and a reason to push the task to next week, then next month, then never. A well-designed nudge does the opposite: it meets users inside Teams or Outlook, tied to a specific file or share they actually remember creating, and asks for a single clear decision. No portal. No context switch. No translation from policy jargon into business reality. Attention is the scarce resource here, and ticketing burns through it.
The scale problem is immediate. A single DLP and access scan on a mid-size tenant will routinely surface millions of files and tens of thousands of external shares. If each one becomes a ticket, you are not running a hygiene program: you are running a denial-of-service attack against your own service desk. Every ticket is a packet of IT labor: triaged, routed, reminded, escalated, tracked against an SLA. At thirty seconds per ticket, fifty thousand tickets is roughly a quarter of a full-time year of overhead, before a single share has been revoked. Nudging routes the work directly to the person closest to the data. IT sees the dashboard. The trend lines. Risk reducing week over week. Ticketing makes IT the bottleneck. Nudging makes IT the conductor.
There is also the engagement question, which is not a soft metric. Users tolerate ticketing systems. Compliance happens when someone follows up three times, not because the data owner felt any stake in the outcome. A nudge treats the data owner as a partner who holds the context, not a respondent clearing another obligation from their inbox. That difference is the gap between a program that produces measurable risk reduction and one that produces a quarterly report nobody trusts.
The real question
The CISO who insisted on shared responsibility was right. The follow-up question (the one that determines whether the program survives contact with reality) is whether the toolchain actually matches that ambition.
You can route the work through a system designed for IT tasks, run by IT, escalated to IT, and closed by IT. Or you can route it through the layer where users already work every day, on a cadence they can absorb, in a format they will not resent receiving.
