Data Retention Policies: setup under GDPR, 152-FZ and HIPAA

Data retention: where personal data storage breaks

Excess data does not appear because of an influx of users, but because of the absence of a decision on retention periods.

Application logs, transactional tables, exports to the analytics environment, snapshots and backup copies are written by different services and remain there until disk space runs out.

Formally, this is personal data storage; in practice, it is a dump without an owner and without a date.

Storage sprawl is almost never related to load: the same set of fields is duplicated in the primary database, in a replica, in a cache and in a report generated once a day.

Even if a retention period is fixed, it is in a paper policy, not in configuration — therefore overdue storage is detected during an inspection or a data subject deletion request, not in advance.

Deleting what is needed turns out to be harder than storing it. A record lives in several places, is linked by foreign keys, ends up in precomputed marts and immutable archives; point cleanup breaks referential integrity, and a full product shutdown for migration is unacceptable.

Then the choice is small: either manual cleanup in prod or deferred deletion with the risk of accumulating even more.

The cause is usually the same — the data retention policy was not designed as part of the data schema; it was bolted on top when the regulator asked the question.

We break down how this is addressed: where to draw the line between "needed for operation" and "time to delete," how to bind rules to specific fields rather than entire services, and how to embed deletion into the normal operations cycle without stopping products.

What a managed personal data retention policy provides

When each data set has an owner, a lifetime and a deletion trigger, storage stops being a "just in case" dump.

A retention policy describes not only the period itself but also what happens upon its expiry: irreversible deletion, anonymization or transfer to an archive with restricted access. It is after this that data minimization stops being a declaration and becomes a working rule.

The first measurable effect is a reduction in the volume of the active environment.

Records past their expiry leave hot tables on schedule, not based on an engineer's memory: indexes and backups shrink, recovery after a failure fits into a shorter interval, and scheduled maintenance stops stretching overnight.

The second is a predictable response to a data subject request. A data map links a person's identifier to specific tables, file storages and queues, so retrieval, correction and deletion follow it rather than searching the entire database. A request is closed in hours instead of days of manually traversing services.

The third is an eliminated class of regulator findings. Requirements of GDPR, 152-FZ and HIPAA diverge in detail but converge on one thing: the retention period must be justified, and deletion must be confirmed.

Approved periods together with the deletion log close the question "why is this data still with us" without rewriting systems for each set of rules.

Ways to implement a retention policy: comparison of approaches

The choice of layer determines whether the rule will work when a service is rewritten or when a record is linked to dozens of tables.

For GDPR, 152-FZ and HIPAA, what matters is not the fact that cleanup is configured but provability: the inspector sees that the record disappeared on time.

The working scheme is almost always hybrid: automatic cleanup jobs run on schedule, mark records for deletion, and the storage level finishes the remainder by period. Each trigger writes the identifier, rule and time to the log — this is the proof for inspection.

Implementing data retention: stages of engineering work

Implementing retention is not a switch in a panel but a sequence of works: first you need to understand where data lies and where it is copied, and only then configure deletion.

Otherwise the rule will trigger in the primary database, but the copy will remain in a replica, search index or nightly backup. The order in which we run such projects is below.

1. Audit of data flows. We build a map: which services write personal data and where it settles — primary database, replicas, object storage, queues, caches, exports to analytics, application logs, backups. For each storage we record the owner, data category and lifetime. The result is a register that shows hidden copies that usually no one remembers.

2. Agreement of periods. For each data set we determine the period and basis: legal requirement, contract condition, account lifetime, consent withdrawal. We consolidate them into one table with the action upon expiry — delete, anonymize or transfer to archive.

3. Schema design. We decide where the rule lives: lifecycle policy on the storage side, scheduled job, cascading deletion at the application level, masking. We think through how the rule will survive a schema change and service migration.

4. Setting up deletion rules. We maintain rules as code in a repository: changes go through review, not hand-edited in panels. In parallel we enable a log — who, when and by which rule deleted a record.

5. Testing on a test environment. We fill a sandbox with similar data and run scenarios: expiry, consent withdrawal, restore from backup, repeated rule run. We check that deletion does not affect linked records and does not break reporting.

6. Handover to operations. We give the on-call team regulations, monitoring and alerts for rule failures, and the procedure for handling a data subject request. After an agreed interval we return and reconcile the policy with actual flows — they change faster than the document.

What remains with you after implementing a retention policy

A retention policy is not one signed document but a set of artifacts by which the system can be checked, handed over to another team and shown to an inspector. Below is what exactly remains in your hands after implementation.

• Retention period matrix — a table by data categories: accounts, requests, transaction history, backups, exports to analytics. For each row, the period, the basis for it and the owner who approves a change are indicated.
• Data flow diagram — from the point where a record appears to the archive and deletion: in which storages data is copied, which services read it, where intermediate snapshots remain.
• Cleanup job configurations — versioned files with schedule, selection conditions, batch size and behavior on failure. A rule change goes through review, not hand-edited on a server.
• Operation logging — a separate stream protected from editing: what was deleted, when, by which rule and who initiated it. The log is retained longer than the data itself; otherwise there is nothing to confirm deletion with.
• Deletion procedure — step-by-step scenarios: deletion upon a user request, emergency cleanup, procedure for approval and confirmation of the result.
• Run reports — how many records fell under the rule, what was deleted, what was skipped and for what reason. Discrepancies are visible immediately, not at the inspection stage.
• Documentation and roles — who is responsible for the category, how to add a new rule, where exceptions are recorded.

The set is checked on a copy of the data: running the rules, reconciling the report with the matrix, analyzing skips. Describe the task — we will come back with an estimate and a plan for your set of storages.

Case: bringing storage into compliance with three regulators

The client is a service with users in the EU, Russia and the USA: the same data was subject to GDPR, 152-FZ and HIPAA, and the periods diverged — in some places storage was limited by contract term, in others a fixed period was set.

Some data lived in PostgreSQL, some in object storage and application logs, and each system had its own "rules" described in a wiki.

At the start, the share of overdue records in the main sets remained at 18–23%: deletion scripts failed on linked rows, and some tasks were disabled during incidents and not turned back on.

A data subject access request was prepared manually — exports from three systems, reconciliation — and the response took 6–9 business days. A planned regulator inspection brought seven findings, four of them about retention periods and the lack of evidence of deletion.

What was changed

First we assembled a register: data type, legal basis, period, action upon expiry — delete, anonymize or transfer to archive.

Then the rules stopped being a document and became configuration: declarative policies in a repository, binding to tables and fields, a check at build — a data set without an assigned rule does not pass deployment.

Deletion was moved to partitioning and cascades instead of row-by-row traversals; each action is written to an immutable log — from it a report for the inspector is generated.

For analytics, copies with masking of personal fields are collected: reports are built, but personal data does not enter the production environment.

After implementation, the share of overdue records is less than 1%; the remainder falls to disputed cases with an open period. The response to a data subject request is assembled automatically by identifier and fits within one business day.

A repeat inspection produced no findings on storage: the log confirms both the period and the fact of deletion.

How GDPR differs from 152-FZ and HIPAA by retention periods

Short answer: neither GDPR, nor 152-FZ, nor HIPAA sets a retention period in days. They define what the period is derived from — processing purpose, legal basis and the obligation to stop processing when the purpose is achieved.

Therefore the same export lives for different times under different regimes, and it is correct to compare regimes along four axes.

Practical conclusion: the period is not a constant in code but a property of the data category.

In a retention policy, each category has a period label, an auto-deletion schedule and a separate path for data subject requests — deletion on demand goes through it, not through manual database edits.

The deletion log is written immediately to immutable storage: it is what closes the first inspection.

Technical questions about data retention periods

Retention periods rarely come down to one number: transactional records, logs, attachments and anonymized statistics live by different rules.

A policy becomes workable only when it is enforced equally in the primary database, object storage and backups — otherwise deletion turns into a one-off manual operation that no one will repeat a month later.

Can data be anonymized instead of deleted?

Yes, if the data is needed for analytics and reporting. Anonymization works only when it is irreversible: direct identifiers are removed, and the mapping table is not stored.

Pseudonymization with a key on the application side is not considered deletion — access to the record is restored, so the retention period continues to apply.

What to do with accumulations that appeared before the policy?

They are handled in a separate pass: inventory of storages, classification by categories, then a decision for each group — delete, anonymize or leave with justification.

Then records are distributed across partitions with binding to date, so deletion goes by partition boundary, not row-by-row scanning of heavy tables.

How to make sure the policy actually works?

We set up automatic checks: a report on the volume of records past the period, a comparison of the actual retention period with the declared one, and control of the deletion log.

Separately we check logs — if identifiers get into them, their own shorter period applies, and this also goes into the check.

Let's discuss your data retention task

To come back with an estimate and a plan, not with general words, we need a minimum of inputs about your infrastructure. Storage touches databases, object storages, backups, logs and exports to analytics — each contour has its own periods and grounds for deletion. Send what you have at hand; we will clarify the rest on a call.

• List of systems and storages — databases, file and object storages, queues, backup archives, as well as external services where data goes (analytics, mailings, support).
• Data categories and processing grounds — where personal data is, where medical information is, where payment and technical logs are; for each category — the requirement from which the retention period follows.
• Current procedures — what is already described: periods, the procedure for deletion upon a data subject request, who is responsible for execution and how the fact of deletion is recorded.
• Downtime and load constraints — windows when schema migrations and mass deletion runs are allowed, peak hours, service availability requirements.
• Testing environment — whether there is a separate environment close to production where retention rules and rollback can be tested without risk to live data.
• Current backup schemes — the depth of copy retention and how deletion in the primary system affects archives; otherwise data continues to live in the backup.

Based on these inputs, we prepare a storage audit, then a work plan and retention rules, test them on a pilot environment and remain on support — the rules will have to be revised when the composition of systems changes. Describe the task in a convenient form, and we will come back with an estimate and a plan.