How to Write a Privacy Policy Compliant with Law 21.719

If your company collects data from customers, subscribers, or users (and today almost every company does), the privacy policy is one of the most visible parts of your compliance. It is the document where you give effect to the duty to inform required by Law 21.719: every time you request an email, a tax ID, or a contact detail, the person has the right to know who processes that information, for what purpose, and how they can control it. A well-crafted policy reduces legal risk, but above all it builds trust. If you want the full picture, start with our guide to the data protection law in Chile.

Law 21.719 was published in December 2024 and updates the Chilean framework that previously rested mainly on Law 19.628. It takes full effect after a transition period, expected in December 2026, and creates the Personal Data Protection Agency as the supervisory authority. That means you have a window to get your documents in order, and the privacy policy is a good starting point because it touches on nearly all of the law's principles.

In this guide we review what your policy should contain in general terms, how to structure it in layers so it is readable, when to update it, and the most common mistakes, starting with the most frequent of all: copying a European template that does not fit Chile.

What the privacy policy is and why the law requires it

The privacy policy, also called a privacy notice, is the document through which you fulfill the duty to inform and the duty of transparency under Law 21.719. Transparency is one of the law's core principles: when you collect data from a person, you must clearly inform them of what you do with it, not bury it in unreadable terms or assume they already know.

It is worth distinguishing two things that are often confused. The privacy policy is an informational document, addressed to data subjects. It is not the same as your internal record of processing activities or your security procedures, which are inward-facing management tools. The policy is the public face of all that internal work, and that is why it must be faithful to what you actually do: promising something on paper that you do not deliver in practice is a risk, not a safeguard.

It applies to virtually any organization that processes personal data: an SME with a customer base, an e-commerce store that processes orders and payments, a marketing team that manages campaigns and forms, or a legal department that coordinates vendors. If you collect data, you need to inform; and the privacy policy is the standard way to do so.

What it must contain: the elements of the duty to inform

The duty to inform translates, in general terms, into a set of elements the person must be able to know at the moment they hand over their data. Do not treat it as a fixed form, but as the questions your policy must answer clearly.

These are the elements your policy should generally cover:

• Who the controller is: identification of the company that decides on the processing, along with its contact details and, where applicable, those of the data protection officer (DPO).
• What data is processed and for what purpose: describe the categories of data and how you use them, in specific terms. Avoid vague purposes such as "improving the experience."
• The lawful basis: state what you rely on to process each group of data (consent, performance of a contract, legal obligation, legitimate interest, among others).
• Retention period or criterion: how long you keep the data, or the criterion you use to determine it (for example, for the duration of the contractual relationship plus any applicable legal periods).
• Recipients and transfers: if you share data with vendors, processors, or other companies, or if you transfer it outside Chile, state this where relevant.
• How to exercise rights and with whom: explain the ARSOP rights (access, rectification, erasure, objection, and portability), along with blocking, and provide a concrete channel to exercise them.
• Contact details: an email or form where the person can write with questions or to exercise their rights.

The lawful basis: consent is not the only option

One of the points where companies most often go wrong is assuming that all processing requires consent. Law 21.719 recognizes consent as a lawful basis, but not as the only one. There are others that may be more appropriate depending on the case, and using the right basis saves you from requesting unnecessary permissions (or, conversely, from relying on a consent the person can withdraw).

Among the bases the law provides are the performance of a contract or of a relationship to which the subject is a party (for example, processing an order the person placed), compliance with a legal obligation (such as retaining tax documentation), and the controller's legitimate interest, provided it is weighed against the subject's rights. Each instance of processing you describe in your policy should be able to be tied to a clear basis.

In practice, this means drawing up a small map before you write: list the processing activities you carry out (sales, invoicing, newsletter sending, customer service, analytics) and assign each one its basis. That exercise not only improves the policy; it also organizes your internal compliance and prepares you to respond if the Agency or a customer asks why you process certain data.

Plain language and a layered approach

The principle of transparency is not satisfied by a text that is technically complete but impossible to read. The law aims for information to be clear to the person, and here the layered approach is a very useful tool. The idea is simple: first provide a short, visible summary, and offer a detailed document for anyone who wants to go deeper.

The first layer is a short notice, at the point where you collect the data (a form, the checkout, a pop-up), answering the essentials in a few lines: who processes the data, for what purpose, and a link to the full policy. The second layer is the extended policy, where you develop each element of the duty to inform in the necessary detail. This way you don't force anyone to read ten pages to subscribe to a newsletter, but you also don't hide information.

To make the language genuinely clear, it helps to follow a few concrete practices:

• Write in the second person and with short sentences: "we use your email to send you your receipt," not "the subject acknowledges that their data may be subject to processing."
• Use headings and navigable sections, so the person can quickly find what they are looking for (for example, "How to exercise your rights").
• Explain technical terms the first time they appear, instead of assuming they are understood.
• Avoid filler text and generic promises; say what you actually do with the data.

When to update it and common mistakes to avoid

A privacy policy is not a document you write once and forget. You should review it whenever something relevant changes in how you process data: a new purpose, a tool or vendor that begins accessing data, an integration with a third party, a new collection channel, or a change in retention periods. It is also worth doing a routine periodic review, especially while you prepare for the law to take full effect, expected in December 2026.

The most common mistake, and the riskiest, is copying a generic template or text designed for Europe's GDPR. Chile has particularities that an imported template does not capture: socioeconomic situation is sensitive data under Chilean law (something distinctive compared to other frameworks), the supervisory authority is the Personal Data Protection Agency, and on breaches the law requires notifying without undue delay and by the fastest possible means, not within the 72-hour deadline often cited from the European model. A policy that mentions regulations or authorities that do not apply in Chile loses credibility and can be misleading.

Other frequent mistakes worth reviewing before you publish:

• Describing vague or generic purposes that do not reflect the actual use of the data.
• Failing to state the lawful basis, or relying on consent when another basis fits better.
• Omitting the vendors or processors that actually access the data.
• Not offering a clear, functional channel to exercise ARSOP rights.
• Promising security measures or certifications you do not have: the law calls for measures appropriate to the risk, with a proactive accountability approach, not a fixed technical checklist or a specific mandatory certification.
• Leaving the policy out of date relative to what the company does today.

Frequently asked questions

Is a privacy policy mandatory under Law 21.719?

The law establishes a duty to inform and a duty of transparency: when collecting data, you must clearly inform the subject who processes it, for what purpose, on what lawful basis, and how to exercise their rights. The privacy policy is the standard way to fulfill that duty, so in practice it is a document your company needs to have.

Is the privacy policy I already have under Law 19.628 still valid?

It can be a starting point, but it is worth reviewing. Law 21.719 updates the framework, reinforces principles such as transparency and proactive accountability, incorporates rights and lawful bases, and creates the Personal Data Protection Agency. An older policy often falls short on lawful basis, retention criteria, and channels to exercise rights.

Can I use a European GDPR template and adapt it?

Copying it as is is not advisable. There are important differences: in Chile, socioeconomic situation is sensitive data, the authority is the Personal Data Protection Agency, and in the event of a breach the law requires notifying without undue delay and by the fastest means, not within a fixed 72-hour deadline. An unadapted European template may include references that do not apply.

Do I need to request consent for everything?

No. Consent is one lawful basis, but not the only one. There is also the performance of a contract to which the subject is a party, compliance with a legal obligation, and legitimate interest weighed against the subject's rights, among others. The recommended approach is to map each processing activity and assign it the most appropriate basis.

How often should I update the policy?

Whenever something relevant changes in how you process data: new purposes, new vendors or tools that access data, new collection channels, or changes in retention periods. In addition, a routine periodic review is advisable, especially during preparation for the law taking full effect, expected in December 2026.

Should I name a data protection officer (DPO) in the policy?

If your organization has a data protection officer, it is good practice to include their contact details in the policy so that subjects have a clear channel. If you do not have one, you should still provide a functional email or form where people can make inquiries and exercise their rights.