Law 21.663 and data protection in Chile: the new requirements, from the offensive side

In Chile, cybersecurity and data protection have stopped being good practices and become legal obligations. Law 21.663, the Cybersecurity Framework Law, and the new Law 21.719 on personal data protection changed the rules for thousands of organizations.

Most of the articles written about these laws approach them from compliance: what to document, which policies to draft, which forms to fill out. It is a necessary view, but an incomplete one. Because both laws, at their core, do not ask for paperwork: they ask that your security actually work, and that is not something you declare, it is something you prove.

In this article we go over what each law is, what they require, how they connect, and why offensive security (ethical hacking) is the piece that shows that what you state in your policies holds up in practice. Before we start, a note: this is informational content, not legal advice.

Law 21.663: the Cybersecurity Framework

Law 21.663 sets up the institutional framework and the cybersecurity obligations in Chile. It creates the National Cybersecurity Agency (ANCI) as the regulator, with powers to issue standards, oversee and sanction, and it mandates incident reporting through the National CSIRT.

It does not apply to everyone equally. Its focus is essential services (energy, telecommunications, banking and financial services, health, transport, water, digital infrastructure, among others) and, within them, the vital importance operators (OIV), which ANCI designates based on their criticality. If your organization operates in one of those sectors, it is very likely you fall within scope.

The most relevant obligations, especially for vital importance operators, include:

• A continuous information security management system, that identifies risks and assesses their likelihood and impact.
• Operational continuity and cybersecurity plans, certified and reviewed periodically.
• Carrying out continuous review operations, exercises, drills and analysis of networks and systems to detect anything that compromises cybersecurity.
• Reporting incidents with significant impact to the National CSIRT, under demanding deadlines: an early alert within 3 hours, an update within 72 hours and a final report within 15 days.
• Applying security and privacy by design in the systems.

That third point is key, and we will come back to it: the law itself requires you to test your security continuously, not just describe it.

The new personal data protection law (Law 21.719)

In parallel, Chile updated its personal data protection regime with Law 21.719, which replaces the old Law 19.628 of 1999. It modernizes the standard, creates a Data Protection Agency with the power to oversee and fine, and comes into full effect toward the end of 2026.

For what matters here, the law requires, among other things:

• Adopting appropriate technical and organizational security measures to protect personal data.
• Notifying breaches, that is, security violations, to the authority and, where applicable, to the affected individuals.
• Reinforced treatment for sensitive data, such as health data.
• Proactive accountability: not failing is not enough, you also have to be able to demonstrate that the measures were taken.

The same idea shows up again: effective security measures and the ability to demonstrate them.

Two laws, one shared underlying problem

Although they regulate different things, Law 21.663 and the data protection law overlap in practice more than it seems.

A personal data breach is often, at the same time, a cybersecurity incident. If an organization is a vital importance operator and suffers a leak that exposes customer data, the same event can trigger both the reporting duty of Law 21.663 and the breach notification of the data protection law. Two clocks running at once.

And both point to the same technical ground: access controls, information exposure and exploitable vulnerabilities. An authorization flaw like an IDOR or a BOLA, for example, is at once a cybersecurity problem and the door through which personal data leaks out.

The common denominator is clear: both laws demand effective and demonstrable security. And that is where paperwork falls short.

Compliance is not the same as being secure

You can have an impeccable security policy, a documented management system and every form up to date, and still be vulnerable. Compliance on paper describes what should happen; it does not guarantee that it happens.

The way to close that gap between what is declared and what is real is to put it to the test, from an attacker's position. That is exactly what offensive security does, and it is also what Law 21.663 explicitly asks for.

Article 8 requires vital importance operators to carry out exercises, drills and analysis on a continuous basis to detect anything that compromises their security. Article 11 empowers ANCI to require tests that prove the continuity and cybersecurity plans actually work. And the principle of security by design pushes for validating systems while they are being built, not afterward.

Put another way: ethical hacking is not an extra that the law tolerates, it is a direct way to comply with what the law mandates.

One point that is sometimes misread is worth clarifying. The law mentions a responsible response principle that prohibits offensive operations; that principle refers to the State's response to incidents, not to the pentesting that an organization commissions on its own systems and with its authorization. Consented ethical hacking is legal and is, precisely, what good practices promote.

What ethical hacking adds that compliance does not

Compliance and offensive security do not compete: they complement each other. Compliance defines what has to be achieved; offensive security demonstrates whether it was achieved.

A well-run offensive exercise answers questions that no document answers:

• Do access controls really stop one user from seeing another's data?
• Does a chain of vulnerabilities allow reaching the customer database from the internet?
• Do your defenses hold, or do they only exist in the diagram?
• If a reportable incident occurred, what personal data would be exposed and with what impact?

Those answers are what feed a management system that actually works, a precise incident notification and a remediation prioritized by what truly matters.

How Quarancle helps, from the offensive side

At Quarancle we work from offensive security: we find and report real vulnerabilities before an attacker uses them or they trigger an incident.

And we do it keeping these laws in mind. When we run an exercise and report each finding, we consider its impact on personal data, the exposure that could trigger a notification duty, and prioritization based on what most exposes your organization. Our reports are meant for your team to act on, not to fill a folder.

Now, let's be clear about what we do not do: we are not a compliance consultancy and we do not draft the legal documentation to satisfy these laws. That function belongs to your legal, compliance or data protection officer. Our part is the technical, offensive side, and it feeds directly into that posture: the evidence that tests were carried out, which Law 21.663 requires; the validation that controls hold; and the concrete findings your team needs to fix before a regulator or an attacker shows up.

In summary

Law 21.663 and the new data protection law raise the cybersecurity bar in Chile, and they do it by asking for more than documents: they ask for security that works and that can be demonstrated.

Compliance is not the same as being secure. The law tells you what you have to achieve; a well-conducted offensive security exercise tells you whether you actually achieved it, by testing your controls the way a real adversary would. That is the contribution no form can replace.

This article is informational content and does not constitute legal advice. For the specific scope and obligations that apply to your organization, consult your legal or compliance team.