- A map of where personal data lives, why it is processed and who owns it
- Customer rights requests handled through one tracked workflow across systems
- Consent and marketing preferences held in one place and respected everywhere
- Personal data removed from logs and traces before they leave applications
- A breach response plan that decides quickly who must be told, and how
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A Chilean retailer sold through stores, a website and an app. It ran a loyalty programme and offered its own store credit card, so alongside names and addresses it held purchase histories, credit decisions and payment behaviour. Over twenty years, teams had built and bought systems under Chile's older data protection law: point of sale, e-commerce, loyalty, card servicing, marketing tools, a data warehouse and a growing set of analytics and AI models. Personal data had been copied into most of them.
Ley 21.719, published in December 2024, replaces that regime: it regulates how personal data is processed and protected and creates a new Personal Data Protection Agency to supervise compliance, handle complaints and impose sanctions12. Its main provisions take effect on 1 December 20261.
Why now. With the effective date weeks away, the company had no single view of its personal data. A bill to postpone the date by a year was reported to be in the Senate, but not enacted3. The board decided to plan for December 2026: the work would be needed either way, and much of it reduced breach risk on its own merits.
What had to be true
- Known: where personal data lives, why it is processed and who owns each system.
- Lawful: a legal basis recorded for each purpose, with consent where needed.
- Answerable: customer requests to access, correct, delete or move their data handled reliably across systems.
- Minimised: data kept only as long as needed, and kept out of places it does not belong, such as logs.
- Ready for incidents: a fast way to decide who must be told about a breach, and how.
- Business as usual: stores, card servicing and marketing keep running throughout.
Architecture
The data catalogue was the backbone. Each system, table and data feed was tagged with the personal data it held, the purposes it served, the legal basis for each purpose and an owner. The rights workflow and retention jobs read from the catalogue, so adding a new system meant registering it once rather than updating every process.
The data flow, end to end
- RequestA customer asks to see, correct or delete their data, in store or online
- VerifyIdentity is confirmed in proportion to the request's risk
- LocateThe catalogue lists every system holding that customer's data
- ActEach system's owner fulfils its part; automated where possible
- CheckExceptions, such as credit records that must be kept, are recorded with reasons
- RespondThe customer receives one answer; the case is kept as evidence
The hard part: deletion, credit records and logs
Deleting without breaking the business. A deletion request cannot simply remove every trace of a customer: card accounts, credit decisions and tax records have their own retention duties. The workflow therefore decided per system and per purpose: marketing profiles and loyalty preferences were deleted, credit records were kept for their required period and flagged so they were no longer used for marketing, and the customer was told which data was kept and why.
Personal data in telemetry. The inventory found customer identifiers, emails and sometimes card fragments in application logs and traces, copied into monitoring tools and kept far longer than the source data. Fixing every application would take years, so personal data was removed centrally: logs and traces flowed through an OpenTelemetry Collector pipeline, where processors masked or dropped sensitive fields before export5. Application teams then fixed the worst sources at their own pace.
Breach decisions under uncertainty. Commentators differ on exactly how the law's breach notification timing will be applied4, so the company designed for speed rather than a deadline: a runbook that uses the catalogue to identify affected data types within hours, including whether credit or other sensitive data is involved, and pre-drafted notices for the Agency and for customers.
Most of the work for a new data protection law is not legal. It is knowing where your data is, and being able to act on it everywhere at once.
How it ran
- Catalogue and tagging
- Rights workflow
- Telemetry redaction
- Confirm data and purposes
- Automate their part
- Retention jobs
- Legal bases per purpose
- Processor contracts
- Breach runbooks
- Request intake in store and online
- Identity checks
- Clear answers
- Inventory systems
- Tag personal data
- Assign owners
- Consent service
- Rights workflow
- Identity checks
- Retention jobs
- Telemetry redaction
- Processor review
- Breach tabletop
- Rights request drills
- Agency-ready evidence
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Plan for December 2026 | Wait for the postponement bill | The work is needed either way and reduces risk now |
| Catalogue as the backbone | Spreadsheets per department | Workflows and retention read from one source |
| One rights workflow | Each system handles its own requests | Customers get one answer; evidence in one place |
| Deletion per purpose with recorded exceptions | Delete everything or nothing | Respects rights and legal retention duties |
| Central telemetry redaction | Fix every application first | Immediate reduction in exposure while teams catch up |
| Design breach response for speed | Design to a specific deadline | Holds whatever interpretation prevails |
What I'd do again, and differently
Again: tag personal data in a catalogue that workflows actually use, rather than a register nobody reads. Differently: include analytics and AI models in the first inventory; training datasets copied from production were the last place anyone looked, and the hardest to clean. Related: data contracts, a consent platform for lending in India, credit AI under Brazil's LGPD and where I work.
If a new data protection law is coming and you cannot yet say where your personal data lives, see my fractional CTO work, or analyse your challenge and bring the result to a call.
- 1Ley 21.719: Regula la protección y el tratamiento de los datos personales y crea la Agencia de Protección de Datos PersonalesBiblioteca del Congreso Nacional de Chile · 13 Dec 2024
- 2
- 3
- 4Chile's New Data Protection Law: What Really ChangesDSN Group · 2026
- 5Collecting OpenTelemetry-compliant Java logs from filesOpenTelemetry blog · 9 Dec 2024