Data Breach Notification Under Law 21.719: A Step-by-Step Guide

A security breach does not distinguish between large and small companies. An email sent to the wrong recipient, a stolen laptop, a ransomware attack, or a misconfigured cloud setting can expose the personal data of your customers, employees, or suppliers. With Law 21.719, which updates Chile's data protection framework and takes full effect in December 2026, data breach notification is no longer an optional best practice and becomes a concrete obligation for your organization. If you want the full picture, start with our guide to the data protection law in Chile.

The difference between a company that responds well and one that runs into trouble is not whether it suffers an incident, because sooner or later almost all of them will. It lies in whether it can recognize the incident in time, contain it, document it, and notify the right parties promptly and with the appropriate information. Improvising in the middle of a crisis tends to worsen both reputational and legal harm.

In this guide we walk through, step by step, what counts as a breach under Law 21.719, when and whom you must notify, what information to include in that notification, how to contain and document the incident, and how to prepare with a response plan you can activate the day you need it.

What Is a Personal Data Security Breach

Under Law 21.719, a breach is any violation of security measures that results in the destruction, leakage, loss, or alteration of personal data, whether accidental or intentional. The key lies in the effect on the data, not solely in the intent of whoever caused it. That is why an internal mistake counts just as much as an external attack.

It is a common misconception to think that a breach only occurs when a hacker is involved. In practice, many incidents originate within the organization itself: a file containing customer data sent by mistake, shared credentials, a poorly protected backup, or the loss of a device. All of these can constitute a breach if they compromise the confidentiality, integrity, or availability of the data.

It helps to structure the analysis by distinguishing three possible types of impact. An impact on confidentiality, when data is accessed or disclosed without authorization. An impact on integrity, when data is improperly altered. And an impact on availability, when data is lost or becomes inaccessible — for example, after ransomware encrypts your systems.

• Confidentiality: unauthorized access to or disclosure of data (leak, misdirected email).
• Integrity: improper alteration or modification of personal data.
• Availability: loss of or inability to access data (deletion, ransomware encryption).

When and Whom You Must Notify

There are two possible recipients, and they do not always coincide. The first is the Personal Data Protection Agency, the new supervisory authority created by Law 21.719. As the data controller, you must notify it of any violations of security measures that result in the destruction, leakage, loss, or alteration of personal data. This communication must be made without undue delay and through the fastest possible channel once you become aware of the incident.

The second recipient is the affected data subjects — that is, the individuals whose data was compromised. You must inform them of the breach when the incident may affect their rights, and with particular reason when sensitive data is involved. In Chile, sensitive data includes, among others, health, biometric data, racial or ethnic origin, beliefs or convictions, sexual life and sexual orientation, and, distinctively, a person's socioeconomic situation.

An important point about timing: Chilean law does not set a rigid deadline in hours like the well-known 72-hour limit of the European regulation (GDPR), which is not part of Chilean legislation. The standard Law 21.719 uses is to notify without undue delay and through the fastest possible channel. In practice, this means acting with reasonable urgency, without waiting for the full forensic analysis before giving the Agency an initial alert.

• To the Agency: when the breach destroys, leaks, loses, or alters personal data.
• To data subjects: when the incident may affect their rights, especially if sensitive data is involved.
• Timing: without undue delay and through the fastest possible channel; do not wait until the investigation is closed for the first alert.

What Information the Notification Must Contain

A useful notification is clear, honest, and actionable. Even if you do not have all the details at the outset, it is best to communicate what you already know and commit to updating the information as the investigation progresses. A timely, partial first notification is preferable to prolonged silence while you wait for complete certainty.

As a general rule and best practice, the communication to the Agency should describe the nature of the incident, the categories and approximate volume of data and affected data subjects, the possible consequences, and the measures you have already taken or plan to take to contain the problem and mitigate its effects. It is also advisable to provide a point of contact — typically the data protection officer or the designated official — so the authority can request further information.

The communication to data subjects serves a different purpose: to give them the tools to protect themselves. That is why it must be written in plain language, avoiding technical jargon, explaining which of their data was affected, what specific risks they face, and what they can do — for example, change passwords, monitor account activity, or be wary of suspicious communications.

• The nature of the incident and when it was detected.
• The categories and approximate volume of data and affected data subjects.
• The possible consequences for the individuals.
• The containment and mitigation measures already taken or planned.
• Contact details for the officer or designated official for follow-up.

How to Contain, Document, and Assess the Incident

Before notifying, your operational priority is to stop the damage. Containment aims to halt the spread: isolating compromised systems, revoking suspicious access or credentials, forcing password changes, and preserving evidence without destroying it. A common mistake is to immediately shut down or reformat equipment, which can erase traces that are key to understanding what happened.

At the same time, document everything from minute one. The principle of proactive accountability recognized by Law 21.719 means you must be able to demonstrate how you acted. Keep a record with the incident timeline: when it was detected, who reported it, which systems and data were affected, what decisions were made, and at what moment. That record is your evidence before the Agency and a source of learning for the future.

With containment underway, assess the severity to decide the scope of the notifications. Weigh the type of data (remember the significance of sensitive data), the number of people affected, how easily that data could be used to harm someone, and the likely consequences. This assessment helps determine whether notifying the Agency is enough or whether you must also inform the data subjects.

• Contain: isolate systems, revoke access, change credentials, and preserve evidence.
• Document: timeline, affected systems and data, decisions, and responsible parties.
• Assess: type of data, volume, likelihood of harm, and consequences for data subjects.

Checklist for Responding in the First Few Hours

Once the incident has occurred, having a clear sequence prevents panic from driving your decisions. This checklist summarizes, in order, the steps your team should be able to execute without improvising. The point is not to memorize it, but to have it written down and rehearsed as part of your response plan.

Keep in mind that several of these steps happen in parallel, not in a strictly linear fashion. While the IT team contains the incident, the data protection officer and the legal team prepare the assessment and the potential notification. Coordination among these areas is precisely what you rehearse before the crisis occurs.

• 1. Detect and log: record the date, time, and how the incident was detected.
• 2. Activate the team: convene IT, the data protection officer, legal, and management.
• 3. Contain: isolate systems, cut off access, and preserve the evidence.
• 4. Assess the scope: what data, how many people, and what level of risk.
• 5. Notify the Agency: without undue delay and through the fastest possible channel.
• 6. Inform the data subjects: if their rights may be affected, especially with sensitive data.
• 7. Document and close: consolidate the record, fix the root cause, and adjust your controls.

How to Prepare with an Incident Response Plan

The best data breach notification is the one you have already prepared before you need it. An incident response plan is a living document that defines roles, responsibilities, communication channels, and concrete steps to act on when something goes wrong. Without it, every incident is resolved by improvisation — and improvising with data tends to be costly.

A good plan assigns, by name, who leads the response, who speaks with the Agency, who coordinates with IT, and who communicates with data subjects or the press if needed. It also sets clear thresholds for deciding when an event escalates into a notifiable incident, and keeps notification templates ready to fill in, so that drafting the communication does not consume valuable hours during the crisis.

Finally, a plan is only useful if it is tested. Run regular drills, train your staff so they know to report an incident as soon as they detect it, and review the plan after every real or simulated event. Preparing in this way is part of the principle of proactive accountability that Law 21.719 requires, and it is what turns a legal obligation into a real capability for your organization.

• Define clear roles: who leads, who notifies the Agency, who communicates with data subjects.
• Set thresholds for deciding when an event is a notifiable incident.
• Keep notification templates ready to fill in.
• Rehearse with drills and update the plan after every real or practice incident.

Frequently asked questions

What is the exact deadline for notifying a breach in Chile?

Law 21.719 does not set a rigid deadline in hours like the 72-hour rule of the European regulation (which does not apply in Chile). It states that you must notify the Agency without undue delay and through the fastest possible channel. In practice, this requires acting with reasonable urgency as soon as you become aware of the incident, without waiting to complete the entire investigation before giving the first alert.

Do I always have to inform the affected data subjects?

Not in every case. Communication to data subjects is required when the incident may affect their rights, and with particular reason when sensitive data is involved, such as health, biometric data, or socioeconomic situation. Notification to the Agency, on the other hand, applies when the breach destroys, leaks, loses, or alters personal data.

Is an email sent to the wrong recipient a breach?

It can be. If that email contained personal data and reached someone who should not have received it, the confidentiality of that data is compromised, which may constitute a breach. The severity and the need to notify will depend on the type of data exposed, the volume, and the risk to the affected individuals.

What happens if I fail to notify a breach that should have been notified?

Failing to comply with the notification duty is a violation of Law 21.719 and can expose your company to penalties from the Agency, in addition to reputational harm. The law provides for violations of varying severity, with fines corresponding to each case. That is why it is best to document each decision well: even when you conclude that an event was not notifiable, that record supports your judgment.

Who within the company should lead the response to a breach?

Ideally a coordinated team, not a single person. The data protection officer or official usually leads and serves as the point of contact with the Agency, supported by IT for technical containment, by the legal team to assess obligations, and by management for communication decisions. All of this should be defined in advance in your incident response plan.

Do I need to have this ready now, or can I wait until December 2026?

It is best to prepare now. Although Law 21.719 takes full effect in December 2026, building a response plan, training the team, and organizing your security measures takes time. Reaching the deadline with processes already tested is far safer than trying to put them together at the last minute or in the middle of a real incident.