ROT Data Belongs on Your Risk Register. Here’s How to Get It Off.

Every enterprise I talk to has run a ROT (redundant, obsolete, trivial) cleanup project. Most of them ran it more than once. A central team gets a mandate, turns on a scanning tool, produces a report showing terabytes if not petabytes of redundant, obsolete, and trivial data, and then the project stalls. Nobody deletes anything. The report goes into a SharePoint folder, which, ironically, becomes ROT data itself.
When I ask what went wrong, the answer is almost never the tool. The scan worked. The duplicates were real. The stale data was stale. What failed was everything around the tool. Nobody agreed on what ROT meant for their business. Nobody knew who owned the data. Nobody had a process for saying yes, and legal had every reason to say no.
Identifying ROT data is a technology problem. Remediating it is a people and process problem. Finding duplicates and stale files is easily solvable. Getting the right owner to make the right decision on the right file, at enterprise scale, with an audit trail that holds up when legal asks why something was removed, is not.
Why ROT Data Matters More Now
ROT data has existed for as long as data itself. So why should organizations go the extra mile to remediate it now? Because it is no longer just a storage cost problem. Storage is cheap. The risk that comes with ROT data is not.
Attackers have figured out that stealing data pays as well as encrypting it. According to Coveware by Veeam, 97% of ransomware attacks involved data exfiltration. SaaS platforms are a favorite target. ShinyHunters is a good example: their model is theft and extortion, not encryption, and the FBI says the group and its associates breached more than 140 organizations and collected at least $70 million in extortion payments.
Here is the part that matters for ROT. You can't leak data you don't have. Every stale file that still holds an SSN, a contract, or a customer record is a potential breach notification letter. None of that data is doing anything for the business. All of it adds to your blast radius.
If you're a CISO, ROT is breach scope, not storage. It belongs on your risk register, not just governance's to-do list.
And now it is also a file an AI agent can read. Agents inherit the permissions of the identities they run as. They do not know a document was superseded four times. They summarize it and hand it back to a user as if it were current. If you are serious about safe AI adoption, ROT reduction moves from hygiene to a prerequisite.
Why Cleanup Projects Fail
The typical pattern. Sound familiar?
A central security or governance team runs a scan and finds a massive amount of ROT.
The team has the technical ability to remove it but not the authority. They do not know whether that 2018 contract folder is under legal hold or whether finance needs those exports for next quarter's audit.
The team sends a spreadsheet to the business asking for review. It has 400,000 rows. Nobody opens it.
The project gets deprioritized. The data keeps growing.
Step 1 is technology, and that part is relatively easy. Steps 2 through 4 are people and process, and that is where it breaks.
The data security industry is rightly talking about closing the gap from discovery to remediation, because visibility does not automatically turn into action. But the usual prescription is a better console. For ROT, the console is not the bottleneck. A central team with a perfect console is still a central team acting on data it does not own. The bottleneck is ownership, authority, and process.
Do not start a ROT program by turning on a scan. Start it by answering three questions.
Who decides what we can purge?
What are the variables needed to help them decide?
How does the decision get executed in a compliant, safe, and repeatable way?
The first is people. The second and third are process. Once you can answer them, technology is how you scale the answers.
People: Who Decides
The people best positioned to decide what to keep are the ones closest to the data. In a large enterprise, those people are spread across many stakeholders. The data owner makes the call. Legal and records management set the boundaries. System administrators execute final disposition under retention policies the business already trusts.
Here is how I would draw the RACI matrix. R is responsible (does the work), A is accountable (owns the outcome, one per row), C is consulted, I is informed.

The sponsor is a data governance or security leader who is graded on the outcome. If nobody's goals include ROT reduction, then the project never gets past identifying the stale data.
The data owner is accountable for the decision, not the platform team. Owners get only their slice, so a 400,000-row spreadsheet becomes 40 files in someone's queue.
Legal and records are consulted on the definition. Bring them in on day one and they become your strongest ally. Wait until you are sitting in a deposition and they become your biggest problem.
Orphaned data needs a named owner too. Some data will not map cleanly to anyone. The sponsor is accountable for it and should name a governance steward to work the queue. Otherwise it quietly becomes the largest pile of ROT you have.
Process: The Variables, Then the Workflow
People without a process just produce opinions. The process is what turns individual decisions into a program you can repeat, measure, and defend in an audit. It has two parts: the variables an owner decides against, and the workflow that executes the decision.
The Variables: What an Owner Needs to Decide
Nobody can make a good keep-or-purge decision from a file name. Give owners these signals for every item in their queue. Notice that some come from the platform and some can only come from people.
Variable | Why it matters | Where it comes from |
Age | The simplest signal that data has outlived its purpose. | File modified time, from discovery scans |
Duplicate status | If an identical copy exists elsewhere, removing this one carries little risk. | Checksum and near-duplicate detection |
Sensitive data | Stale data with SSNs, financial, or health data is breach scope. Prioritize it. | Data classification |
Exposure | Data shared externally or open to the entire org has a bigger blast radius. | Sharing and permission analysis |
AI agent access | Stale data an agent can read can show up in answers users trust. | Agent and identity access mapping |
Owner | No owner, no decision. | Owner tags and file ownership |
Legal hold | Data under hold cannot be touched, period. | Legal and records team |
Retention obligation | Some old data must be kept by regulation or contract. | Records retention schedule |
The last two rows are the ones that kill projects when they are skipped. No scanner knows about the litigation your general counsel learned about last week. That is why legal is in the RACI.
The Workflow: How the Decision Gets Executed
Stage | What happens | Why it matters |
1. Define | Write down what ROT means for your business, by data type, age, and location. | Owners can only make consistent decisions against a consistent standard. |
2. Assign | Map every piece of data to an owner using stable business attributes. | No owner means no decision. |
3. Route | Deliver each owner only their items, in the tools they already use. | Work that lands in a new portal gets ignored. Work that lands in a ticket queue gets done. |
4. Review and stage | Owners decide. Approved items move to quarantine, not to the trash, with a full audit trail. | Reversibility is what gets legal and the business to say yes. |
5. Dispose and measure | Existing retention policies perform the irreversible delete. Progress is reported on a set cadence. | The riskiest step stays inside controls you already trust. |
Two points cause confusion:
Quarantine is not deletion. Moving data to a staging location, with a placeholder left behind, gives everyone a safety net. If an owner gets it wrong, it comes back. That single choice turns a terrifying decision into a low-risk one, and low-risk decisions actually get made.
Routing is open loop. A ticket tells the owner there is work and links them to it. It does not take action on its own. A human still decides. For most large enterprises, I recommend starting with a human in the loop and earning your way to automation as trust builds.
Notice that none of this depends on a specific product. If your program cannot answer "who owns this" and "what is our definition of ROT" on a whiteboard, no tool will save it.
Technology: Encoding the People and the Process
Now the technology. The platform's job is not to make decisions. It is to encode your definitions, your ownership model, and your review process into policy so they run at scale without a central team babysitting them.
I'll show this in the Veeam DataAI Command Platform because it's what I work in every day, but the pattern applies whatever tooling you use.
Step 1: Turn Your ROT Definition Into Policy
The platform ships with system-defined policies for duplicate files and for age-based retention tiers at one, three, five, and seven years. Start here to size the problem before you write anything custom. Exact duplicates are identified by a checksum calculated for each file during the discovery scan. Identical checksums mean identical content, regardless of file name or location. Near duplicates are detected by comparing the first 3,000 characters of a file's parsed text. Enable cluster analysis in the discovery scan configuration, and it takes effect after the next scan.

The defaults are a baseline. Your written ROT definition from the process stage becomes custom policies. Every policy scope is a graph query, so you can combine file properties, data system properties, and relationships. That is what lets you turn the variables table above into policy.
Step 2: Hunt the Toxic Combinations
ROT on its own is a cost problem. ROT combined with sensitive data, broad exposure, or AI agent access is a risk problem. Those toxic combinations are where to start, because they are what your sponsor cares about and what a CISO will fund.
The first one is simple: stale files that contain SSNs. Below is a query for every file older than one year with a US Social Security number in it. In my lab tenant it returned 884 files. That is data nobody considered critical enough to act on, sitting next to the most regulated data element there is.

ROT policies identify. Quarantine policies act.

The second combination is the one I want to highlight: Archive ROT Data AI Agents Have Access To. The scope finds files in OneDrive not modified in more than a year, on a scanned data system, that are readable by an AI agent.

Stale data an agent can reach can end up in an answer a user trusts. It is the easiest risk to explain and the fastest win to show, and early wins are what keep a program's people engaged.
When quarantine runs, you can leave a placeholder file behind that tells users where their file went and who to contact. It is a people feature disguised as a technical setting, and it heads off most of the help desk noise that kills ROT programs in the first month.
Step 3: Give Owners a Place to Decide, With a Record of Every Decision
Every file a ROT or quarantine policy touches shows up in Data Remediation. This is where owners and stewards review their items, see processing status, and track what has been quarantined or reverted.

This screen is where the "review and stage" process lives. It captures what an auditor will ask about: which policy acted on the file, the original and destination paths, the owner, and a full history per item. Mistakes can be reverted, and the reversal is tracked too. When legal asks why a file was removed, the answer is already recorded.
Step 4: Route Work to Owners Where They Already Work
This is where the RACI becomes real. Under Automation, you create policies that take ROT findings, group them by owner, and send each owner only their slice. The action can be an email directly to the owner or a ticket in ServiceNow or Jira.

The platform creates one ticket per grouping, assigns it to the owner, and includes a direct link back to their remediation items. The owner works the ticket in a tool they already use, clicks through, and decides in the workbench. No new portal to learn, which is a people decision as much as a technical one.
Step 5: Let Your Retention Policies Do the Final Delete
The platform quarantines. It does not perform the irreversible delete. Final disposition runs through the end-of-life and retention policies on the source system, executed by the administrators who already own that process.
This is a feature, not a gap. The most consequential step stays inside controls your records and legal teams already approved, which is also why this approach gets through a change advisory board far more easily than a tool that deletes on its own.
Running It as a Program, Not a Project
Here is the rollout I recommend. Notice how many of these steps happen before or outside the console.
Name the people. Sponsor, platform admin, governance steward, legal and records contact. Fill in the RACI with names before anything else.
Write the definition. Agree with legal and the business on what counts as ROT for your first data system. Keep it short enough to fit on one page.
Start in review mode on one system. Run the system-defined policies, size the opportunity, and quarantine nothing yet.
Model ownership before you route. If you cannot answer "who owns this data" with a policy, you are not ready to send tickets.
Lead with the toxic combinations. Stale sensitive data and stale data AI agents can reach. Show an early, explainable win.
Set a cadence. Nobody wants 400 tickets on a Monday. Batch by owner on a predictable schedule so review becomes routine instead of an event.
Measure and publish quarterly. Track these five metrics:
Metric | What it tells you |
Ownership coverage | The percentage of data with an assigned owner. The foundation for everything else. |
ROT identified | The volume of redundant and obsolete data flagged for review. |
ROT reclaimed | The volume quarantined and permanently removed through your retention process. |
Owner responsiveness | How quickly owners act on assigned work. |
Footprint trend | Whether your total ROT is going down over time. |
Closing Thoughts
The organizations that win at ROT reduction will not be the ones with the biggest scan results. Anyone can produce a big number. They will be the ones that decided who owns the decision, gave those people a clear standard to decide against, and made each decision safe, reversible, and recorded.
Technology makes that possible at scale. It does not make it happen. People and process do. Do that, and ROT stops being a project you run every two years. It becomes something your organization just does. And in a world where attackers steal everything they can reach and AI agents read everything they can reach, that discipline is not optional anymore.




Comments