Someone in legal asks for a contract from 2017. It takes three people two days to find it, because it lives in four places: the deal folder, an email attachment, a former employee's synced laptop, and a personal drive that nobody on the current team knew existed.
The contract was supposed to be gone two years ago. The retention schedule says so. The schedule is a PDF on the intranet.
That is the normal state of file retention. Policy says one thing and files say another. But every file that outlives its purpose is one more thing a stolen login can open.
This post is about closing that gap: how to write a data retention policy that works on files, how to decide what to keep, retire, or delete, and what to do about the copies you will never find.
Why a Data Retention Policy Matters for Files, Not Just Records
Most retention programs were designed for records: the invoice, the personnel file, the signed agreement. Records live in systems that can apply a schedule, flag an expiry date, and delete on command.
Files do not behave that way. A file gets created in one place, attached to an email in another, synced to a laptop, shared with a contractor, and pasted into an AI tool. By the time the retention window closes, the original is one of many copies, and the retention system only knows about one of them.
Two facts make this matter more now than it did ten years ago.
First, volume. Gartner estimates that 70 to 90 percent of organizational data is unstructured, and that it grows 40 to 60 percent a year. That is mostly files. It is also the data retention schedules cover least well.
Second, exposure. Your blast radius is not a choice you made. It is an architecture you inherited, and it includes every file you kept longer than you needed. According to the 2026 IBM Cost of a Data Breach Report, the global average cost of a data breach has reached a record $4.99 million, with a mean identification and containment window of 247 days. A breach that exposes ten years of files costs more to scope, to notify, and to explain than one that exposes two.
Keeping less is a security control. It is also the cheapest one on this list.
Files You Should Have Deleted Are Still Open to Anyone With Access
Retention policy decides what you keep. Per-file protection decides who can open what you cannot delete. See how it works on your own old files in a two-week pilot.
What Retention Rules Require
Retention rules do two opposite things. Some require you to keep data. Others require you not to keep it too long. A workable policy has to satisfy both.
Rules that require keeping: HIPAA's Security Rule requires covered entities and business associates to retain required documentation, including policies, procedures, and risk assessments, for six years from creation or last effective date, whichever is later (45 CFR 164.316(b)(2)). Federal contractors generally must make contract records available for three years after final payment, or longer where a contract clause or specific provision requires it (FAR 4.703). Industry and state rules add more.
Rules that limit retention: Privacy law often points the other way. Under the GDPR's storage limitation principle, personal data should be kept no longer than necessary for its purpose (Article 5(1)(e)). The rule does not name a number of years. It asks you to define a period, justify it, and enforce it. We mention it here as regulatory context only. It illustrates the broader principle that retention without an end date is a liability, not a safeguard.
What neither tells you: None of these rules says where the copies are, how to find them, or what protects them while you keep them. That part is yours.
A caution: retention periods are legal decisions. Your counsel sets them. This post is about turning a schedule into something your file environment can follow, not about choosing the schedule.
Keep, Retire, Delete: A Three-State Model
A retention schedule usually has two states: keep and delete. Files need a third, because the gap between "required to keep" and "safe to delete" is where most of them sit.
| State | What it means | What to do with the file |
|---|---|---|
| Keep | Still needed for business, legal, or regulatory reasons | Protect it according to its sensitivity tier |
| Retire | No longer actively used, but not yet cleared for deletion (a legal hold, a pending audit, an unresolved question) | Restrict access to as few people as possible, ideally one named custodian or no one |
| Delete | Past retention, cleared by legal, no hold | Remove the file, and remove the copies you can find |
The middle state is the one that changes your risk. A file in "retire" is not gone, so the policy has not failed. It is just no longer open to the whole team. That is the difference between a file nobody uses and a file anybody with valid access can open.
How to Decide What to Keep
Start with categories, not individual files. You will never review forty million documents by hand. You can agree on twelve categories.
- Contracts and agreements: Keep through the term plus the legal limitation period. Counsel sets it.
- Financial records. Governed by tax and audit requirements.
- Personnel files. Governed by employment law, and sensitive from day one.
- Customer and personal data. Keep only as long as the purpose lasts. This is where minimization matters most.
- Design, engineering, and IP files. Often kept indefinitely. Often the most valuable to a competitor.
- Regulated technical data. Rules vary. Treat as the highest tier while it exists.
- Project working files. Usually low value after the project closes. A primary driver of unnecessary data exposure.
- Email attachments and downloads. Rarely covered by any schedule, and the largest source of untracked copies.
- Security and access logs. Often required for years. Check the framework you answer to.
- Backups. Your schedule must say how long they live, because they hold every file you deleted.
- Drafts and duplicates. Delete early.
- Anything under legal hold. Exempt from every schedule until counsel releases it.
For each category, write one line: how long, who decides, and what happens at the end. A schedule with twelve lines that people follow beats a hundred-page one they do not.
The Problem Retention Schedules Skip: Copies You Cannot Find
Even a perfect schedule fails on one point. You can delete the file in the system of record. You cannot guarantee you deleted every copy.
Copies live in backups. They live in old email. They live on laptops that left the building with former employees, on contractors' drives, in personal cloud storage, and in the cache of whatever AI tool someone pasted the text into. Most of these sit outside any tool that can apply your schedule. We covered the contractor version of this in What Happens to Your Sensitive Files When a Contractor Leaves.
The operational reality is that file deletion across distributed environments is rarely complete. A retention policy that depends on deleting every copy will not meet its own promise.
The more useful question is a different one: for the copies you cannot delete, what can they do?
If the answer is "anyone who finds one can open it," then every forgotten copy is still a live exposure. If each copy is encrypted with its own key—or protected by context-aware access controls—so that it opens only for an identity your policy approves, a forgotten copy is simply a locked file. It exists. It cannot be read by someone who should not read it. And the policy that governs it can change after the file has left, without you finding it first.
This is where data-centric security changes the model. Theodosian moves the wall to the file, so a protected copy stays protected wherever it ended up. Control that travels with the data matters most for the copies you do not know about.
The Honest Limits
Theodosian provides continuous cloud discovery, agentic classification, and file-layer protection. We believe in being explicit about what our architecture does and does not do:
- In-Use View Restrictions vs. Full DRM: We enforce context-aware access decisions (identity, device, location, time) at the moment a file is opened or decrypted. However, once an authorized user opens a file in a native application, we do not restrict screen capture, printing, or physical copying of text (full digital rights management/DRM features are on our roadmap).
- Unstructured Files vs. Relational Databases: Our pipeline is built specifically to discover, classify, and protect unstructured files (documents, spreadsheets, PDFs, presentation decks, source code) across cloud storage. It does not inspect or encrypt relational databases (SQL, Postgres, Snowflake).
- Deletion Execution: Theodosian does not physically purge files from your underlying cloud storage or destroy encryption keys (retaining keys ensures files remain recoverable for legal holds and authorized audits). Physical file deletion is executed directly within your storage environments or via your records management tools.
Legal Holds and Why Recoverability Is a Feature
Legal hold is where "delete everything" meets reality. When litigation or an investigation is reasonably anticipated, relevant files must be preserved, and deleting them can create serious problems of its own.
This is the best argument against destroying keys as a retention strategy. A file you cannot recover cannot be produced. It can also look like destruction of evidence if the timing is wrong.
Keeping files recoverable while restricting access gives you both. A file under hold can be set to one custodian, such as legal or the records manager, so it is preserved and untouched. When the hold lifts, an authorized administrator decides what happens next. This is a design choice about recoverability, not a legal-hold product, and your counsel should own the process.
A 90-Day Plan to Shrink What You Hold
You do not need a records program overhaul. You need three decisions a month.
Days 1 to 30: Agree on the schedule. Get counsel to sign off on the twelve categories above and the three states. Name an owner for each. Write down what happens to legal hold files.
Days 31 to 60: Find the heaviest piles. Look for the repositories that hold the oldest, largest, or most sensitive files: the main shared drive, the archive, the project folders from three years ago. You are not cleaning everything. You are finding where the age and volume sit.
Days 61 to 90: Retire and delete in bulk. Delete what is cleared. Retire what is not. For files that stay, apply the protection their sensitivity tier calls for. For the Restricted tier, that means a key of its own and an access decision at every open. Our guide to data classification levels covers how to tier them.
Run it again each quarter. The schedule matters less than the habit.
What This Means for Your Security Program
Retention is usually filed under compliance. It belongs under risk reduction.
Every file you keep that no one needs is a file that a compromised account, a departing employee, or a careless forward can expose. Each one adds to the scope of any incident and the cost of any investigation. Shrinking that pile is not glamorous. It is one of the few controls that gets cheaper the more you do it.
The ones you cannot shrink—the legal holds, the regulated records, the copies you will never find—need a different kind of protection: one that does not depend on where the file sits.
Keep what you need. Retire what you must hold. Delete what you can. And make sure the files that remain defend themselves.
Control Your Oldest and Most Sensitive Files
We run a two-week pilot on a defined set of your files. You choose them. We can show you what happens when one is downloaded, forwarded, and then restricted to a single person.
FAQs: Retention and Per-File Protection
Can Theodosian delete files when their retention period ends?
No. Physical file deletion is handled directly within your cloud storage or records management system, and Theodosian does not destroy encryption keys so that files remain recoverable when required for legal holds or audits. What Theodosian controls is access: when a file reaches the end of its lifecycle, you can restrict access to a single named custodian or revoke access entirely.
Why doesn't Theodosian destroy keys to make old files unreadable?
Because destroyed keys cannot be recovered, and a file that cannot be recovered can lock out the people who legitimately need it, including legal during a hold. Keys are retained so a file is never permanently unreachable. Access is the control: it can be narrowed to one person or to no one.
What happens to an old copy of a protected file that is still sitting in a backup or on a former employee's laptop?
It stays encrypted, with its own key, and opening it requires an access decision against your current policy: who is asking, from which device, from where, and when. If your policy no longer approves that person, the copy cannot be read. You can run this on your own files in the pilot: protect a file, copy it out of your environment, then restrict access and watch what happens to the copy.
Can an administrator remove encryption from a file?
Yes. An administrator can remove encryption from a file, and if the file is protected again, a new key is created. We would not suggest treating that as an exception to manage informally. Admin accounts belong in your privileged access program.
Does Theodosian help us find which files are past retention?
Yes. Theodosian’s continuous discovery and agentic classification engine continuously scans your cloud repositories (such as SharePoint and Google Drive) to map file age, access permissions, and sensitivity tiers. This allows you to quickly locate stale or unmanaged files that have exceeded retention windows. We cover the main discovery options in the best sensitive data discovery tools in 2026.
What would a two-week pilot on our oldest files show us?
We protect a defined set of files you choose, over your existing Microsoft 365, Google Workspace, or cloud storage, with no data migration. You see what happens when one is downloaded, forwarded outside the company, and then restricted to a single person, plus the per-file access record from your own environment. You finish with a clear answer to what your retention policy cannot tell you: what the forgotten copies can still do.
Related Reading:
Data Classification Levels: How to Tier Your Files
Data Sprawl: The Compliance Risk Nobody Is Auditing
Shadow Data: The Files Your DLP Tool Will Never Find
What Is Information Governance?
🔍 Contractor Access Audit: Contractors hold copies no retention schedule reaches. Use our Contractor Offboarding File Security Checklist to find out which files are still out there.
🤖 AI Access Audit: Files pasted into AI tools outlive every schedule. Use our Shadow AI Risk Assessment Checklist to map where that happens.