An email reaches customer service: someone wants all their data deleted. Support removes them from the CRM and replies that it's done. Three weeks later, the same person gets a quote generated from the ERP. Their national ID number is still in a collections spreadsheet that gets passed around by email, and their full record sits in the backup somebody restored to the test environment back in March. Nobody lied. Nobody knew the data was there.
Complying with Chile's Law 21,719 in your company's IT systems is where most of the work happens. A privacy policy on the website doesn't help much if databases, backups and spreadsheets hold personal data that nobody has on record. The law asks you to respond to data subjects, protect what you process, and delete or anonymize what you no longer need. To do any of that, you first have to know which systems hold each piece of data.
The deadline: what changed this week
Law 21,719 is set to take effect on December 1, 2026. On October 28, the Senate voted 33 to 6 to approve the bill (bulletin 18,623-07) that would push that date to October 15, 2027, as reported by Diario Financiero. The Chamber of Deputies still has to review it. Until it is approved and published, the legal date is still December of this year.
Whatever happens in the Chamber, the technical work stays the same. In a mid-sized company, sorting out where the data lives usually takes several months. If the delay goes through, the extra time lets you do it with less pressure, but the work still has to get done.
Why the inventory has to look at the systems
When a company builds its first personal data inventory, it almost always starts with interviews: each department explains what data it uses. The result describes processes the way people think they work. Once you look inside the databases, things show up that nobody mentioned:
- Free text fields (notes, comments, descriptions) where someone wrote down a diagnosis, a personal phone number or the reason for a medical leave.
- Tables nobody uses anymore and nobody deleted: customers from a business line that closed, job applicants from hiring rounds years ago.
- Copies born out of some emergency that never went away, like Excel exports, production restores in development, or the database a former vendor left behind.
The law doesn't impose a formal inventory as a general obligation. The record of processing activities appears in article 49, as part of the infringement prevention model, which is voluntary. Still, several obligations that apply to everyone assume you know where the data is. To answer an access request you have to find the person in every system, and a deletion has to reach every copy. Security works the same way: if you don't know where the sensitive data is, you can't protect it according to its risk.
Where the data nobody inventoried usually lives
These are the places that come up most often when a company's databases are compared with what had been declared.
| Location | What's usually there | Why it slips through the inventory |
|---|---|---|
| ERP | National ID numbers, addresses, bank details for suppliers and employees, payroll | It's seen as an accounting system, not a personal data system |
| CRM | Contacts, conversation history, sales reps' notes | Free text notes pile up information nobody reviews |
| Backups | Full production copies, sometimes going back years | Since nobody queries them, nobody counts them |
| Development and QA environments | Production restores used for testing | They're created in a hurry and have no owner |
| Spreadsheets and exports | Customer lists, collections, payroll lists | They live in email, shared folders and laptops |
| Integrations and logs | Data moving between systems that ends up in traces | They were built for debugging, not for protecting data |
| Legacy systems | Old databases still running or kept for lookups | Few people really know their data model |
Test environments deserve an article of their own, and we wrote one: Real data in test environments and Law 21,719 lays out three levels of solution depending on how much effort you can put in.
What you can't comply with without that map
Responding to data subjects on time is the first thing that gets hard. The law recognizes the rights of access, rectification, deletion, objection, portability and blocking. Under article 11, once you receive a request you have 30 calendar days to respond, extendable once for another 30, and you must keep proof of your reply. If answering means asking five departments and checking ten systems by hand, that window closes fast.
Then there's retention. The proportionality principle says data is kept only as long as its purpose requires and is then deleted or anonymized, unless another law says otherwise. That calls for a retention rule per data type and something that enforces it automatically. A 2019 backup with the full customer database is unlikely to pass that test.
The security duty requires technical and organizational measures suited to the processing and the type of data. It's hard to encrypt sensitive fields you haven't identified, or restrict access to a table you don't know exists.
If a breach affects personal data, the controller has to report it to the Personal Data Protection Agency without undue delay. To size the impact you'll need to know what data was in the compromised system, and that answer is much easier to have ready before an incident than to piece together during one.
Finally, anonymization. The law defines it as an irreversible procedure: anonymized data is no longer personal data. Pseudonymization can be reversed with additional information, so the data is still personal. That difference decides whether a test environment or an analytics dataset falls inside or outside the law.
If your company handles employee information in occupational safety systems, we covered that case in Your DS 44 system also handles personal data.
How to build a technical inventory without stopping operations
You don't need to audit everything at once. This order tends to work:
- List systems, not processes: ERP, CRM, in-house applications, SaaS platforms, reporting databases, file servers. Include the ones you thought were switched off.
- Look for the data inside the databases. Reviewing schemas and content samples turns up ID numbers, emails, phone numbers and sensitive fields that no interview mentions, and much of it can be automated with queries and patterns.
- Count the copies: backups, replicas, non-production environments, scheduled exports. Note who has access to each one.
- Follow the data outward. Which integrations send information to third parties, to which vendor, and under what contract.
- Prioritize by risk. Sensitive data, volume and the number of people with access decide what gets fixed first.
- Turn the findings into system changes: automatic retention, deletion that reaches every copy, access logging and anonymized test environments.
Many companies stop at step five, with a solid report that nobody turns into changes. Without step six, the next production restore puts everything back where it was.
Frequently asked questions
Does Law 21,719 require a record of processing activities?
Not as a general obligation. The record is part of the infringement prevention model in article 49, which is voluntary. Even so, without knowing where the data is, it's very hard to meet response deadlines, carry out deletions or fulfill the security duty.
Do backups have to comply with the law too?
Yes. A backup containing personal data is still processing of that data. It's worth defining how long backups are kept, who can restore them, and what happens to them when someone asks to be deleted.
Is the delay to October 2027 already in effect?
No. On October 28, 2026, the Senate approved the bill and sent it to the Chamber of Deputies. Until it's published as law, the date in force is December 1, 2026.
Where to start
If you want to know how far your applications and databases are from what the law requires, our free assessment is twelve questions with immediate results by area. To go deeper, Disrupsoft runs a three-week, fixed-price technical assessment that compares what was declared with what your databases actually contain, followed by the development work to close whatever gaps turn up. See how we approach Law 21,719.
