Data processing agreements (DPAs) with processors: how to share data with vendors without breaching Law 21.719

Few organizations process their personal data in isolation. Day-to-day operations depend on vendors: email and files live in the cloud, payroll is calculated by a third party, debt collection is managed by an external company, campaigns are run by an agency, and customer service is operated by a call center. At each of these points you are handing the personal data of your customers, employees, or users to a third party. If you want the full legal picture, start with the definitive guide to Law 21.719. If you want the full picture, start with our guide to the data protection law in Chile.

Law 21.719, published on December 13, 2024 and with full enforcement starting December 1, 2026, requires that this handover be governed. The instrument that does so is the data processing agreement, also known by its English acronym DPA. In this article you will see the difference between a controller and a processor, when you need this agreement, and which clauses cannot be missing.

Controller and processor: who decides and who executes

Law 21.719 distinguishes two key roles that determine the obligations of each party. The data controller is the one who decides the purposes and the means: it defines what the data is used for, what is collected, and under what conditions. The processor, on the other hand, is the one who processes the data on behalf of the controller, following its instructions, without deciding on its own what becomes of that information.

The difference is not theoretical. It determines who is liable to the data subjects and to the Personal Data Protection Agency, who handles ARSOP rights, and who bears the duty to notify breaches. Confusing the two roles, or failing to document who is who, is one of the most frequent failures we detect in audits.

In practice, most of your technology and operational vendors act as processors.

• Cloud and software vendors (hosting, CRM, ERP, email, storage).
• Payroll or compensation-calculation companies.
• Debt-collection companies that manage your portfolio.
• Marketing agencies and email or advertising platforms.
• Call centers and outsourced customer service or support services.

When you need a data processing agreement

The rule is simple: every time a third party accesses personal data for which you are the controller in order to process it on your behalf, you need a data processing agreement. It does not matter whether the vendor is domestic or international, nor whether the service is large or small; what triggers the obligation is that a processor has access to that data in order to provide you with a service.

It is not always obvious. A ticketing system that stores customer emails, an analytics tool that receives user identifiers, or a backup vendor that stores your databases are processors, even if the data is not their core business. The right question is not whether the vendor uses the data, but whether it can access it.

A good starting point is to build your Record of Processing Activities (RAT) and cross-reference it with your list of vendors. Wherever a data flow crosses over to a third party, there must be an agreement governing that processing. This mapping also feeds your Data Protection Impact Assessment (EIPD) when the processing is high-risk.

What the data processing agreement must include

A solid data processing agreement is not a generic clause tacked onto the end of a services contract. It is a specific agreement that delimits what the processor can and cannot do with the data. Law 21.719 is inspired by the European framework, so it is advisable to cover the same pillars that international best practice requires.

These are the elements that, at a minimum, it must contain:

• Purpose and instructions: the processor only processes the data for the purposes defined by the controller and in accordance with its documented instructions. Using it for the processor's own purposes is prohibited.
• Confidentiality: the processor and its personnel maintain the duty of secrecy over the data, even after the relationship has ended.
• Security measures: the processor applies technical and organizational measures appropriate to the risk (access control, encryption where applicable, logs, backups).
• Handling of subprocessors: the processor may not subcontract the processing without the controller's authorization, and must pass on to those subprocessors the same obligations.
• Return or deletion of data: at the end of the service, the processor returns or deletes the data as instructed by the controller, keeping no copies unless required by law.
• Cooperation on ARSOP rights and breaches: the processor must help the controller handle requests for Access, Rectification, Erasure, Objection, and Portability, and notify it without delay of any security breach.

The subprocessor chain: the risk you cannot see

Your vendor rarely works alone. The marketing agency uses an email-sending platform; that platform runs on a third party's cloud; that third party, in turn, may rely on other services. Each link is a subprocessor, and your data travels through that entire chain even though you only signed with the first vendor.

That is why the agreement must expressly govern subcontracting. The recommended approach is to require prior authorization or, at the very least, information about who the subprocessors are and notification when they change. The primary processor must guarantee that each subprocessor assumes the same obligations of security, confidentiality, and purpose that it accepted with you.

Without this clause, you lose visibility and control over where the data ends up. And, as we will see, that loss of control does not release you from liability: it exposes you.

Liability is not transferred: you are liable for the entire chain

This is the point most worth internalizing. Hiring a processor does not transfer your liability. Under the principle of proactive accountability introduced by Law 21.719, the controller must be able to demonstrate that it chose vendors offering sufficient guarantees and that it properly governed each processing activity. If a processor or a subprocessor fails, the controller remains liable to the data subject and to the Personal Data Protection Agency.

This means that due diligence does not end at signing. It involves assessing your vendors before hiring them, keeping the agreements up to date, periodically reviewing their security measures, and retaining evidence of all of this. The agreement is the foundation, but ongoing oversight is what sustains your defense in the event of an enforcement action.

The financial consequence is not minor. The sanctioning regime provides for fines according to the severity of the infringement:

• Minor infringements: up to 5,000 UTM.
• Serious infringements: up to 10,000 UTM.
• Very serious infringements: up to 20,000 UTM.

How to get started before enforcement begins

With full enforcement set for December 1, 2026, the time to put your relationship with vendors in order is running short. The good news is that the process is methodical and can be tackled in stages, without halting operations.

We recommend moving forward in this order, assigning an internal lead or a DPO to coordinate the effort and leave a trace of each step. Documenting the process is, in itself, part of compliance.

• Inventory your vendors: identify every third party that accesses personal data and classify it as a processor.
• Review what has been signed: detect which agreements already exist, which lack processing clauses, and which need to be updated.
• Close contractual gaps: incorporate a data processing agreement with the six pillars in every relationship that requires one.
• Assess guarantees: ask your processors for evidence of their security measures and of how they manage their subprocessors.
• Integrate ARSOP and breaches: ensure channels and timelines so that processors cooperate in handling rights and notifying incidents.
• Oversee continuously: schedule periodic reviews and keep the RAT updated as your vendors change.

Frequently asked questions

What is the difference between a data controller and a data processor?

The controller is the one who decides the purposes and the means of the processing, that is, why and how the data is used. The processor processes it on behalf of the controller and according to its instructions, without deciding on its own. Vendors such as the cloud, payroll, debt collection, marketing, or the call center usually act as processors.

When do I need to sign a data processing agreement with a vendor?

Whenever a third party accesses personal data for which you are the controller in order to process it on your behalf. It applies to domestic and international vendors and to services of any size. What triggers the obligation is not that the vendor uses the data as its business, but that it can access it in order to provide you with the service.

What must a data processing agreement include at a minimum under Law 21.719?

It must set out the purpose and instructions, the duty of confidentiality, the security measures, the handling of subprocessors, the return or deletion of the data at the end of the service, and the processor's cooperation in handling ARSOP rights and notifying security breaches.

If I outsource the processing, do I stop being liable in the event of an infringement?

No. Liability is not transferred. Under the principle of proactive accountability, the controller must demonstrate that it chose vendors with sufficient guarantees and governed each processing activity. If a processor or subprocessor fails, the controller remains liable to the data subjects and to the Personal Data Protection Agency, with fines of up to 20,000 UTM depending on the severity.

What must the contract with a processor contain?

Article 15 bis of Law 21.719 requires setting out the object of the engagement, its duration, the purpose of the processing, the types of personal data processed, the categories of data subjects concerned, and the parties' rights and obligations. Those six elements are the statutory minimum.

What if the supplier uses the data for something else?

Their role and liability change. Article 15 bis of Law 21.719 provides that where the processor handles the data for an object other than the agreed one, or discloses it without authorisation, they will be treated as a controller for all legal purposes, answering personally for infringements and jointly for damages.

Can my supplier subcontract to someone else?

Only with specific written authorisation from the controller, under article 15 bis of Law 21.719. And even when they delegate, the processor remains jointly and severally liable for that engagement: the provision states expressly that they may not escape liability by arguing they delegated the processing.

Are there official model contracts?

The law provides for them. Article 15 bis of Law 21.719 states that the Agency will make model contracts available to the public on its website. Until they are published, the contract must cover the six minimum elements that same article requires on its own.

What happens to the data when the service ends?

Article 15 bis of Law 21.719 settles it without ambiguity: once the third-party agent or processor has completed the processing service, the data in their possession must be deleted or returned to the data controller, as applicable.

Is the processor answerable for data security?

Yes. Article 15 bis of Law 21.719 expressly applies to them the duty of secrecy or confidentiality of article 14 bis and the security duty of article 14 quinquies, and adds that in the event of a breach they must report the fact to the controller.

Official sources

• Law 21.719 on the protection and processing of personal data, creating the Personal Data Protection Agency — official text, Library of the National Congress of Chile
• Article 15 bis (processing through a third-party agent or processor) — consolidated text in force from 1 December 2026

This article is for information purposes only and does not constitute legal advice for a specific case.