What changes for you
Your product stops holding on to everything forever. Today nothing removes anything. Accounts that were closed years ago are still there. Logs that nobody reads keep growing. Files uploaded for a project that ended are still stored next to the ones in use. None of it was a decision. It is simply what happens when a product was built to add data and never to let it go.
Deletion requests follow the same pattern. When someone writes in to ask for their account to be removed, a person on your team has to work out where that account’s data lives, remove it by hand and reply. No two requests look quite the same, and every one sits in a queue behind other work.
With your own keeping rules built into your product, that changes. For each kind of record you choose how long it stays. When the period you set ends, the record is removed. When someone asks for their account to be deleted, the request is carried out without anyone on your team assembling it by hand.
Something else changes too. Data you no longer hold is data you no longer have to look after, explain or worry about. A product that keeps only what it needs is easier to reason about for everyone who works on it.
This page is about the records your users put into your product and the traces it keeps of them. Your code is a separate matter. The keeping rules arrive as changes in your own code repository. The code we build for you is yours.
What you decide
You decide what each kind of record is and how long it stays. Accounts, activity logs, uploaded files and messages can each have their own period, or none at all. We do not recommend a period, because the right one depends on your business and on what you are obliged to keep.
You decide what a deletion request covers. Some records belong to the person asking. Others may belong to their organisation, or may be something you have to keep for your own reasons. Where that line sits is a business and legal question, not a technical one.
You decide who may ask and where. A request might come from the person themselves inside your product, from an administrator on their behalf, or still by email to your team. You also decide how the product tells them their request has been carried out.
The law has a say here too. In the EU, Article 17 of the General Data Protection Regulation sets out the right to erasure. What it asks of your product, if anything, is a judgement for you and your legal advisers, and this page is not legal advice. For the wider question of what a product collects and keeps, see Data protection by design, for product leaders.
What you see along the way
You see your keeping rules take shape in your repository, as small changes your team can read and approve. A choice that is yours, such as which records a deletion request leaves in place, reaches you with the question and a link. Nothing reaches your users without your approval.
What it costs you in time
A first conversation about the data your product holds, what you want to keep and for how long. After that, some time from the person who handles deletion requests today. They know what people ask for and where the awkward cases are, and that knowledge shapes rules that fit your product.
What if you want to stop
The rules you approved before stopping stay in your repository. Your team can go on answering deletion requests by email, as it does today. Your code and your product stay yours to take anywhere.
Starting small
We have not built keeping rules like these for a customer before, so this page describes what we can do, not something we have done. A good first piece is a single rule for the kind of record that piles up fastest, so you can see the result before deciding what comes next. Every engagement is tailored to your product and your goals. It starts with a conversation, with no obligation.
