Law 21.719 Security Measures: Which Technical and Organizational Controls Your Company Must Adopt

Law 21.719 modernizes Chile's data protection framework and, among its principles, enshrines the security principle: the controller and the processor must adopt appropriate measures to protect personal data against its destruction, loss, leakage or alteration. With full effect scheduled for December 2026 and the creation of the Personal Data Protection Agency as the supervisory and enforcement authority, security stops being a good intention and becomes an enforceable, auditable obligation. If you want the full picture, start with our guide to the data protection law in Chile.

The good news for IT and security teams is that the law does not impose a rigid technical catalog or require certification against a specific standard. The flip side is that it shifts the responsibility onto your organization: you are the one who must assess the risk, decide which controls are proportionate, and be able to demonstrate that the decision was reasonable. That is the heart of the risk-based approach and of accountability.

In this guide we clearly separate technical from organizational measures, explain how to calibrate them according to risk, and give you a concrete structure for documenting compliance. The goal is not to scare you with penalties, but to give you an actionable framework so you reach December 2026 with a defensible security posture.

What the security principle actually requires

Law 21.719's security principle sets out a general duty: both the controller and the processor must adopt security measures appropriate to the risk in order to protect personal data. In practice, that goal translates into preserving three classic properties of information: confidentiality (only those who should can access it), integrity (data is not altered improperly), and availability (it is accessible when needed).

It is important to understand what the law does not say. It does not provide an exhaustive list of mandatory controls, it does not set an encryption key size, it does not require a specific technology, and it does not force you to obtain a particular certification. Standards such as ISO 27001 or frameworks such as NIST can be valuable references and voluntary best practices, but none is a legal requirement in itself. Adopting them helps demonstrate diligence; not adopting them is not, in itself, a violation.

This flexibility is deliberate: a startup that handles contact emails and a healthcare provider that manages clinical records cannot be held to the same technical standard. What the law asks of you is that the measures be appropriate and proportionate to the actual risk of your processing, and that you be able to explain and defend that appropriateness.

Technical measures versus organizational measures

Data protection rests on two layers that reinforce each other. Technical measures are the controls that live in your systems and infrastructure; they protect data by design and by default. Organizational measures are the rules, roles and processes that govern how people handle that data. Flawless encryption is worthless if any employee can export the entire database without oversight; and the best internal policy is a dead letter if the systems do not make it enforceable.

As a practical reference, these are common examples of each layer (this is not a mandatory legal checklist, but a menu you choose from according to your risk):

The key lies in the combination: almost every real incident combines a technical failure with an organizational one. That is why a mature security posture never invests in tools alone or in policies alone, but in both layers in a coordinated way.

• Technical — Encryption of data in transit and at rest; role-based access control and least privilege; strong authentication (MFA); regular, tested backups; access logging and traceability (logs); pseudonymization or anonymization where possible; network segmentation and patch management.
• Organizational — Internal processing and security policies; definition of roles and responsibilities (including a data protection officer where applicable); regular staff training and awareness; management of and contracts with vendors or processors; incident response plan; physical access controls and data lifecycle management.

The risk-based approach and proportionality

The risk-based approach is the mechanism the law gives you to decide how much to invest in security. Instead of applying the same controls to everything, you assess each processing activity according to the likelihood of an incident occurring and the severity of the harm it would cause to data subjects. The higher the risk, the more demanding the measures; the lower the risk, the proportionately lighter the controls.

Several factors raise the risk and, with it, the expected level of protection: the processing of sensitive data (which in Chile includes, among others, health, biometric data, racial or ethnic origin, political or union affiliation, beliefs or convictions, sex life and sexual orientation, and—distinctively in Chile—socioeconomic status), the volume of data subjects affected, the use of intrusive or profiling technologies, and transfers to third parties. Large-scale processing of health data demands a far higher standard than a newsletter subscriber list.

Proportionality works both ways, and that nuance is liberating for the business: you are not required to implement every conceivable control or to spend without limit. You are required to implement what is reasonable for your risk, and to be able to justify where you drew the line. Documenting that justification is what turns a resource decision into a defensible compliance decision.

How to document compliance (accountability)

Accountability changes the underlying question. Being secure is no longer enough: you have to be able to demonstrate that you made reasonable security decisions. Before the Agency, in front of a client, or after an incident, documentary evidence is what separates a diligent organization from an exposed one. If it is not written down, in practice it is as if it did not exist.

A reasonable compliance file does not need to be a bureaucratic monument. These are the components worth keeping alive and up to date:

Two practical tips. First, date and version everything: a document's evidentiary value depends on being able to show when what was decided. Second, treat this documentation as a cycle, not a one-time project; review it at least once a year and whenever a relevant system, vendor or processing activity changes.

• An inventory or record of processing activities (what data you process, for what purpose, on what lawful basis, and for how long).
• A risk analysis for each processing activity, with the technical and organizational measures chosen and their justification.
• Approved internal policies and procedures (security, access control, incident management, backups).
• Contracts with processors and vendors, including security and confidentiality clauses.
• Operational records: training conducted, backup tests, access reviews and an incident log.
• Impact assessments for higher-risk processing activities, where applicable.

How security connects to breaches and impact assessments

Security measures do not exist in isolation: they are the first line of defense against breaches and a direct input to the impact assessment. A breach is, precisely, a compromise of your security measures that causes the destruction, leakage, loss or alteration of personal data. The stronger your controls, the less likely a breach is to occur and the smaller its scope when it does.

When a breach occurs, Law 21.719 sets out the duty to notify the Personal Data Protection Agency of the compromises to security measures that cause the destruction, leakage, loss or alteration of the data, and to notify affected data subjects when the incident may affect their rights. The law requires doing so without undue delay and through the most expedient means possible. It is worth underscoring something to avoid confusion imported from other frameworks: the Chilean rule does not set the 72-hour deadline found in the European regulation; the applicable standard is the reasonable promptness the law itself requires. This is where your incident response plan stops being a document and becomes critical: detecting, containing, assessing and notifying in time depends on having rehearsed it beforehand.

The impact assessment closes the loop from the other end. It is the exercise of analyzing, before starting a high-risk processing activity, what could go wrong and which security measures mitigate that risk. Put another way: the impact assessment helps define which controls you need, the security measures implement them, and breach management is the safety net that kicks in when something fails despite everything. The three processes feed one another and are best designed as a system, not as separate formalities.

First steps: a checklist to start today

If your organization does not yet have a formal data security posture, you do not need to solve everything at once. The sensible path is to prioritize by risk and move forward in iterations. This checklist orders the first, highest-impact moves ahead of December 2026.

The most common mistake is to start buying tools before understanding what data you have and what risk it represents. Invest in the diagnosis first; the technology comes later, guided by the risk you have identified.

• Build an inventory of processing activities: what personal data you process, where it lives, who accesses it, and for what purpose.
• Classify by sensitivity and risk, flagging sensitive data and high-volume or high-impact processing activities.
• Review the basic technical controls: encryption, MFA, role-based access management, tested backups and access logging.
• Formalize the organizational side: designate owners, approve a security policy, and schedule staff training.
• Get your processors and vendors in order: identify who processes data on your behalf and verify that contracts with security clauses are in place.
• Prepare an incident response plan with roles, containment steps, and criteria for notifying the Agency and data subjects.
• Document every decision and schedule a periodic review: compliance is a cycle, not a milestone.

Frequently asked questions

Does Law 21.719 require certification against ISO 27001 or any technical standard?

No. The law establishes a risk-based security principle, but it does not require any specific certification or impose a closed technical checklist of controls. Standards such as ISO 27001 or frameworks such as NIST are voluntary best practices that can help you demonstrate diligence, but adopting them is your decision, not a legal obligation. What is required is having measures appropriate and proportionate to the risk, and being able to justify them.

What is the difference between a technical measure and an organizational one?

Technical measures live in your systems: encryption, access control, backups, access logging, pseudonymization, strong authentication. Organizational measures live in your processes and people: internal policies, roles and responsibilities, training, vendor contracts and an incident response plan. Both are necessary and complement each other; most real incidents combine a technical failure with an organizational one, so investing in only one layer is not enough.

Do I have a 72-hour deadline to notify a breach, as in Europe?

No. The 72-hour deadline belongs to the European regulation (GDPR), not to Chilean law. Law 21.719 requires notifying the Personal Data Protection Agency without undue delay and through the most expedient means possible, and notifying affected data subjects when the incident may affect their rights. The standard is reasonable promptness; that is why it is advisable to have a tested incident response plan that lets you detect and notify quickly.

How do I demonstrate to the Agency that I comply with the security principle?

With living, dated documentation. What is reasonable includes a record of processing activities, a risk analysis for each activity with the measures chosen and their justification, approved internal policies, contracts with processors, operational records (training, backup tests, access reviews, incident log) and impact assessments where applicable. Under accountability, if it is not documented, it is difficult in practice to demonstrate that it happened.

Do security measures also apply to my vendors?

Yes. Both the controller and the processor have a security duty. If a vendor processes personal data on your behalf (for example, a hosting provider, a CRM or a cloud service), there must be a contract governing that processing and including security and confidentiality obligations. Processor management is itself a key organizational measure: you remain responsible for the data even if a third party carries out the operational processing.

We are an SMB with limited resources—how much should we invest in security?

Whatever is proportionate to your risk. The law does not expect an SMB that handles low-risk data to apply the same controls as a large healthcare institution. You must implement reasonable measures for the type and volume of data you handle, and be able to justify where you drew the line. Start with the diagnosis—what data you have and what its risk is—and prioritize the highest-impact controls: access, backups, basic encryption, training and an incident plan.