Data retention and deletion: schedules, flows, backups and logs

Most digital businesses keep data because deleting it takes effort and keeping it seems free. It is not free. Every record kept is a record that can leak, be misused, slow down a migration or complicate a customer's request to be forgotten. And most of it is never looked at again.

At Oryvelon, each company has its own data retention and deletion practice: a written schedule of what it keeps and for how long, deletion flows that reach every copy, and clear handling of backups and logs. This note explains how we approach it, with examples from across the group.

It describes practice, not legal advice. Laws such as GDPR in Europe and the UK and KVKK in Türkiye set expectations about keeping personal data only as long as necessary and honouring deletion requests; children's data rules such as COPPA in the United States add more. Each company takes its own advice on how these apply to it.

Why retention is a company decision, not a group one

It would be tidy to have one retention policy for the whole group. It would also be wrong.

Our companies are different businesses with different users. EduRelia works with students, families and schools, and keeps as little as possible about children. CastLyra is a marketplace where verification records and consent matter. Noveniq is a store with orders, invoices and returns. MerchNivo processes data from merchants' Shopify stores on their behalf. KeşifAtlası handles questions about people's relocation plans. Each has different obligations and different reasons to keep things.

So each company owns its retention schedule, stored in its source-of-truth document. What the group shares is the method: the template, the checklist and the review cadence. This follows the broader principle of shared infrastructure, separate data. And because no user data is shared between products, a deletion in one company never needs to be coordinated with another.

Building a retention schedule

A retention schedule is a table. It does not need to be long, but it needs to be complete. Each row is a type of data, and the columns answer the same questions.

Two columns cause most of the work.

Location is where hidden copies appear. When a team lists every place an order record lives, they usually find it in the database, the admin tool's export folder, the email service that sent the receipt, the analytics tool, the support tool and a spreadsheet someone made last quarter. All of them belong in the row.

Retention needs a starting event, not just a duration. "Two years" means nothing without "from what?" From account closure? From the last order? From the end of the school's licence? The event determines when the clock starts, and it is often the part people get wrong.

A simplified, illustrative example for a store like Noveniq might include rows like these. The durations here are placeholders to show the shape, not recommendations:

Short by default

Our starting assumption for any new data type is short retention. The team has to justify keeping something longer, and "it might be useful someday" is not a justification.

Longer retention needs a concrete reason: an accounting or legal requirement, an active contract, a real product feature that depends on history, or a security need. Where history is useful for analysis, we ask whether aggregated or anonymised data would do. Usually it does. A store does not need five-year-old customer names to know which months are busiest.

This is also a cost decision. Storage is cheap per gigabyte, but data that must be protected, backed up, migrated, searched and eventually deleted is not.

Deletion flows that reach every copy

A deletion request — from a user, a school, a merchant uninstalling an app, or a scheduled job — is only complete when it has reached every place the data lives. We design deletion as a flow with explicit steps, not a single database command.

A typical account deletion flow looks like this:

1. Verify the request and confirm the scope (whole account, a specific item, a tenant).
2. Mark for deletion immediately, so the data is no longer shown or used, even before physical removal.
3. Delete from the primary database, including related records.
4. Delete derived data: search indexes, AI retrieval indexes and embeddings, caches, generated summaries.
5. Delete files: uploads, exports, generated documents.
6. Notify connected tools: email platforms, support tools, analytics, payment providers, through their deletion interfaces where they exist.
7. Record the deletion in a log that says what was deleted and when, without keeping the deleted content.
8. Confirm to the requester where appropriate.

Step 4 is the one teams forget most often, and it matters more as products use AI. An embedding of a user's document is derived from that document; if the document is deleted and the embedding remains, retrieval can still surface it. See RAG without data leakage.

Step 6 is where deletion leaves your own systems. We keep a list, per company, of every external tool that receives personal data and how deletion works in each. If a tool has no way to delete data on request, that is a reason to reconsider using it. Our quarterly review of tools is where that question is asked.

Worked examples across the group

MerchNivo: when a merchant leaves

MerchNivo works with data from a merchant's Shopify store: orders, products, inventory and customer information needed to produce briefings and operations signals. The merchant is the customer; their store's shoppers are people whose data MerchNivo processes on the merchant's behalf.

When a merchant uninstalls the app, the store's data is scheduled for deletion after a short, stated grace period, in case the uninstall was a mistake. After that, store data, generated briefings, cached AI outputs and any retrieval index for that store are deleted. Operational metrics that contain no store data — request counts, latency — may remain in aggregate. Shopify's own requirements for apps handling customer data requests are part of the flow as well. See Tenant isolation explained.

MerchNivo also avoids copying shopper data it does not need. A refund spike can be described with counts and product names; it does not need the names of the customers who asked for refunds. Less copied data means less to delete.

EduRelia: when a school's licence ends

For EduRelia, the retention schedule is shorter across the board, and some data is never stored at all. Tutoring conversations are kept only for as long as the product feature and the school agreement require, then deleted. Student profiles hold the minimum needed to run the product.

When a school's licence ends, the school's tenant data — student accounts, progress records, uploaded materials, the school's retrieval namespace — is deleted on a schedule agreed with the school, with an export offered first where the school needs it. See B2B2C licensing for schools and Data minimisation for children in edtech.

CastLyra: verification records

CastLyra has a harder balance. Verification is central to the marketplace's trust, so the fact that a profile was verified, and when, needs to be kept while the profile is active. But the documents used to verify it — identity documents, for instance — are sensitive, and keeping them indefinitely increases risk without adding much.

The approach we favour is to keep the verification outcome and date, and delete the underlying documents after a short, defined period once review is complete. When a talent closes their account, their public profile, portfolio and contact details are removed promptly, and consent records are handled according to the schedule.

KeşifAtlası: answers about someone's plans

KeşifAtlası users answer questions about their nationality, work, family situation and where they hope to move, in order to see which visa or relocation rules may apply. Those answers are personal, and many users only take the free test once.

So answers from a free test that does not lead to an account are kept only briefly, long enough to show the result and let the user continue to a paid report if they choose. After that they are deleted, and only aggregated counts remain — how many tests were completed for a given route, for example — with nothing that identifies a person. For paid reports, the answers and the report are kept for a defined period after delivery so the customer can return to it and ask follow-up questions, then deleted unless the customer keeps an account. See From free test to paid report.

Backups: expire, don't edit

Backups are where deletion gets awkward. A backup is a snapshot; if a user's data was in yesterday's snapshot, deleting it from the live database today does not remove it from the backup.

Editing backups to remove individual records is usually impractical and risky. So our approach is:

• Backups expire on a fixed, documented cycle. Once the cycle passes, data deleted from the live system is gone from backups too.
• The cycle is part of the retention schedule and part of what we tell users about how long deletion takes to fully complete.
• Backups are access-restricted, encrypted and used only for recovery, never for analytics or testing.
• Restores re-apply deletions. If we ever restore from a backup, the deletion log is replayed against the restored data before it goes live, so deleted records do not return.

That last point is the one people miss. Without it, a restore quietly undoes every deletion made since the backup was taken.

Logs: useful, short-lived and filtered

Logs are the other quiet store of personal data. Application logs, server logs, error reports and AI request logs can all contain names, emails, IP addresses or entire user messages.

Our rules for logs:

• Filter at write time. Personal fields are masked before logs are written, not after.
• Log metadata, not content. For AI features, the gateway records model, prompt version, token counts, latency and outcome by default, not the prompt text or response. See Building an AI gateway.
• Short rolling retention. Operational logs are kept for a short period, long enough to investigate issues and security events.
• Separate security logs. Logs needed for security investigations, such as authentication events, may be kept longer, with tighter access.
• Deletion log without content. The record that a deletion happened says which account and which categories, not what the data was.

AI data is data

AI features create new places for personal data to live, and each needs a retention rule:

• Prompt and response logs, if kept for evaluation, are sampled, filtered and stored for a short, defined period in the product's own storage.
• Caches of model responses expire, and any entry keyed to a user or tenant is deleted with them. See Latency and caching for AI.
• Retrieval indexes and embeddings follow the source documents they were built from.
• Evaluation sets use synthetic or explicitly consented data, never copied production conversations.
• Provider-side retention is checked in each product's AI project settings, so that data sent to a model provider is not kept longer than the product's own policy allows.

Deletion versus anonymisation

Not every end action has to be deletion. Sometimes a record is useful in aggregate long after the personal part stops being needed. In that case we anonymise: remove or irreversibly transform everything that could identify a person, and keep the rest.

It is easy to do this badly. Replacing a name with an internal ID is not anonymisation if the ID can be joined back to the account table. Removing names but keeping exact addresses, birth dates and rare combinations of attributes often leaves people identifiable. Real anonymisation usually means aggregating — counts per week, per product, per region — rather than keeping individual rows with fields blanked out.

Our rule of thumb: if the anonymised data would still let someone on the team answer "was this particular person in here?", it is not anonymised enough, and it stays under the retention schedule like any other personal data.

Handling individual requests

Scheduled deletion covers most data. Individual requests — "please delete my account", "what do you hold about me?" — need a clear path too.

Each company publishes how to make a request and handles it through the same deletion flow described above, not through a one-off manual clean-up. The requester's identity is confirmed in proportion to the risk: signing in to the account is usually enough; a request by email for a sensitive account needs more. The team replies within the time the applicable rules set, and says honestly what happens next, including that backups will clear on their normal cycle and that some records, such as invoices, may be kept where the law requires them.

For EduRelia, requests about a student usually come through the school or a parent, and the flow reflects that. For MerchNivo, a shopper's request about their data normally reaches the merchant first, and MerchNivo supports the merchant in carrying it out.

Reviewing the schedule

A retention schedule written once and never checked is just a document. Each company reviews its schedule as part of the operating cadence, typically quarterly, and whenever a new data type, tool or feature is added.

The review asks three questions: does every data type we now hold appear in the schedule; are the deletion jobs actually running, with evidence; and has any retention period grown without a reason? We also run a test deletion in staging for a representative account and confirm it disappears from every listed location.

Common mistakes

• No starting event. "Keep for a year" with no defined start is unenforceable.
• Forgetting derived data. Indexes, caches, exports and summaries outlive their sources.
• Soft delete forever. Marking records as deleted without ever removing them is hiding, not deleting.
• Test data from production. Copying real customer data into test environments creates copies no deletion flow knows about.
• Marketing and product data mixed. Unsubscribing from emails and deleting an account are different requests with different flows. See Marketing consent vs product consent.

Summary

Data retention and deletion work when each company treats them as design decisions rather than clean-up. At Oryvelon every company owns a written schedule listing each data type, its purpose, every location, a retention period with a starting event, and the mechanism that deletes it. Deletion flows reach every copy — databases, AI indexes and embeddings, caches, files, external tools and logs. Backups expire on a documented cycle and deletions are re-applied after any restore. Logs are filtered and short-lived, AI data is treated as data, and the schedule is reviewed regularly with a real test deletion.

Questions and answers

What is a data retention schedule?

A data retention schedule is a written list of each type of data a business holds, the reason it is kept, where it is stored and how long it is kept before deletion or anonymisation. It turns retention from an ad hoc habit into a rule that can be checked.

How should deletion work with backups?

Most teams do not edit backups directly. Instead, backups expire on a fixed cycle, and a documented process makes sure any data restored from a backup has pending deletions re-applied before it is used.

Do AI features need their own data retention rules?

Yes. Prompts, model responses, evaluation samples, caches and retrieval indexes can all contain personal data, so they need defined retention periods and must be included in deletion flows like any other store.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Data, Privacy & Security

NextTenant isolation explained: separate databases, schemas and row-level security →