Chile Law 21.719: technical compliance manual with Veeam

Today, personal data protection is no longer a conversation that lives only in the legal department. With the effective date of Chile Law 21.719 set for December 1, 2026, IT areas become a critical actor in compliance, and backup, recovery, and incident response plans become auditable evidence in front of the new Personal Data Protection Agency. Fines can reach UTM 20,000 or 4% of annual revenue from sales and services in Chile (around USD 1.2 million at the UTM cap, and up to three times that amount for repeat offenses), forcing us to translate each principle of the law into a concrete technical control, not into a declaration of good intentions.

Important note: This post is a technical interpretation from a Solutions Architect Nerd perspective, not legal advice. The definitive legal analysis for any organization must be performed together with its legal team and, when applicable, with external counsel specialized in personal data protection.

Introduction

#

In Chile, the old Law 19.628 on protection of private life remained for more than two decades without a real supervisory authority, without effective sanctions, and without clearly defined technical obligations for organizations processing personal data. That changes profoundly with the enactment of Law 21.719, published on December 13, 2024, with full effect from December 1, 2026.

The new law brings Chile to the European GDPR standard in terms of data subject rights, controller obligations, sanctions, and, above all, the creation of a Personal Data Protection Agency with real supervisory and sanctioning powers. For IT teams, this means that technical controls over personal data become subject to external audit, and that the documentation supporting each control becomes evidence that can be requested during a supervisory process.

In this context, the Veeam Platform is a key component to implement and evidence several of the principles established by the law, particularly those related to confidentiality, integrity, and availability of personal data. In this post, we will see how each principle maps to specific capabilities of Veeam Backup & Replication, Veeam ONE, and the rest of the stack, with the goal of delivering an auditable matrix that you can take directly to your organization’s documentation management system.

What changes with Law 21.719 versus Law 19.628

#

Before going down to technical controls, it is important to understand what is actually new. The difference between both legal frameworks is not about wording, it is a paradigm shift.

Creation of the Personal Data Protection Agency

#

The Agency is the new autonomous body in charge of supervising compliance with the law, receiving complaints, instructing sanctioning procedures, and issuing general and specific guidelines. Unlike the previous model, where the data subject had to resort to civil courts to enforce their rights, now there is a specialized administrative path and, most relevant for IT, a technical authority that can request documentary evidence of implemented security measures.

Graduated sanctions with real deterrent effect

#

Sanctions are classified into three levels, with a floor from 1 UTM and the caps detailed below (reference: UTM ~$69,611 CLP as of February 2026, equivalent to roughly USD 72):

Minor infringements (Art. 34 bis): up to UTM 5,000, approximately $348 million Chilean pesos (~USD 305K).

Serious infringements (Art. 34 ter): up to UTM 10,000, or alternatively up to 2% of annual revenue from sales and services in Chile for companies that do not qualify as SMEs (whichever results higher). The UTM cap equates to approximately $696 million CLP (~USD 610K).

Very serious infringements (Art. 34 quáter): up to UTM 20,000, or alternatively up to 4% of annual revenue from sales and services in Chile for companies that do not qualify as SMEs (whichever results higher). The UTM cap equates to approximately $1,392 million CLP (~USD 1.2 million), plus the possibility of suspending processing operations.

Repeat offenses: fines can be tripled when serious or very serious infringements recur, reaching up to UTM 60,000 (~USD 3.6 million).

Special regime for SMEs (adaptation period): during the first year of full effect of the law (December 1, 2026 to December 1, 2027), small and medium enterprises are only subject to written warning for their infringements, not to fines. This is a meaningful adaptation margin for the Chilean SME segment, but it does not exempt them from the prior implementation work: the Agency will start documenting non-compliance from day one, and at the end of the grace period those records become part of the company’s history.

The omission of reasonable security measures, international transfer without adequate guarantees, and failure to notify a breach in time all fall within the range of serious or very serious infringement.

Data Protection Officer (DPO) obligation

#

Organizations that perform massive personal data processing or habitual processing of sensitive data must designate a Data Protection Officer. While the role is typically led by the legal or compliance area, the DPO requires permanent technical support from IT to validate that the controls declared in the Record of Processing Activities (ROPA) match operational reality.

Data Protection Impact Assessments (DPIA) for high-risk processing

#

Before starting a processing activity that may generate high risk to data subject rights, for example automated decisions, profiling, large-scale processing of sensitive data, or wide-scale video surveillance, the organization must perform an Impact Assessment. This point has a direct technical implication: any new backup or replication architecture involving sensitive data or international transfer must go through a documented DPIA before implementation.

Mandatory 72-hour breach notification

#

Art. 14 sexies states that when a security breach affecting personal data is detected, the controller must notify the Agency within a maximum of 72 hours from knowledge of the breach. And depending on severity, the affected data subjects as well. This is the point that generates the most technical pressure, because it forces organizations to have real detection, containment, and communication capabilities within a very tight timeframe.

How it compares with GDPR: what we already have advanced and what needs adjustment

#

For organizations already operating under GDPR, typically because they have subsidiaries in Europe, European clients, or because they voluntarily adopted the standard, the good news is that most of the technical work is already done. Law 21.719 takes the GDPR model as reference and replicates almost all of its principles, rights, and obligations. What changes is the detail, jurisdiction, and in some cases the deadlines.

What stays almost identical

#

• Processing principles: lawfulness, fairness, transparency, specific purpose, minimization, accuracy, storage limitation, integrity and confidentiality, and demonstrable accountability. The seven principles match one to one.

• Data subject rights: access, rectification, erasure (right to be forgotten), objection, portability, and restriction of processing. They remain essentially unchanged.

• DPIA and DPO for high-risk processing and for organizations that process massive or sensitive data.

• 72-hour breach notification from knowledge of the event.

• International transfer mechanisms: standard clauses, BCRs, countries with adequate level, data subject consent in specific cases.

• Controller and processor regime with established minimum contractual obligations.

Relevant differences we do need to adjust

#

• Sanction amounts: GDPR reaches up to 4% of global annual turnover or EUR 20 million (whichever is greater). Law 21.719 reaches up to UTM 20,000 (~USD 1.2 million) or 4% of annual revenue from sales and services in Chile (whichever is greater for non-SME companies), with tripling for repeat offenses up to UTM 60,000. The structure is very similar to the GDPR scheme, with the difference that the Chilean revenue calculation is limited to operations in Chile, not global.

• Territorial application: GDPR has extraterritorial application, it applies to any organization processing data of EU residents regardless of where it is established. Law 21.719 has a more limited scope to processing that occurs in Chile or that affects Chilean residents, without the same automatic extraterritorial extension.

• Jurisprudence and official guidance: GDPR has several years of European jurisprudence, decisions from national authorities, and most importantly, European Data Protection Board (EDPB) guidance that clarifies grey areas. Law 21.719 will start with initial Agency guidance, but interpretation will be built up over the first years of application.

• Sensitive data: both laws consider special categories (health, biometric, ethnic origin, political opinions, etc.), but the specific definitions have nuances, particularly in processing by State bodies and applicable exceptions.

• Public sector regime: Law 21.719 establishes a specific regime for State bodies, with nuances in consent, purposes, and lawful bases that differ from the GDPR model.

Practical implication for IT

#

If your organization already complies with GDPR, the technical stack controls, encryption with KMS, immutability, RBAC, justified retention, breach response runbook, ROPA, are reused almost entirely. What changes is the documentation, the contracts with cloud providers, and the regulatory interlocutor. The auditable matrix delivered to the Chilean Agency can be built from documentation that already exists for GDPR, adjusting regulatory references and to the new authority. In practical terms, the Veeam stack that complies with GDPR complies with Law 21.719, and the remaining effort is more legal-administrative than technical.

Why backups stop being an operational topic and become a legal topic

#

There is an installed idea in many organizations that backup is purely an operational topic, owned by the infrastructure area, and that its role before the regulator is secondary. With Law 21.719 this stops being true.

The principle of integrity and confidentiality established in Art. 3 of the law, together with the duty of security in the following articles, requires us to protect personal data against unauthorized loss, alteration, or destruction, whether accidental or intentional. A well-documented backup and recovery strategy stops being a best practice and becomes evidence of compliance. The absence of reasonable measures in this area can be interpreted as a serious or very serious infringement by omission, especially if as a result of a ransomware incident, hardware failure, or human error, there is loss of personal data that was reasonably preventable.

Additionally, facing a breach or an incident, the ability to recover data from a point in time prior to the event is the difference between reporting to the Agency “the data was lost” and “the data was recovered without loss”. The Veeam Platform, with its capabilities for immutability, granular recovery, and automated verification, is the technical response to these scenarios, maintaining the integrity and availability of the protected data.

Confidentiality: end-to-end encryption with Veeam and external KMS

#

The first principle we must attack technically is confidentiality. The law requires that personal data be protected against unauthorized access, both in transit and at rest, including all backup copies.

Encryption in backup jobs

#

Veeam Backup & Replication allows enabling AES-256 encryption at the job level, which means data is encrypted from the moment of backup and remains encrypted in the destination repository, including replicated copies to remote sites or capacity tiers in object storage. It is important to note that encryption must be enabled at the job level, not only at the repository, because repository encryption (when available) only protects against storage access, while job encryption additionally protects data in transit and the data that travels to secondary copies.

Integration with external KMS

#

One of the practices that most differentiates solid compliance from superficial compliance is the separation of responsibilities in key management. If the encryption key lives on the same Veeam Backup Server that runs the backup, then the backup operator has indirect access to data in cleartext, which violates the least privilege principle.

The solution is to integrate Veeam with an external Key Management Service, options include:

• HashiCorp Vault: the option for Kubernetes environments protected with Veeam Kasten. Vault manages encryption keys and secrets for K8s applications covered by the backup, integrating natively with Kasten for the complete cycle of backup, recovery, and cross-cluster replication.

• AWS KMS: when the primary or secondary repository resides in AWS, it is the natural option. Supports CMK with granular IAM policies.

• Azure Key Vault: analogous to the above, for Azure environments. Allows Hardware Security Module (HSM) in the Premium tier.

• Google Cloud KMS: for GCP environments, with CMEK support and project separation.

• KMIP (Key Management Interoperability Protocol): OASIS standard natively supported by Veeam Backup & Replication. Allows integration with any compatible enterprise KMS (Thales CipherTrust, Entrust KeyControl, Fortanix DSM, IBM Security Guardium, among others) without being tied to a specific cloud vendor. It is the natural option when the organization already has its own corporate key management solution and prefers to remain cloud-agnostic, or when sovereignty requirements demand that the key never leave the customer’s infrastructure.

What this integration does is move the key outside the Backup Server, so that decrypting a backup requires authorization from both the Veeam operator and the key custodian in the KMS, with independent audit logs. In other words, no single role has the ability to exfiltrate personal data in cleartext.

Auditable evidence we deliver

#

Facing a supervisory process, the documents that support this control are:

• Export of the job configuration showing that AES-256 encryption is enabled.
• Capture of the KMS audit log showing key usage events (encrypt, decrypt, rotate).
• Documented procedure for periodic key rotation, with frequency justified by the organization’s risk analysis.
• Documented procedure for key revocation in case of compromise, with target times (specific RTO for revocation).

Integrity: Hardened Repository and real immutability, not the marketing kind

#

The second principle we must address is integrity. Here enters the most strategic component of any modern backup architecture: immutability.

Object Lock in Compliance versus Governance mode

#

When we talk about immutability over object storage (S3, Azure Blob with Immutable Policies, Google Cloud Storage Bucket Lock), there are two possible modes:

Governance mode: the object cannot be deleted, but a user with specific elevated privileges (typically with “BypassGovernanceRetention” permission or equivalent) can remove the lock and delete the data.

Compliance mode: the object cannot be deleted by anyone until the configured retention expires. Not even the root user of the cloud account can bypass this lock.

The difference between both modes is not an implementation detail, it is the difference between your immutability being valid before the law or not. Under the principle of integrity and confidentiality of Art. 3 of Law 21.719 and the obligation to adopt reasonable security measures to prevent unauthorized alteration or destruction of data, only Compliance mode is defendable as a sufficient technical measure, because only Compliance mode guarantees that neither an attacker who compromises privileged credentials, nor an insider with administrative access, can delete the backup copies within the declared retention period.

Linux Hardened Repository on-premise

#

For on-premise backups, Veeam offers the possibility of configuring a Linux Hardened Repository. This architecture combines several controls:

• Immutable Filesystem flag: backup files are marked with chattr +i, which prevents their modification or deletion at the filesystem level until the immutability period expires.

• Single Use Credentials: the Backup Server authenticates to the repository only once to write the backup, and afterwards does not store the SSH credentials. This means that if the Backup Server is compromised, the repository credentials are not available to the attacker.

• Repository outside Active Directory domain: the server acting as Hardened Repository must not be joined to the production AD domain, because that would expose it to lateral movements based on domain credential compromise.

Backup Server isolation

#

In addition to the Hardened Repository, the Veeam Backup Server itself must be isolated from the main AD domain, ideally in a dedicated domain or workgroup, with mandatory MFA on the console and granular RBAC so that no operator has simultaneous access to production and to the backup console.

Auditable evidence we deliver

#

• Repository configuration showing that immutability is enabled in Compliance mode.
• Veeam ONE report confirming the percentage of jobs with immutable destination.
• Architecture documentation showing the network and identity isolation of the Backup Server and the Hardened Repository.
• Periodic failed deletion attempt test, with timestamp, as proof that the lock works.

Availability: the 3-2-1-1-0 rule translated into auditable evidence

#

The third principle is availability. Here, the 3-2-1-1-0 rule that the industry has adopted translates directly into a compliance matrix.

• 3 copies of the data.
• 2 different media.
• 1 offsite copy.
• 1 offline or immutable copy.
• 0 errors in verification.

The difference between “we believe the backup works” and “we have monthly evidence that the backup works” is what SureBackup does. SureBackup performs automated and isolated verification of the backup: starts a virtual machine from the copy, validates that the operating system boots, validates that critical services (such as SQL, Active Directory, or Oracle) respond, and generates a report with the result.

The SureBackup report, together with the monthly Veeam ONE reports on effective RPO and RTO, are the documents that are attached to the Record of Processing Activities as formal evidence of the availability control. What the auditor will ask for is not “show me your Backup Server”, it is “show me the twelve monthly verification reports of the last year”.

Right to be forgotten over immutable backups: the operational response with Veeam

#

This is the point that generates the most confusion in organizations, and which deserves a dedicated section because the superficial answer is wrong.

Art. 7 of the law establishes the right of erasure of the data subject: when a person exercises their right to be forgotten over their personal data, because it is no longer necessary for the processing purpose, because consent was revoked without another legal basis, because the processing was unlawful, or by court order, the organization is obliged to delete it within a reasonable period. The problem is that backups by definition are designed to not be deleted selectively. If I have a full backup of a database from last Monday, I cannot “delete John Doe’s row” without invalidating the entire backup. And if the backups are immutable, the problem doubles.

The primary answer: Staged Restore + minimum retention + immutability + documentation

#

For the vast majority of organizations that protect traditional workloads with Veeam (VMs, databases, file shares, SaaS), the combination that defendably complies with the right of erasure under Law 21.719 is the following:

1. Staged Restore to ensure that the active production state reflects the suppression of the data subject’s data. This is the effective and operational control, and where the right to be forgotten is truly fulfilled.
2. Retention at the minimum legal applicable, justified documentally. Historical backups of the data subject exist, but for a limited and demonstrable period in the Record of Processing Activities.
3. Immutability over that same historical backup, demonstrating that during the retention period nobody can access or modify the data subject’s data.
4. Honest documentary record that explicitly recognizes: “the data subject’s data was deleted from the production state on day X via Staged Restore; it persists in historical backups for N months due to legal obligation Y; upon retention expiration it will be automatically deleted; during the period no operations are performed on those backups”.

This combination is the defendable response before the Agency, and is what really applies to the typical Veeam setup protecting mixed workloads. We detail it in depth in the Staged Restore section that follows.

Staged Restore: Veeam’s operational response for the right to be forgotten

#

Veeam Backup & Replication offers, since version 9.5 Update 4, a functionality specifically designed for right-to-be-forgotten flows and selective deletion obligations: Staged Restore.

What Staged Restore does is the following:

1. Recovery to an isolated environment: the VM or workload is restored from the immutable backup to a test or “lab” environment isolated from production, without being exposed to the corporate network.

2. Execution of sanitization scripts: before the VM is published to production, Veeam executes a custom script (PowerShell, Bash, or whatever language is required) that operates on the restored data. For example: delete records of a specific data subject from a database, delete sensitive files, anonymize fields, apply reversible or irreversible transformations.

3. Publication of sanitized state: once the script terminates successfully, the sanitized workload is published to production replacing the previous state.

4. Complete record: each Staged Restore is registered in the Veeam job log with timestamp, executed script, exit code, and duration, which serves as operational evidence before the regulator.

This flow does not modify the original backup (which remains immutable), but allows the active production version to comply with the suppression obligation without having to wait for the backup to expire by retention.

Staged Restore use cases aligned with Law 21.719

#

• Right of erasure: delete records of a data subject in production databases from a recent backup, without touching the immutable backup.
• Anonymization: apply transformations (hash, mask, generalization) before migrating data to an environment with lower control level.
• Pre-restore cleanup after an incident: execute AV/EDR verifications, apply critical patches, or sanitize insecure configurations before the VM touches production.
• Contractual compliance with processors: ensure that information shared with a third party does not contain personal data beyond what is strictly necessary.

Secure Restore

#

Along with Staged Restore, Veeam offers Secure Restore, which automatically scans the VM with an antivirus or EDR before publishing it. While its focus is on operational security (anti-ransomware, anti-malware), it also provides complementary evidence to compliance, demonstrating that each restore goes through a formal prior validation and that we are not reintroducing into production a threat that could compromise personal data.

Limitations to keep in mind

#

• Staged Restore operates at the level of a complete VM. For more granular cases, for example deleting a single user from a database table without touching the rest of the workload, it is complemented with Veeam Explorer for Microsoft SQL or the corresponding Explorer, which allows recovery at the application object level.
• For data that lives in SaaS or native cloud services without a Veeam backup agent, the deletion flow must be complemented with the provider’s native APIs (M365, Salesforce, etc.) and with Veeam Backup for Microsoft 365 or Veeam Backup for Salesforce, which do support granular restore and auditable record.
• The sanitization script is the responsibility of the IT team; Veeam executes the script but does not generate the deletion logic. This means that the quality of compliance depends on how well the script is written and on its maintenance over time. I recommend versioning it in the same Git repository of the organization, with review and testing before each productive use.
• Staged Restore acts on the restored state, not on historical backups. For past backups, the correct response is the combination of retention controlled to the minimum legal applicable, immutability during that period, and honest record, there is no technical shortcut to “selectively delete from history” in traditional architectures.

What NOT to do

#

• Do not promise the data subject that their data was deleted from the backup if it actually remains there. The correct statement is that the data has been deleted from the production state and is held in historical backups for the minimum legal period, identifying that period and the legal basis that justifies it.
• Do not assume that Law 21.719 requires immediate physical deletion of history. The law requires reasonable and proportional measures, not impossible ones. Controlled retention + immutability + Staged Restore + honest documentation is a defendable response.
• Do not look for technical shortcuts that promise to “selectively delete from the backup”. In traditional architectures they do not exist. What exists is Staged Restore for the production state and properly managed retention so that history expires in the right time.
• Do not forget that the honesty of the record is what differentiates a defendable process from one that does not withstand supervision. The regulator tolerates an imperfect architecture documented with honesty far better than an “ideal on paper” architecture that does not hold up when scrutinized.

Minimization and storage limitation period

#

The minimization principle requires that we only keep personal data for the time necessary to fulfill the declared processing purpose. In the context of backups, this translates into retention and GFS policies justified documentally.

GFS is not decorative. Each retention period must be supported by a legal, contractual, or operational basis. Some typical examples:

• Accounting data and invoices: 6 years due to tax obligations from the Servicio de Impuestos Internos.
• Critical systems access logs: 1 year for internal compliance and incident traceability.
• Marketing and CRM data: the consent period granted by the data subject, typically between 1 and 3 years with renewal option.
• Health or sensitive data: the period declared in the Record of Processing Activities, typically aligned with applicable sectoral regulation.

Veeam allows configuring GFS policies per job with daily, weekly, monthly, and annual granularity. What is important from a compliance standpoint is that the Veeam ONE retention report matches what is declared in the ROPA, and that any deviation is documented and justified.

72-hour breach notification

#

Art. 14 sexies establishes the obligation to notify the Agency and, depending on severity, the affected data subjects. The 72-hour window counts from knowledge of the breach, not from the breach itself. This means the clock starts when someone within the organization (typically the IT team or SOC) detects the situation. If detection takes days, the 72-hour period counts from that moment, but the detection delay can be interpreted as a monitoring control failure, configuring an additional infringement.

Veeam capabilities for early detection

#

The Veeam Platform incorporates several specific capabilities to shorten detection time:

• Veeam Recon Scanner: automated analysis of backups searching for indicators of compromise, including known IOCs and anomalous behavior in the backed-up data.

• Threat Center: centralized dashboard that correlates security events detected during backups, with prioritization by severity.

• Malware Detection with entropy analysis: automated detection of anomalous encryption in files, characteristic of an ongoing ransomware event.

• Mass deletion alerts: immediate notification when atypical data deletion is detected in backups or in protected workloads.

Runbook connected with NIST 800-61

#

Once the breach is detected, the response flow must be documented and rehearsed. This connects directly with what we already covered in the post on Incident Response Plan with NIST 800-61, 800-53r5, Mitre ATT&CK and Veeam, and with the perimeter detection capabilities of the post on Veeam Decoys - Early Detection.

The recommended flow is:

1. Veeam Detection (Recon Scanner, Threat Center, Decoys, Malware Detection).
2. Analysis and triage of the incident by the CSIRT.
3. Containment through network isolation, credential revocation, and activation of the Hardened Repository as a clean site.
4. Eradication and recovery from the last verified immutable point.
5. Formal notification to the Agency within 72 hours, with the information required by the law (nature, categories, and approximate number of affected data subjects, probable consequences, and measures adopted).
6. Notification to affected data subjects when the breach represents a high risk to their rights.
7. Post-mortem analysis and update of the response plan.

International transfer: every backup that crosses the border is a transfer

#

When we replicate a backup to S3 in us-east-1 or to Azure East-US, we are performing an international transfer of personal data subject to the provisions of Art. 27 and 28 of the law (transfer to countries with an adequate level and standard clauses, respectively), with general supervision established in Art. 29. This is a point that many organizations overlook in the design phase of their backup architecture, and that is very expensive to fix later.

Guarantee mechanisms accepted by the law

#

Law 21.719 admits several mechanisms for an international transfer to be valid:

• Countries with adequate level of protection: the Agency will maintain a list of countries whose legislation is considered equivalent. Until that list is published, the recommended practice is to work with the presumption that most destinations will require additional guarantees.

• Standard clauses: standardized contracts approved by the Agency that are incorporated into the service contract with the cloud provider.

• Binding Corporate Rules (BCR): applicable to intra-group transfers in multinational organizations.

• Express consent of the data subject: applicable in certain specific cases, not recommended as a general basis for backup infrastructure.

Documentation in the ROPA

#

Every international transfer must be reflected in the Record of Processing Activities, identifying the destination country, the provider, the category of data transferred, the purpose of the transfer, and the guarantee mechanism used. If we replicate backups to AWS us-east-1, that must be in the ROPA.

Alternatives to keep data in LATAM

#

A strategy many organizations are adopting is to minimize international transfer by choosing cloud regions or capacity tiers in LATAM. The 2026 landscape looks like this:

• AWS: operational regions in São Paulo and Mexico (Central), with Santiago de Chile announced for end of 2026.
• Azure: operational regions in Brazil South (São Paulo), Brazil Southeast (Rio de Janeiro), Mexico Central (Querétaro), and Chile Central (Santiago) with announced availability and rollout in progress.
• Google Cloud: operational regions in São Paulo and Santiago.
• On-premise object storage with Veeam Hardened Repository + S3-compatible capacity tier (MinIO, Cloudian, Scality, Pure Storage, NetApp StorageGRID) hosted in local provider data centers or on own infrastructure. This is the option that most regulated organizations are choosing when data sensitivity does not allow any exit from the country.
• Veeam Data Cloud Vault as object storage managed by Veeam with default WORM immutability, AES-256 encryption in transit and at rest, logical air-gap from production, and particularly relevant for predictable budgets, flat per-TB pricing that includes API calls, restore, and egress (unlike the pure S3 model where these charges are variable and often surprise on the invoice).

This decision is not only about compliance, it also has impacts on latency and egress cost that must be evaluated case by case. Very important: the mere fact that a provider has a region in LATAM does not mean that your subscription automatically routes data there, the destination region is configured explicitly in the Veeam job and must be documented in the ROPA.

Securiti AI (now part of Veeam): DSPM, privacy operations, and AI trust

#

While Veeam Backup & Replication solidly covers the pillars of integrity, availability, and confidentiality over backed-up data, there are compliance layers that occur upstream of the backup: discovery, classification, privacy governance, data subject rights management, impact assessments, that historically required external tools. That changed in December 2025: Veeam completed the acquisition of Securiti AI for USD 1.725 billion (formal closing on December 11, 2025), incorporating into the portfolio Securiti’s Data Command Center: DSPM, privacy operations, AI governance, under the slogan “first trusted Data Platform”. Rehan Jalil, Securiti founder and CEO, took the role of President of Security and AI at Veeam, and Securiti’s 600 employees joined the team.

In practice, this means that the capabilities I detail below stop being “an integration between two vendors” and become pieces of the same Veeam portfolio, with a single commercial interlocutor, single support, and in the medium term deeper technical integration with VBR, VRO, and the rest of the stack. For an organization building its compliance architecture under Law 21.719, this significantly lowers the friction of adoption.

What Securiti AI solves that VBR does not solve

#

• Data Security Posture Management (DSPM): automated discovery of where personal data lives across the entire organization, databases, data lakes, SaaS, file shares, and cloud storage, with automatic classification by category (personally identifiable data, sensitive data, specially protected data such as health or biometrics). Without this prior discovery, we don’t know what data we are backing up nor to which jobs to apply the strictest policies.

• Automatic classification and labeling: identification of national ID numbers, health data, financial data, minors’ data, biometric data, etc., using pre-trained models. The output of this classification directly feeds the differentiated retention and encryption policies in Veeam.

• Privacy Operations (DSAR): automation of the response flow to data subject requests (Data Subject Access Requests), access, rectification, suppression, portability. This lowers the operational cost of complying with data subject rights from person-days to hours, and leaves an auditable trace of each request and its resolution.

• Consent management: registration and traceability of consent given by each data subject, with direct linkage to the purposes declared in the Record of Processing Activities.

• DPIA automation: assisted workflow to perform Impact Assessments, with templates aligned to multiple regulatory frameworks (GDPR, LGPD, CCPA, and those emerging for Law 21.719).

• Compliance automation and multi-framework mapping: when an organization operates in several countries, Securiti AI allows mapping implemented controls to multiple laws simultaneously, avoiding duplication of documentation effort and maintaining coherence among regulations that share principles but differ in detail.

• AI security and governance: specific capabilities to govern the use of personal data in AI projects, protection of training data, prompt sanitization, traceability of inferences and derived models.

How they integrate in a combined architecture

#

A mature compliance architecture under Law 21.719 combines both layers of the Veeam portfolio operating on distinct but coordinated planes:

1. Securiti AI in the discovery, classification, governance, and privacy operations layer, acting as the intelligence system that knows what personal data exists, where it lives, who processes it, with what purpose, and under what consent.

2. Veeam Backup & Replication + Recovery Orchestrator in the backup, recovery, immutability, and incident response layer, acting as the system that ensures the integrity and availability of that data when something goes wrong.

3. Integration by APIs and tags: the classification produced by Securiti AI translates into differentiated policies in Veeam, jobs with encryption and dedicated KMS for sensitive data, extended retention for data subject to specific legal obligations, replication restricted to LATAM regions for data that does not admit international transfer, Threat Center alerts prioritized according to the regulatory criticality of the compromised dataset. This integration will deepen during 2026 as the portfolio unification progresses post-acquisition.

What additional evidence Securiti AI brings to the regulator

#

Facing a supervisory process, Securiti AI contributes documentation that Veeam cannot generate natively:

• Inventory report of personal data by category and by system, with timestamp and change traceability.
• DSAR log with response times and traceability of the action executed on production systems.
• Mapping of controls to specific articles of Law 21.719 and to analogous frameworks such as GDPR, LGPD, or CCPA.
• Documented DPIAs, archived, and with formal approval flow.
• Consent registry with timestamps, sources, and modification traceability.

The underlying question is not Veeam or Securiti AI, the question is how they complement each other to cover the complete personal data cycle: discover, classify, govern (Securiti AI) → back up, protect, recover (Veeam) → respond and provide evidence to the regulator (both combined).

Additional Veeam capabilities aligned with Law 21.719: VRO, Coveware, Threat Hunter and more

#

Beyond the pillars already covered (encryption with KMS, Hardened Repository, 3-2-1-1-0 rule, Staged Restore, Recon Scanner, Threat Center), the Veeam Platform has several specific capabilities worth knowing because they map directly to the principles of Law 21.719 and to the documentary requirements that the supervisory process will have. Several of these are recent functionalities incorporated in v12.3 (early 2025) and v13 that many organizations have not yet enabled.

Veeam Recovery Orchestrator (VRO): the availability control documented automatically

#

Veeam Recovery Orchestrator is the component that orchestrates disaster recovery and, what is most relevant for our case, automatically generates the documentation the auditor will ask for. Instead of manually maintaining the DR plan, runbooks, and test reports, VRO produces and updates them automatically when the plan is executed or tested.

What it brings for Law 21.719:

• Automated runbooks that detail step by step how to recover critical workloads containing personal data, without depending on the memory of the operator on duty.
• Automated tests with record: DR drills are executed in an isolated environment and leave a dated report of the result, which constitutes formal evidence of the availability control before the regulator.
• Monthly Audit Report with Full Change Tracking (incorporated in v13 of the Platform): records all activities and changes on recovery plans during the month, generating traceability that we will hardly produce by hand.
• Offline malware scanning before recovery: backups are scanned offline before being brought up to production, preventing reintroduction of threats that could compromise personal data in the production environment.
• Compliance dashboards that show the DR compliance status against internally declared SLAs and the timeframes committed in the ROPA.

For an organization that has to demonstrate before the Agency that its availability measures are real and verifiable, VRO is the way to go from “we have a plan” to “here are the monthly reports that demonstrate the plan works and is tested periodically”.

Coveware by Veeam: the response team we activate when prevention fails

#

Veeam acquired Coveware in April 2024 and the brand operates today as Coveware by Veeam. It is a service specialized in response to cyber extortion and ransomware incidents, that is, exactly the scenario that triggers the 72-hour notification obligation under Law 21.719.

What it brings:

• Incident Response Retainer: preventive contract that gives priority access to the response team when the incident occurs. In practice, avoiding the initial “scramble” of searching for and hiring specialists while the crisis is active, which typically burns the first days of the notification period.
• Negotiation with extortion actors when applicable, handled by a team with thousands of closed cases. The decision to negotiate or not is legal and business, but the technical ability to do it or to professionally avoid it is something the average organization does not have internally.
• Forensics and damage assessment: technical analysis of the incident, entry vector, affected data. This information is exactly what the regulator will require as part of the formal breach notification.
• Recon and Unidecrypt: Coveware’s own tools for incident cost analysis and decryption in cases where it is technically possible.
• Integration with Veeam Cyber Secure program: the elite services program of Veeam Data Platform Premium that combines a Ransomware SWAT team available 24/7 with a 30-minute SLA, quarterly security assessments executed by Veeam experts, advanced seven-phase onboarding, and for enrolled clients, up to two incidents per year attended by Coveware at no additional cost.

For Law 21.719 this is particularly relevant because the 72-hour notification is not just “inform the Agency”: it is delivering a technical analysis that makes sense. A typical internal team cannot produce that analysis in three days from scratch. With Coveware on retainer, and even more so if the organization is a Cyber Secure client with a 30-minute SLA, that analysis starts on day zero of the incident.

Veeam Threat Hunter, YARA, and Inline Malware Scanning: detection integrated into the backup engine

#

Since version 12.3 of Veeam Backup & Replication (early 2025), the Platform incorporates detection capabilities that previously required external tools:

• Veeam Threat Hunter: combines scanning with YARA rules, antivirus-style detection, machine learning, and heuristic analysis, all integrated into the backup engine. Detects polymorphic malware that evades traditional signatures. The threat database is updated multiple times daily from Veeam.
• Inline Malware Scanning: the scan occurs during the backup job, not as a subsequent step. If a compromised VM is being backed up with files encrypted by ransomware or with malicious binaries, the alert is immediate and within the job’s own window.
• Indicators of Compromise (IoC) Detection: identifies known attack patterns within backed-up data, fed by integrated threat intelligence.
• Custom YARA rules: the security team can define their own rules to detect threats specific to their industry, environment, or a particular case under investigation.

For Law 21.719, what is critical is the time to detection. Let’s remember that the 72 hours count from knowledge of the breach. Every hour that passes without detecting the incident erodes the time available for an orderly response and to build the formal notification to the Agency. These capabilities significantly lower that detection time and, equally importantly, leave auditable logs of each detection and each false positive dismissed.

Four-Eyes Authorization: enforceable separation of duties

#

Another recent incorporation is Four-Eyes Authorization, which requires the approval of a second authorized operator before executing sensitive operations on the backup infrastructure: deleting jobs, modifying retention policies, disabling encryption, modifying configurations of immutable repositories.

This capability directly attacks the risk of malicious insider and of accidental action with destructive consequences. For Law 21.719, it complies with the principle of “reasonable measures” in role separation, especially for operations that affect retention or deletion of personal data, operations that could otherwise be used to evade compliance or to destroy evidence before the regulator. This connects with the multi-tenant RBAC approach we already covered in the post on Kasten RBAC multi-tenant multi-cluster with Keycloak, where the separation of responsibilities at the platform level is also applied to the backup of Kubernetes workloads.

Each approval is registered in the audit log with both operators identified, date, operation performed, and textual justification when applicable. It is the type of control that an auditor asks to verify directly, and that without Four-Eyes Authorization is built with manual processes that rarely comply 100%.

Auditable matrix and 12-month checklist

#

To close, here is a summary table with the cross “principle of the law → technical control → Veeam component → auditable evidence”, and a milestone checklist so that your organization arrives prepared for December 1, 2026.

How are the technical controls mapped to the principles of Law 21.719?

#

The following matrix translates each principle of the law into a specific technical control, its responsible Veeam component, and the documentary evidence we deliver to the regulator. It is the short and actionable answer to the question that almost all readers will have when arriving here.

12-month checklist

#

• T-12 months (December 2025): implementation and testing of external KMS, integration with Veeam Backup & Replication, definition of key rotation policy.

• T-9 months (March 2026): deployment of Hardened Repository in Compliance mode, migration of critical jobs to immutable destination, validation of network and identity isolation.

• T-6 months (June 2026): execution of DPIA for the backup flow, especially for jobs involving sensitive data or international transfer. Update of the Record of Processing Activities.

• T-3 months (September 2026): complete simulation of breach notification, measuring detection time, containment time, notification time. Adjustments to the runbook based on findings.

• T-1 month (November 2026): external compliance audit, review of all documentation that would be delivered to the Agency in case of an eventual requirement.

• December 1, 2026: full entry into force of Law 21.719.

Frequently Asked Questions

#

When does Law 21.719 enter into force?

#

Law 21.719 was published on December 13, 2024, and enters into full force on December 1, 2026, 24 months after publication. From that date, the Personal Data Protection Agency can supervise compliance and apply sanctions.

What are the maximum sanctions under Law 21.719?

#

Up to UTM 20,000 or 4% of annual revenue in Chile in the highest category (~$1,392M CLP at the UTM cap). Repeat offenses can triple the fine, reaching up to UTM 60,000.

Must SMEs comply with Law 21.719 from day one?

#

Yes, but with an adaptation margin: during the first year of effect (Dec 1, 2026 to Dec 1, 2027), SMEs are subject only to written warning, not to fines. After that period, sanctions apply fully.

How to comply with the right of erasure over immutable backups?

#

For traditional architectures, the defendable response is the combination of Staged Restore (Veeam B&R 9.5 U4+) over the active production state, retention at the minimum legal applicable documented in the ROPA, immutability of the historical backup during that period, and honest record that documents the action before the data subject and the regulator.

What is Staged Restore in Veeam?

#

It is a functionality of Veeam Backup & Replication (since 9.5 Update 4) that allows recovering a VM from the backup to an isolated environment, executing a sanitization script (PowerShell, Bash) on the restored data, for example deleting records of a data subject, anonymizing fields, and publishing the sanitized state to production. The original backup remains immutable.

How does Law 21.719 relate to GDPR?

#

Law 21.719 takes the conceptual model of GDPR and replicates almost all of its principles, data subject rights, DPO obligations, DPIA, and 72-hour breach notification. The main differences are the absolute amount of sanctions, the territorial scope (limited to Chile rather than extraterritorial), and the jurisprudence, which in Chile is just beginning to be built.

Conclusion

#

Law 21.719 finally takes us to a scenario where personal data protection translates into concrete and supervisable technical obligations. For IT areas, and particularly for teams in charge of backup and recovery infrastructure, this represents an opportunity to professionalize and document practices that are often already applied, but were not formalized as compliance evidence.

The good news is that most of the controls the law requires can be implemented and evidenced with the native capabilities of the Veeam Platform: encryption with KMS, real immutability in Compliance mode, RBAC with MFA, justified retention, Staged Restore for the right of erasure, automated detection with Veeam Threat Hunter and Threat Center, periodic verification with SureBackup, orchestration with Veeam Recovery Orchestrator, and specialized response with Coveware by Veeam. What differentiates solid compliance from superficial compliance is the discipline to document each control and keep up to date the auditable matrix we deliver to the regulator.

For Chilean SMEs there is an additional margin during the first year of effect (Dec 1, 2026 to Dec 1, 2027), where infringements are sanctioned only with warning. But that period is not for “starting later”, it is to finish landing what should already be in motion: at the end of the grace period, the accumulated records become part of the history before the Agency.

If your organization does not yet have a clear plan to arrive at December 1, 2026 with the house in order, the recommendation is to start today with the 12-month checklist, and advance systematically and documented. As I always say, in security and resilience there are no shortcuts: either it is done right, or it is not done.

If this post was useful, or if you have questions about how to apply these controls in your specific architecture, write me on LinkedIn.

Related posts

#

• Veeam Hardened (Immutable) Repository
• Veeam Decoys - Early Detection
• Veeam + Kasten
• Veeam Capacity Tier Oracle Cloud Object Storage