Retention and deletion of personal data under Law 21.719

For years, storing data "just in case" was the norm at many Chilean companies. Law 21.719, which updates the personal data protection framework in Chile and reaches full force after a transition period, changes that logic: personal data is not an asset to be accumulated without limit, but information you may keep only for as long as it serves the specific purpose for which you collected it. Once that purpose is fulfilled or disappears, the standard is to delete the data or stop identifying a person. If you want the full picture, start with our guide to the data protection law in Chile.

This is not a minor technical detail. Two of the law's principles (purpose and quality) converge precisely here. The purpose principle requires that every processing activity have a legitimate, explicit and defined objective; the quality principle requires that data be accurate, relevant and not excessive in relation to that purpose. Data that is no longer needed stops being relevant, and keeping it weakens the justification for that processing.

In this guide you'll see how to translate these principles into concrete decisions: how to set defensible retention periods, how to build a retention policy by data category, what it means to delete securely and to anonymize, how it all connects to the data subject's right to erasure, and which exceptions may allow you to keep information even when the subject asks you to delete it.

Why the purpose and quality principles require deleting data

The starting point is not "when do I have to delete," but "why am I keeping this." The purpose principle establishes that data is collected for specific, explicit and lawful objectives, and should not later be used for purposes incompatible with those. The quality principle complements it: data must be accurate, up to date and relevant in relation to the purpose. Data that outlives its purpose stops satisfying both principles at once.

This is where the idea of limited retention comes from. As a general rule, there is no reason to store information indefinitely. As long as the data is necessary for the purpose (or for a legitimate exception we'll cover later), you may keep it. When that need ends, the standard is to delete or anonymize it. In practice, this gives every database an "expiration date" by record type.

For the controller, this connects directly to the principle of accountability: good intentions are not enough; you should be able to demonstrate that retention rules exist, that they are applied, and that information is purged. A company that hoards data on former applicants from eight years ago, or marketing emails to people who never replied, has a compliance problem and, on top of that, a larger risk surface if a breach occurs.

How to set defensible retention periods

A retention period isn't invented; it's justified. The right question for each set of data is "how long do I really need this information for the stated purpose, or to meet an associated legal obligation?" From that answer you define a concrete period and document it. Vague timeframes like "as long as needed" are useless if you can't translate them into an applicable rule.

There are three typical sources that set a period. The first is the purpose itself: for example, the data of an unsuccessful job application stops being necessary shortly after the process closes, unless the person consents to remain in a database for future processes. The second is legal obligations under other regulations (tax, labor, accounting, social security) that require certain records to be kept for defined periods. The third is the potential defense against claims or litigation, which may justify keeping certain information for as long as active proceedings exist.

• Identify the exact purpose of each set of data before assigning it a period.
• Distinguish between the "active use" period and the "archival" period for legal compliance or defense.
• Anchor each period to a concrete justification: purpose, legal obligation or active legal action.
• Define what happens when the period expires: secure deletion, anonymization or documented manual review.
• Review the periods regularly, because purposes and obligations change over time.

Retention policy by data category

The most common mistake is treating all data the same. A useful retention policy is organized by category, because each type of data has different purposes and timeframes. The practical approach is to build a matrix that cross-references data category, purpose, legal basis, retention period, deletion criterion and responsible party. That matrix draws directly on your Record of Processing Activities (RoPA): if you already have one, much of the work is done.

Think about the typical categories at a Chilean company. HR data (applicants, active employees, former employees) usually carries long retention periods due to labor and social security obligations. Customer and billing data intersects with tax and accounting obligations. Marketing and prospect data depends on the legal basis that supports it (for example, consent or another applicable basis), and usually has the shortest timeframes. Security data, such as access logs or video, tends to be kept for brief periods. And sensitive data (including, among others, health, biometric data such as facial recognition, and socioeconomic status) demands special rigor and, as a rule, the tightest timeframes.

The policy must be a living, actionable document, not a PDF nobody opens. For each category, define who is responsible for carrying out the deletion, how often it is reviewed, and how you record that the purge actually happened. Without that record, it is hard to demonstrate compliance to the Personal Data Protection Agency or to the data subject themselves.

Secure deletion and anonymization: not all deleting is equal

Deleting securely means the data can no longer be recovered, not that it merely disappears from view. Many systems perform a "soft delete": they mark the record as inactive but keep it in the database. That doesn't meet the standard when the goal is to erase the data. Genuine deletion involves effective, irreversible erasure, and accounting for every place the data lives: the main database, exported reports, backups, test environments and the third-party services that process it on your behalf.

Anonymization is the alternative to deletion when you want to preserve analytical value without keeping identifiable people. Anonymizing properly means transforming the data so that it is no longer possible to re-identify the subject by reasonable means, not even by cross-referencing it with other information. This is where the most frequent pitfall lies: pseudonymization (replacing the name with a code but keeping the table that allows it to be reversed) is not anonymization. As long as there is a way back to the person, you are still processing personal data and the law's obligations still apply.

A point that is often forgotten is backups. If you delete data from production but it remains alive in backup copies for months, the deletion is only partial. The practical recommendation is to define a backup policy with its own rotation cycle and document how deleted data eventually disappears from the copies too as they are overwritten or expire.

• A soft delete (marking as inactive) is not the same as deletion: the data still exists.
• Genuine anonymization = reasonable impossibility of re-identification; pseudonymization doesn't count.
• Cover every repository: main database, exports, test environments and third parties.
• Include backups in the plan: define rotation cycles so copies are purged as well.
• Document every bulk deletion by period expiration as evidence of compliance.

Its relationship with the right to erasure (part of ARSOP rights)

Retention has two drivers: yours, when you delete because a period has expired, and the data subject's, when they exercise their right to erasure. Among the ARSOP rights (access, rectification, erasure, objection and portability, plus blocking), erasure (also called cancellation) lets the person ask you to delete their data. If your retention policy is well built, responding to these requests stops being an emergency and becomes an orderly process.

When an erasure request arrives, the practical flow is usually: verify the identity of the requester, locate all of that person's data across your systems (this is where the RoPA is key), assess whether any exception applies that requires or allows you to keep part of the information, carry out the secure deletion of what applies, and inform the subject of what you did. If you delegated processing to processors or vendors, as a good accountability practice you should propagate the deletion instruction to them.

The law recognizes these rights and expects the controller to have channels and procedures to handle them in a timely manner. Rather than fixating on an exact number of days, focus on having a documented process, with clear owners and defined internal timeframes, that lets you respond promptly and demonstrably. A company that doesn't know where a person's data is cannot delete it, and that blindness is itself a compliance problem.

Exceptions: when you can indeed keep data

The right to erasure is not absolute, and neither is the duty to delete. There are situations in which keeping data is legitimate and even mandatory, even if the subject asks otherwise or the active-use period has expired. Recognizing these exceptions, in line with what the law and its regulations provide, saves you from two opposite mistakes: deleting something you must keep, or using the exception as an excuse to retain everything indefinitely.

The clearest exception is compliance with legal obligations. Tax, labor, accounting or sector-specific rules may require certain records to be kept for defined periods; in those cases, the basis that justifies the processing is not consent but the legal obligation, and it prevails over a deletion request for those specific data. Another situation is the defense against claims or active legal actions, which may justify keeping information for as long as the risk or the proceeding exists.

The law also generally contemplates processing for historical, statistical or research purposes, which may allow data to be kept beyond its original purpose, ideally applying safeguards such as anonymization or dissociation where possible. The key across all exceptions is proportionality: the exception covers only the data strictly necessary for that specific purpose, not your entire database. If you can meet the legal obligation by keeping five fields, don't keep twenty.

• Legal obligations (tax, labor, accounting) may require records to be kept for defined periods.
• Defense against active claims or litigation may justify the temporary retention of related data.
• Historical, statistical or research purposes may allow retention, preferably with anonymized or dissociated data.
• The exception covers only the data necessary for that purpose, not the person's entire record.
• Always document which exception you invoke and why, so you can justify it to the Agency or the subject.

Frequently asked questions

Is there a single retention period for all data under Law 21.719?

No. The law does not set a single, general period. The criterion is to keep data only for as long as it is necessary for the purpose that justified its collection, or for as long as an exception (such as a legal obligation) requires. That's why each data category has its own period, which you define and justify case by case.

What is the difference between deleting and anonymizing data?

Deleting means erasing the data securely and irreversibly, so that it ceases to exist. Anonymizing means transforming it so that it is no longer possible to re-identify the person by reasonable means; the data still exists, but it stops being personal data. Anonymizing properly lets you keep statistical value without keeping identifiable people. Note: replacing the name with a reversible code is pseudonymization, not anonymization, and it is still personal data.

If a customer asks me to delete their data, do I always have to erase it?

Not necessarily all of it. You must handle the erasure request, but you may (or must) keep the portion of the information covered by a legitimate exception, such as compliance with a tax or accounting legal obligation, or defense against an active claim. The right approach is to delete what is not protected by an exception, keep only what is strictly necessary, and explain to the subject what was done.

Does data in backups also count for deletion?

Yes. Data deleted from production but still alive in backup copies is not truly deleted. The recommended practice is to have a backup policy with defined rotation cycles, so that deleted data also disappears from the copies as they are overwritten or expire, and to document how that process happens.

Which data requires greater rigor in its deletion timeframe?

Sensitive data: in Chile this includes, among others, health, racial or ethnic origin, beliefs or convictions, biometric data (such as facial recognition), sex life and sexual orientation, political or union affiliation and, distinctively, socioeconomic status. Given their greater potential for harm, it is advisable to apply tighter timeframes, stricter access controls and more demanding deletion criteria.

How do I prove to the Agency that I comply with retention and deletion?

With documentation. You need a retention policy by category, an up-to-date Record of Processing Activities (RoPA), and evidence that deletions and anonymizations actually take place (purge logs, assigned owners, dates). The accountability the law requires is demonstrated by showing rules that exist and are applied, not just good intentions.