Most "data retention policy" documents fail for the same reason: someone typed in a period that sounded reasonable — "keep for 7 years," "delete after 90 days" — without it actually coming from anywhere. A retention schedule is only as good as the periods in it, and no software can tell you what those periods should be. What software can do is take the periods you already know and turn them into something concrete: a document, and a set of dates you'll actually see again.
Start with the one thing a tool can't give you: the periods
A data retention schedule needs three things per category of data: how long to keep it, what starts the clock, and why. The "why" — the legal or business basis — is what makes the period defensible instead of arbitrary. Tax records might follow a statute of limitations. Support tickets might follow an internal policy. Marketing data you collected with consent might follow whatever you told people in your consent notice.
None of that comes from a calculator. It comes from your legal or compliance advisor, the specific law that applies to your jurisdiction and industry, or a documented internal decision. If you don't have those periods yet, get them before you build the schedule — a schedule full of guessed numbers is worse than no schedule, because it looks authoritative.
What a retention schedule actually needs to record
Once you have the periods, each line in the schedule needs five things:
- Data category — specific enough to be useful ("customer support tickets," not "data")
- Retention period — a duration, like 3 years or 90 days
- Trigger — the event the clock starts from: date collected, last activity, contract or relationship end, account closure, or something else you specify
- Start date — the day that trigger actually happened, if it already has
- Basis — the law, contract clause, or internal policy that justifies the period
That structure matters because of a distinction that is easy to get backwards. The question isn't which trigger a row uses — it's whether that trigger has already happened. A contract that ended last June is a known date, just as much as data collected on a known day, and both give you a review date you can compute right now. What you genuinely cannot compute is a trigger still in the future: a contract that hasn't ended, an account still open. Nobody knows those dates yet, because they depend on when the event actually happens. A schedule that pretends otherwise is fabricating a date it can't back up.
FileX's Retention Policy Calculator is built around that distinction directly, and it's worth being precise about what the tool does and doesn't do: it holds no retention periods, no legal defaults, and no jurisdiction-specific rules of its own. Every period, trigger, start date, and basis on the schedule is something you typed in. The tool's job is arithmetic and assembly — give any row a start date and it works out the review/delete date from your period, then formats the whole set of categories into a readable document. Leave the start date blank on a row whose trigger hasn't happened yet and it records the rule without pretending to know the date, and says so. It's also explicit about the difference between a date you supplied and one it assumed: a row marked "date collected" with no start date is read as collected today, and its date is labelled an example rather than presented as fact.
Turning the schedule into reminders you'll actually see
A retention schedule that lives in a document nobody reopens doesn't get enforced — it gets forgotten until an audit or a breach notification forces someone to go looking. The Retention Policy Calculator addresses that with a downloadable .ics calendar file: one reminder event per category, but only for rows where a review date could actually be calculated (a start date plus a valid period). Import it into whatever calendar you already use, and the review date shows up as a real appointment with a one-day-ahead alarm, not a line in a PDF you'll have to remember to check.
Categories whose trigger hasn't happened yet still appear in the schedule text — they're just not on the calendar, because there's no date yet to put there. When that event does happen (the contract ends, the account closes), that's your cue to come back, fill in the start date, and let the tool calculate the real review date from the rule you already recorded.
Where retention fits with what you've already told people
If you collect personal data from users, your retention period isn't a private decision — it's something you likely already disclosed. FileX's Consent Notice Generator includes a retention field in the notice it produces, precisely because "how long do you keep this" is a question a consent notice is expected to answer. Keeping the two in sync matters: a retention schedule that keeps customer data for 5 years while your public notice says 2 years is a discrepancy someone will eventually notice, and it undermines both documents.
The practical order is: decide the periods with your legal or compliance advisor first, state them consistently in your consent notice, then build the schedule from the same numbers. A tool can keep those two documents structurally aligned; it can't make the underlying decision for you.
The honest limits, stated plainly
A generated retention schedule is a formatting and date-arithmetic aid, not a compliance certification. It won't tell you that a period is legally correct, and it won't catch a period that's wrong for your jurisdiction. What it will do is turn periods you already know into a document with correctly computed dates, and turn every row whose trigger has already happened into a calendar reminder you're actually likely to see. That's a real, bounded piece of the work — not the legal judgment part, which stays yours.
Try the Retention Policy Calculator with your own categories and periods — nothing is uploaded, the schedule and the calendar file are both built entirely in your browser.