Ley 21.719 en Chile: manual técnico de cumplimiento con Veeam

Hoy en día, la protección de datos personales dejó de ser una conversación que vive solo en el área legal. Con la entrada en vigencia de la Ley 21.719 el 1 de diciembre de 2026, las áreas de IT se convierten en un actor crítico del cumplimiento, y los planes de respaldo, recuperación y respuesta a incidentes pasan a ser evidencia auditable frente a la nueva Agencia de Protección de Datos Personales. Las sanciones, que pueden llegar a las UTM 20.000 o al 4% de los ingresos anuales por ventas y servicios en Chile (alrededor de $1.392 millones de pesos chilenos en su tope UTM, y hasta tres veces ese monto por reincidencia), nos obligan a traducir cada principio de la ley a un control técnico concreto, no a una declaración de buenas intenciones.

Nota importante: Este post es una interpretación técnica desde el rol de Solutions Architect Nerd, no constituye asesoría legal. El análisis legal definitivo de cualquier organización debe realizarse en conjunto con sus equipos jurídicos y, según corresponda, con asesoría externa especializada en protección de datos personales.

Introducción

#

En Chile, la antigua Ley 19.628 sobre protección de la vida privada quedó por más de dos décadas sin una autoridad de control real, sin sanciones efectivas y sin obligaciones técnicas claramente definidas para las organizaciones que tratan datos personales. Esto cambia de forma profunda con la promulgación de la Ley 21.719, publicada el 13 de diciembre de 2024, que entra en plena vigencia el 1 de diciembre de 2026.

La nueva ley nos lleva al estándar GDPR europeo en términos de derechos del titular, obligaciones del responsable del tratamiento, sanciones y, sobre todo, la creación de una Agencia de Protección de Datos Personales con potestades fiscalizadoras y sancionatorias reales. Para las áreas de IT, esto significa que los controles técnicos sobre los datos personales pasan a ser objeto de auditoría externa, y que la documentación que respalda cada control se convierte en evidencia que puede ser requerida en un proceso de fiscalización.

En este contexto, la Plataforma de Veeam es un componente clave para implementar y evidenciar varios de los principios establecidos por la ley, en particular los relacionados con confidencialidad, integridad y disponibilidad de los datos personales. En este post, veremos cómo se mapea cada principio con capacidades concretas de Veeam Backup & Replication, Veeam ONE y el resto del stack, con el objetivo de entregar una matriz auditable que puedas llevar directamente al sistema de gestión documental de tu organización.

Lo que cambia con la Ley 21.719 frente a la Ley 19.628

#

Antes de bajar a controles técnicos, es importante entender qué es lo realmente nuevo. La diferencia entre ambos cuerpos legales no es de redacción, es de paradigma.

Creación de la Agencia de Protección de Datos Personales

#

La Agencia es el nuevo organismo autónomo encargado de fiscalizar el cumplimiento de la ley, recibir denuncias, instruir procedimientos sancionatorios y emitir instrucciones generales y particulares. A diferencia del modelo anterior, donde el titular debía recurrir a tribunales civiles para ejercer sus derechos, ahora existe una vía administrativa especializada y, lo más relevante para IT, una autoridad técnica que puede solicitar evidencia documental sobre las medidas de seguridad implementadas.

Sanciones graduadas con efecto disuasivo real

#

Las sanciones se clasifican en tres niveles, con un piso desde 1 UTM y los topes que se detallan a continuación (referencia: UTM ~$69.611 CLP a febrero 2026):

Infracciones leves (Art. 34 bis): hasta UTM 5.000, aproximadamente $348 millones de pesos chilenos (~USD 305 mil).

Infracciones graves (Art. 34 ter): hasta UTM 10.000 o, alternativamente, hasta el 2% de los ingresos anuales por ventas y servicios en Chile para empresas que no califiquen como PyME (lo que resulte mayor entre ambos cálculos). El tope UTM equivale aproximadamente a $696 millones de pesos chilenos (~USD 610 mil).

Infracciones gravísimas (Art. 34 quáter): hasta UTM 20.000 o, alternativamente, hasta el 4% de los ingresos anuales por ventas y servicios en Chile para empresas que no califiquen como PyME (lo que resulte mayor entre ambos cálculos). El tope UTM equivale aproximadamente a $1.392 millones de pesos chilenos (~USD 1,2 millones), además de la posibilidad de suspensión de las operaciones de tratamiento.

Reincidencia: las multas pueden triplicarse cuando se acreditan infracciones graves o gravísimas reiteradas, alcanzando hasta UTM 60.000 (~USD 3,6 millones).

Régimen especial para PyMES (período de adaptación): durante el primer año de vigencia plena de la ley (1 de diciembre de 2026 al 1 de diciembre de 2027), las pequeñas y medianas empresas están sujetas únicamente a amonestación escrita por sus infracciones, no a multa. Este es un margen de adaptación significativo para el segmento PyME chileno, pero no exime del trabajo de implementación previo: la Agencia comenzará a documentar los incumplimientos desde el día uno, y al cierre del período de gracia esos antecedentes pasan a ser parte del historial de la empresa.

La omisión de medidas de seguridad razonables, la transferencia internacional sin garantías adecuadas y la falta de notificación oportuna de una brecha caen, todas ellas, dentro del rango de infracción grave o gravísima.

Obligación de Delegado de Protección de Datos (DPO)

#

Las organizaciones que realizan tratamiento masivo de datos personales o tratamiento habitual de datos sensibles deben designar un Delegado de Protección de Datos. Si bien el rol es típicamente liderado por el área legal o de cumplimiento, el DPO requiere apoyo técnico permanente del área de IT para validar que los controles declarados en el Registro de Actividades de Tratamiento (RAT) coinciden con la realidad operacional.

Evaluaciones de impacto (DPIA) para tratamientos de alto riesgo

#

Antes de iniciar un tratamiento que pueda generar un alto riesgo para los derechos de los titulares, por ejemplo, decisiones automatizadas, perfilamiento, tratamiento masivo de datos sensibles o videovigilancia a gran escala, la organización debe realizar una Evaluación de Impacto. Este punto tiene una implicancia técnica directa: toda nueva arquitectura de respaldo o replicación que involucre datos sensibles o transferencia internacional debe pasar por una DPIA documentada antes de implementarse.

Notificación obligatoria de brechas en 72 horas

#

El Art. 14 sexies establece que cuando se detecta una brecha de seguridad que afecta datos personales, el responsable debe notificar a la Agencia en un plazo máximo de 72 horas desde el conocimiento de la brecha. Y según la gravedad, también debe notificar a los titulares afectados. Este punto es el que más presión técnica genera, porque obliga a las organizaciones a tener capacidad real de detección, contención y comunicación dentro de un plazo muy acotado.

Cómo se compara con GDPR: lo que ya tenemos avanzado y lo que necesita ajuste

#

Para las organizaciones que ya operan bajo GDPR, típicamente porque tienen filiales en Europa, clientes europeos o porque adoptaron el estándar de forma voluntaria, la buena noticia es que gran parte del trabajo técnico ya está hecho. La Ley 21.719 toma el modelo GDPR como referencia y replica casi todos sus principios, derechos y obligaciones. Lo que cambia es el detalle, la jurisdicción y, en algunos casos, los plazos.

Lo que se mantiene casi idéntico

#

• Principios del tratamiento: licitud, lealtad, transparencia, finalidad específica, minimización, exactitud, limitación del plazo de conservación, integridad y confidencialidad, y responsabilidad demostrable. Los siete principios calzan uno a uno.

• Derechos del titular: acceso, rectificación, supresión (olvido), oposición, portabilidad y limitación del tratamiento. Se mantienen prácticamente sin modificaciones.

• DPIA y DPO para tratamientos de alto riesgo y para organizaciones que tratan datos masivos o sensibles.

• Notificación de brechas en 72 horas desde el conocimiento del evento.

• Mecanismos de transferencia internacional: cláusulas tipo, BCR, países con nivel adecuado, consentimiento del titular en casos puntuales.

• Régimen de responsable y encargado del tratamiento con obligaciones contractuales mínimas establecidas.

Diferencias relevantes que sí debemos ajustar

#

• Sanciones: GDPR llega hasta el 4% de la facturación anual global o EUR 20 millones (el mayor de los dos). Ley 21.719 llega hasta UTM 20.000 (~USD 1,2 millones) o el 4% de los ingresos anuales por ventas y servicios en Chile (lo que resulte mayor para empresas no PyME), con triplicado por reincidencia hasta UTM 60.000. La estructura es muy similar al esquema GDPR, con la diferencia que el cálculo de revenue chileno se acota a operaciones en Chile, no global.

• Aplicación territorial: GDPR tiene aplicación extraterritorial, aplica a cualquier organización que trate datos de residentes en la UE, sin importar dónde esté establecida. Ley 21.719 tiene un alcance más acotado al tratamiento que ocurre en Chile o que afecta a residentes chilenos, sin la misma extensión extraterritorial automática.

• Jurisprudencia y guía oficial: GDPR cuenta con varios años de jurisprudencia europea, decisiones de autoridades nacionales y, sobre todo, guías del European Data Protection Board (EDPB) que aclaran zonas grises. La Ley 21.719 partirá con guías iniciales de la Agencia, pero la interpretación se construirá durante los primeros años de aplicación.

• Datos sensibles: ambas leyes consideran categorías especiales (salud, biométricos, origen étnico, opiniones políticas, etc.), pero las definiciones específicas tienen matices, particularmente en el tratamiento por órganos del Estado y en las excepciones aplicables.

• Régimen para el sector público: la Ley 21.719 establece un régimen específico para órganos del Estado, con matices en consentimiento, finalidades y bases de licitud que difieren del modelo GDPR.

Implicancia práctica para IT

#

Si tu organización ya cumple GDPR, los controles técnicos del stack, encryption con KMS, inmutabilidad, RBAC, retention justificada, runbook de respuesta a brechas, RAT, se reutilizan prácticamente en su totalidad. Lo que cambia es la documentación, los contratos con proveedores cloud y el interlocutor regulatorio. La matriz auditable que entregamos a la Agencia chilena se puede construir a partir de la documentación que ya existe para GDPR, ajustando referencias normativas y al nuevo organismo. En términos prácticos, el stack Veeam que cumple GDPR cumple Ley 21.719, y el esfuerzo restante es de tipo legal-administrativo más que técnico.

Por qué los respaldos pasan de ser un tema operativo a ser un tema legal

#

Existe una idea instalada en muchas organizaciones de que el respaldo es un tema puramente operacional, propiedad del área de infraestructura, y que su rol frente al regulador es secundario. Con la Ley 21.719 esto deja de ser cierto.

El principio de integridad y confidencialidad establecido en el Art. 3 de la ley, junto con el deber de seguridad de los artículos siguientes, nos obliga a proteger los datos personales contra pérdida, alteración o destrucción no autorizada, ya sea accidental o intencional. Una estrategia de respaldo y recuperación bien documentada deja de ser una buena práctica y se convierte en evidencia de cumplimiento. La ausencia de medidas razonables en este ámbito puede ser interpretada como una infracción grave o gravísima por omisión, especialmente si producto de un incidente de ransomware, falla de hardware o error humano se produce una pérdida de datos personales que era razonablemente prevenible.

Adicionalmente, frente a una brecha o un incidente, la capacidad de recuperar datos desde un punto en el tiempo previo al evento es la diferencia entre informar a la Agencia “se perdieron los datos” y “los datos fueron recuperados sin pérdida”. La Plataforma de Veeam, con sus capacidades de inmutabilidad, recuperación granular y verificación automatizada, es la respuesta técnica frente a estos escenarios, manteniendo la integridad y disponibilidad de los datos protegidos.

Confidencialidad: encryption end-to-end con Veeam y KMS externo

#

El primer principio que debemos atacar técnicamente es la confidencialidad. La ley exige que los datos personales estén protegidos contra accesos no autorizados, tanto en tránsito como en reposo, incluyendo todas sus copias de respaldo.

Cifrado en jobs de respaldo

#

Veeam Backup & Replication permite habilitar cifrado AES-256 a nivel de job, lo que significa que los datos quedan cifrados desde el momento del respaldo y permanecen cifrados en el repositorio de destino, incluyendo las copias replicadas a sitios remotos o capacity tiers en object storage. Es importante notar que el cifrado debe habilitarse en el job, no solo en el repositorio, porque el cifrado en el repositorio (cuando existe) protege únicamente contra acceso al storage, mientras que el cifrado en el job protege adicionalmente los datos en tránsito y los datos que viajan a las copias secundarias.

Integración con KMS externo

#

Una de las prácticas que más diferencia un cumplimiento sólido de uno superficial es la separación de responsabilidades en la gestión de llaves. Si la llave de cifrado vive en el mismo Veeam Backup Server que ejecuta el respaldo, entonces el operador del respaldo tiene acceso indirecto a los datos en claro, lo que viola el principio de mínimo privilegio.

La solución es integrar Veeam con un Key Management Service externo, opciones como:

• HashiCorp Vault: la opción para entornos Kubernetes protegidos con Veeam Kasten. Vault gestiona las llaves de cifrado y los secretos de las aplicaciones K8s cubiertas por el respaldo, integrándose nativamente con Kasten para el ciclo completo de backup, recovery y replicación cross-cluster.

• AWS KMS: cuando el repositorio principal o secundario reside en AWS, es la opción natural. Soporta CMK con políticas de IAM granulares.

• Azure Key Vault: análogo al anterior, para entornos Azure. Permite Hardware Security Module (HSM) en la opción Premium.

• Google Cloud KMS: para entornos GCP, con soporte CMEK y separación de proyectos.

• KMIP (Key Management Interoperability Protocol): estándar OASIS soportado de forma nativa por Veeam Backup & Replication. Permite integrarse con cualquier KMS empresarial compatible (Thales CipherTrust, Entrust KeyControl, Fortanix DSM, IBM Security Guardium, entre otros) sin atarse a un vendor cloud específico. Es la opción natural cuando la organización ya tiene una solución de gestión de llaves corporativa propia y prefiere mantenerse cloud-agnostic, o cuando los requerimientos de soberanía exigen que la llave nunca abandone la infraestructura del cliente.

Lo que hace esta integración es mover la llave fuera del Backup Server, de modo que para descifrar un respaldo se requiere autorización tanto del operador de Veeam como del custodio de la llave en el KMS, con audit log independiente. Es decir, ningún rol único tiene la capacidad de exfiltrar datos personales en claro.

Evidencia auditable que entregamos

#

Frente a un proceso de fiscalización, los documentos que respaldan este control son:

• Export de la configuración del job mostrando que la opción de cifrado AES-256 está habilitada.
• Captura del audit log del KMS mostrando los eventos de uso de la llave (encrypt, decrypt, rotate).
• Procedimiento documentado de rotación periódica de llaves, con la frecuencia justificada según el análisis de riesgo de la organización.
• Procedimiento documentado de revocación de llaves ante eventos de compromiso, con tiempos objetivo (RTO específico para revocación).

Integridad: Hardened Repository e inmutabilidad real, no la del marketing

#

El segundo principio que debemos abordar es la integridad. Aquí entra el componente más estratégico de toda arquitectura de respaldo moderna: la inmutabilidad.

Object Lock en modo Compliance versus Governance

#

Cuando hablamos de inmutabilidad sobre object storage (S3, Azure Blob con Immutable Policies, Google Cloud Storage Bucket Lock), existen dos modos posibles:

Modo Governance: el objeto no se puede borrar, pero un usuario con privilegios elevados específicos (típicamente con permisos de “BypassGovernanceRetention” o equivalente) puede eliminar el lock y borrar el dato.

Modo Compliance: el objeto no se puede borrar por nadie hasta que expire la retention configurada. Ni siquiera el usuario root de la cuenta cloud puede saltarse este lock.

La diferencia entre ambos modos no es un detalle de implementación, es la diferencia entre que tu inmutabilidad sea válida frente a la ley o no. Bajo el principio de integridad y confidencialidad del Art. 3 de la Ley 21.719 y la obligación de adoptar medidas de seguridad razonables para impedir alteración o destrucción no autorizada de los datos, únicamente el modo Compliance es defendible como medida técnica suficiente, porque solo el modo Compliance garantiza que ni un atacante que comprometa credenciales privilegiadas, ni un insider con acceso administrativo, pueden borrar las copias de respaldo dentro del período de retención declarado.

Linux Hardened Repository on-premise

#

Para los respaldos on-premise, Veeam ofrece la posibilidad de configurar un Linux Hardened Repository. Esta arquitectura combina varios controles:

• Immutable Filesystem flag: los archivos de respaldo se marcan con chattr +i, lo que impide su modificación o borrado a nivel de filesystem hasta que expire el período de inmutabilidad.

• Single Use Credentials: el Backup Server se autentica al repositorio una sola vez para escribir el respaldo, y luego no almacena las credenciales SSH. Esto significa que si el Backup Server es comprometido, las credenciales del repositorio no quedan disponibles para el atacante.

• Repositorio fuera del dominio Active Directory: el servidor que actúa como Hardened Repository no debe estar joineado al dominio AD de producción, porque eso lo expondría a movimientos laterales basados en compromiso de credenciales de dominio.

Aislamiento del Backup Server

#

Adicionalmente al Hardened Repository, el propio Veeam Backup Server debe estar aislado del dominio AD principal, idealmente en un dominio dedicado o en grupo de trabajo, con MFA obligatorio en la consola y RBAC granular para que ningún operador tenga, simultáneamente, acceso a producción y acceso a la consola de respaldo.

Evidencia auditable que entregamos

#

• Configuración del repositorio mostrando que la inmutabilidad está habilitada en modo Compliance.
• Reporte de Veeam ONE que confirma el porcentaje de jobs con destino inmutable.
• Documentación de arquitectura mostrando el aislamiento de red y de identidad del Backup Server y del Hardened Repository.
• Test periódico de tentativa de borrado fallida, con timestamp, como prueba de que el lock funciona.

Disponibilidad: la regla 3-2-1-1-0 traducida a evidencia auditable

#

El tercer principio es la disponibilidad. Aquí, la regla 3-2-1-1-0 que la industria ha adoptado se convierte directamente en una matriz de cumplimiento.

• 3 copias de los datos.
• 2 medios distintos.
• 1 copia offsite.
• 1 copia offline o inmutable.
• 0 errores en la verificación.

La diferencia entre “creemos que el respaldo funciona” y “tenemos evidencia mensual de que el respaldo funciona” es lo que hace SureBackup. SureBackup ejecuta una verificación automatizada y aislada del respaldo: levanta una máquina virtual desde la copia, valida que el sistema operativo bootea, valida que servicios críticos (como SQL, Active Directory u Oracle) responden, y genera un reporte con el resultado.

El reporte de SureBackup, junto con los reportes mensuales de Veeam ONE sobre RPO y RTO efectivos, son los documentos que se anexan al Registro de Actividades de Tratamiento como evidencia formal del control de disponibilidad. Lo que el auditor va a pedir no es “muéstrame tu Backup Server”, es “muéstrame los doce reportes mensuales de verificación del último año”.

Derecho al olvido sobre respaldos inmutables: la respuesta operacional con Veeam

#

Aquí está el punto que más confusión genera en las organizaciones, y que merece una sección dedicada porque la respuesta superficial es errada.

El Art. 7 de la ley establece el derecho de supresión del titular: cuando una persona ejerce su derecho al olvido sobre sus datos personales, porque ya no son necesarios para la finalidad del tratamiento, porque se revocó el consentimiento sin otra base legal, porque el tratamiento fue ilícito, o por orden judicial, la organización está obligada a eliminarlos en un plazo razonable. El problema es que los respaldos por definición están diseñados para no poder borrarse selectivamente. Si tengo un respaldo full de una base de datos del lunes pasado, no puedo “borrar la fila de Juan Pérez” sin invalidar el respaldo completo. Y si los respaldos son inmutables, el problema se duplica.

La respuesta primaria: Staged Restore + retention mínima + inmutabilidad + documentación

#

Para la inmensa mayoría de las organizaciones que protegen cargas tradicionales con Veeam (VMs, bases de datos, file shares, SaaS), la combinación que cumple defendiblemente con el derecho de supresión bajo Ley 21.719 es la siguiente:

1. Staged Restore para asegurar que el estado productivo activo refleja la supresión del dato del titular. Este es el control efectivo y operacional, y es donde realmente se cumple con el derecho de olvido.
2. Retention al mínimo legal aplicable, justificada documentalmente. Los respaldos históricos del titular existen, pero por un plazo acotado y demostrable en el Registro de Actividades de Tratamiento.
3. Inmutabilidad sobre ese mismo respaldo histórico, demostrando que durante el plazo de retention nadie puede acceder ni modificar los datos del titular.
4. Registro documental honesto que reconozca explícitamente: “los datos del titular fueron suprimidos del estado productivo el día X mediante Staged Restore; permanecen en respaldos históricos durante N meses por obligación legal Y; al expirar la retention serán eliminados automáticamente; durante el plazo no se realizan operaciones sobre esos respaldos”.

Esta combinación es la respuesta defendible ante la Agencia, y es la que realmente aplica al setup típico de Veeam protegiendo cargas mixtas. La detallamos a fondo en la sección de Staged Restore que viene a continuación.

Staged Restore: la respuesta operacional de Veeam para el derecho al olvido

#

Veeam Backup & Replication ofrece desde la versión 9.5 Update 4 una funcionalidad específicamente diseñada para flujos de derecho al olvido y obligaciones de borrado selectivo: Staged Restore.

Lo que hace Staged Restore es lo siguiente:

1. Recuperación a un entorno aislado: la VM o el workload se restaura desde el respaldo inmutable hacia un entorno de pruebas o “lab” aislado de producción, sin exponerse en la red corporativa.

2. Ejecución de scripts de sanitización: antes de que la VM sea publicada en producción, Veeam ejecuta un script personalizado (PowerShell, Bash o el lenguaje que se requiera) que opera sobre los datos restaurados. Por ejemplo: eliminar registros de un titular específico de una base de datos, borrar archivos sensibles, anonimizar campos, aplicar transformaciones reversibles o irreversibles.

3. Publicación del estado saneado: una vez que el script termina exitosamente, el workload saneado se publica en producción reemplazando el estado anterior.

4. Registro completo: cada Staged Restore queda registrado en el job log de Veeam con timestamp, script ejecutado, código de salida y duración, lo que sirve como evidencia operacional ante el regulador.

Este flujo no modifica el respaldo original (que sigue siendo inmutable), pero permite que la versión productiva activa cumpla con la obligación de supresión sin tener que esperar a que el respaldo expire por retention.

Casos de uso de Staged Restore alineados con la Ley 21.719

#

• Derecho de supresión: eliminar registros de un titular en bases de datos productivas a partir de un respaldo reciente, sin tocar el respaldo inmutable.
• Anonimización: aplicar transformaciones (hash, máscara, generalización) antes de migrar datos a un entorno con menor nivel de control.
• Limpieza pre-restore tras un incidente: ejecutar verificaciones AV/EDR, aplicar parches críticos o sanitizar configuraciones inseguras antes de que la VM toque producción.
• Cumplimiento contractual con encargados de tratamiento: garantizar que la información compartida con un tercero no contiene datos personales más allá de lo estrictamente necesario.

Secure Restore

#

Junto con Staged Restore, Veeam ofrece Secure Restore, que escanea automáticamente la VM con un antivirus o EDR antes de publicarla. Si bien su foco es de seguridad operacional (anti-ransomware, anti-malware), también aporta evidencia complementaria al cumplimiento, demostrando que cada restauración pasa por una validación previa formal y que no estamos reintroduciendo en producción una amenaza que pueda comprometer datos personales.

Limitaciones que hay que tener presentes

#

• Staged Restore opera a nivel de VM completa. Para casos más granulares, por ejemplo, eliminar un único usuario de una tabla en una base de datos sin tocar el resto del workload, se complementa con Veeam Explorer for Microsoft SQL o el Explorer correspondiente, que permite recuperación a nivel de objeto de aplicación.
• Para datos que viven en SaaS o servicios cloud nativos sin agente de respaldo Veeam, el flujo de borrado debe complementarse con las APIs nativas del proveedor (M365, Salesforce, etc.) y con Veeam Backup for Microsoft 365 o Veeam Backup for Salesforce, que sí soportan restauración granular y registro auditable.
• El script de sanitización es responsabilidad del equipo de IT; Veeam ejecuta el script pero no genera la lógica de borrado. Esto significa que la calidad del cumplimiento depende de qué tan bien escrito esté el script y de su mantenimiento en el tiempo. Recomiendo versionarlo en el mismo repositorio Git de la organización, con revisión y testing antes de cada uso productivo.
• Staged Restore actúa sobre el estado restaurado, no sobre los respaldos históricos. Para los respaldos del pasado, la respuesta correcta es la combinación de retention controlada al mínimo legal aplicable, inmutabilidad durante ese plazo y registro honesto, no existir un atajo técnico para “borrar selectivamente del histórico” en arquitecturas tradicionales.

Lo que NO hay que hacer

#

• No prometer al titular que su dato fue borrado del respaldo si en realidad el dato sigue ahí. La declaración correcta es que el dato ha sido suprimido del estado productivo y se mantiene en respaldos históricos durante el plazo legal mínimo, identificando cuál es ese plazo y la base legal que lo justifica.
• No asumir que la Ley 21.719 exige el borrado físico inmediato del histórico. La ley exige medidas razonables y proporcionales, no imposibles. Una retention controlada + inmutabilidad + Staged Restore + documentación honesta es una respuesta defendible.
• No buscar atajos técnicos que prometen “borrar selectivamente del respaldo”. En arquitecturas tradicionales no existen. Lo que existe es Staged Restore para el estado productivo y retention bien gestionada para que los históricos expiren en el plazo justo.
• No olvidar que la honestidad del registro es lo que diferencia un proceso defendible de uno que no resiste fiscalización. El regulador tolera una arquitectura imperfecta documentada con honestidad mucho mejor que una arquitectura “ideal en papel” que no se sostiene cuando se rasca un poco.

Minimización y limitación del plazo de conservación

#

El principio de minimización exige que solo conservemos los datos personales por el tiempo necesario para cumplir la finalidad declarada del tratamiento. En el contexto de respaldos, esto se traduce en políticas de retention y GFS justificadas documentalmente.

GFS no es decorativo. Cada plazo de retención debe estar respaldado por un fundamento legal, contractual u operacional. Algunos ejemplos típicos:

• Datos contables y facturas: 6 años por obligación tributaria del Servicio de Impuestos Internos.
• Logs de acceso a sistemas críticos: 1 año por compliance interno y trazabilidad ante incidentes.
• Datos de marketing y CRM: el plazo del consentimiento entregado por el titular, típicamente entre 1 y 3 años con opción de renovación.
• Datos de salud o sensibles: el plazo declarado en el Registro de Actividades de Tratamiento, típicamente alineado con la normativa sectorial aplicable.

Veeam permite configurar políticas GFS por job con granularidad diaria, semanal, mensual y anual. Lo importante desde el punto de vista de cumplimiento es que el reporte de retention de Veeam ONE coincida con lo declarado en el RAT, y que cualquier desviación esté documentada y justificada.

Notificación de brechas en 72 horas

#

El Art. 14 sexies establece la obligación de notificar a la Agencia y, según la gravedad, a los titulares afectados. La ventana de 72 horas se cuenta desde el conocimiento de la brecha, no desde la brecha misma. Esto significa que el reloj parte cuando alguien dentro de la organización (típicamente el equipo de IT o el SOC) detecta la situación. Si la detección demora días, el plazo de 72 horas se cuenta desde ese momento, pero la demora en detectar puede ser interpretada como una falla del control de monitoreo, configurando una infracción adicional.

Capacidades de Veeam para detección temprana

#

La Plataforma de Veeam incorpora varias capacidades específicas para acortar el tiempo de detección:

• Veeam Recon Scanner: análisis automatizado de los respaldos en busca de indicadores de compromiso, incluyendo IOCs conocidos y comportamientos anómalos en los datos respaldados.

• Threat Center: dashboard centralizado que correlaciona eventos de seguridad detectados durante los respaldos, con priorización por severidad.

• Malware Detection con análisis de entropía: detección automatizada de cifrado anómalo en archivos, característico de un evento de ransomware en curso.

• Alertas de borrado masivo: notificación inmediata cuando se detecta eliminación atípica de datos en los respaldos o en las cargas protegidas.

Runbook conectado con NIST 800-61

#

Una vez detectada la brecha, el flujo de respuesta debe estar documentado y ensayado. Esto se conecta directamente con lo que ya conversamos en el post de Plan de Respuesta ante Incidentes con NIST 800-61, 800-53r5, Mitre ATT&CK y Veeam, y con las capacidades de detección perimetral del post de Veeam Decoys - Detección Temprana.

El flujo recomendado es:

1. Detección Veeam (Recon Scanner, Threat Center, Decoys, Malware Detection).
2. Análisis y triage del incidente por el CSIRT.
3. Contención mediante aislamiento de red, revocación de credenciales y activación del Hardened Repository como sitio limpio.
4. Erradicación y recovery desde el último punto inmutable verificado.
5. Notificación formal a la Agencia dentro de las 72 horas, con la información requerida por la ley (naturaleza, categorías y cantidad aproximada de titulares afectados, consecuencias probables y medidas adoptadas).
6. Notificación a los titulares afectados cuando la brecha represente un alto riesgo a sus derechos.
7. Análisis post-mortem y actualización del plan de respuesta.

Transferencia internacional: todo respaldo que cruza la frontera es transferencia

#

Cuando replicamos un respaldo a S3 en us-east-1 o a Azure East-US, estamos realizando una transferencia internacional de datos personales sujeta a las disposiciones de los Art. 27 y 28 de la ley (transferencia a países con nivel adecuado y cláusulas tipo, respectivamente), con la fiscalización general establecida en el Art. 29. Este es un punto que muchas organizaciones pasan por alto en la fase de diseño de su arquitectura de respaldo, y que después es muy costoso corregir.

Mecanismos de garantía aceptados por la ley

#

La Ley 21.719 admite varios mecanismos para que una transferencia internacional sea válida:

• Países con nivel adecuado de protección: la Agencia mantendrá un listado de países cuya legislación es considerada equivalente. Hasta que ese listado esté publicado, la práctica recomendada es trabajar con la presunción de que la mayoría de los destinos requerirán garantías adicionales.

• Cláusulas tipo: contratos estandarizados aprobados por la Agencia que se incorporan al contrato de servicios con el proveedor cloud.

• Reglas Corporativas Vinculantes (BCR): aplicables a transferencias intra-grupo en organizaciones multinacionales.

• Consentimiento expreso del titular: aplicable en algunos casos puntuales, no recomendado como base general para infraestructura de respaldo.

Documentación en el RAT

#

Toda transferencia internacional debe estar reflejada en el Registro de Actividades de Tratamiento, identificando el país de destino, el proveedor, la categoría de datos transferidos, la finalidad de la transferencia y el mecanismo de garantía utilizado. Si replicamos respaldos a AWS us-east-1, eso debe estar en el RAT.

Alternativas para mantener los datos en LATAM

#

Una estrategia que muchas organizaciones están adoptando es minimizar la transferencia internacional eligiendo regiones de cloud o capacity tiers en LATAM. El panorama 2026 luce así:

• AWS: regiones operativas en São Paulo y México (Central), con Santiago de Chile anunciado para fines de 2026.
• Azure: regiones operativas en Brazil South (São Paulo), Brazil Southeast (Río de Janeiro), Mexico Central (Querétaro) y Chile Central (Santiago) con disponibilidad anunciada y rollout en curso.
• Google Cloud: regiones operativas en São Paulo y Santiago.
• Object storage on-premise con Veeam Hardened Repository + capacity tier S3-compatible (MinIO, Cloudian, Scality, Pure Storage, NetApp StorageGRID) hospedado en data centers locales del proveedor de turno o en infraestructura propia. Esta es la opción que más organizaciones reguladas están eligiendo cuando la sensibilidad de los datos no admite ninguna salida del país.
• Veeam Data Cloud Vault como object storage gestionado por Veeam con inmutabilidad WORM por defecto, encryption AES-256 en tránsito y reposo, logical air-gap desde producción y, particularmente relevante para presupuestos predecibles, pricing flat por TB que incluye API calls, restore y egress (a diferencia del modelo S3 puro donde estos cargos son variables y a menudo sorprenden en factura).

Esta decisión no es solo de cumplimiento, también tiene impactos en latencia y costo de egress que deben evaluarse caso a caso. Muy importante: el solo hecho de que un proveedor tenga una región en LATAM no implica que tu suscripción enrute automáticamente los datos allí, la región de destino se configura explícitamente en el job de Veeam y debe documentarse en el RAT.

Securiti AI (ahora parte de Veeam): DSPM, privacy operations y AI trust

#

Si bien Veeam Backup & Replication cubre de forma sólida los pilares de integridad, disponibilidad y confidencialidad sobre los datos respaldados, hay capas del cumplimiento que ocurren aguas arriba del respaldo: descubrimiento, clasificación, gobierno de privacidad, gestión de derechos del titular, evaluaciones de impacto, que históricamente requerían herramientas externas. Eso cambió en diciembre de 2025: Veeam completó la adquisición de Securiti AI por USD 1.725 mil millones (cierre formal el 11 de diciembre de 2025), incorporando al portfolio el Data Command Center de Securiti, DSPM, privacy operations, gobierno de IA, bajo el lema “first trusted Data Platform”. Rehan Jalil, fundador y CEO de Securiti, asumió como President of Security and AI en Veeam, y los 600 colaboradores de Securiti se sumaron al equipo.

En la práctica, esto significa que las capacidades que detallo a continuación dejan de ser “una integración entre dos vendors” y pasan a ser piezas del mismo portfolio Veeam, con un único interlocutor comercial, un único soporte y, en el mediano plazo, integración técnica más profunda con VBR, VRO y el resto del stack. Para una organización que está armando su arquitectura de cumplimiento bajo Ley 21.719, esto baja significativamente la fricción de adopción.

Qué resuelve Securiti AI que VBR no resuelve

#

• Data Security Posture Management (DSPM): descubrimiento automatizado de dónde viven los datos personales en toda la organización, bases de datos, data lakes, SaaS, file shares y almacenamiento cloud, con clasificación automática por categoría (datos personales identificables, datos sensibles, datos especialmente protegidos como salud o biométricos). Sin este descubrimiento previo, no sabemos qué datos estamos respaldando ni a qué jobs aplicar las políticas más estrictas.

• Clasificación y etiquetado automático: identificación de RUT, datos de salud, datos financieros, datos de menores, datos biométricos, etc., usando modelos pre-entrenados. La salida de esta clasificación alimenta directamente las políticas de retention y encryption diferenciadas en Veeam.

• Privacy Operations (DSAR): automatización del flujo de respuesta a solicitudes de los titulares (Data Subject Access Requests), acceso, rectificación, supresión, portabilidad. Esto baja el costo operacional de cumplir con los derechos del titular de días-persona a horas, y deja una trazabilidad auditable de cada solicitud y su resolución.

• Consent management: registro y trazabilidad del consentimiento entregado por cada titular, con linkage directo a las finalidades declaradas en el Registro de Actividades de Tratamiento.

• DPIA automation: workflow asistido para realizar las Evaluaciones de Impacto, con plantillas alineadas a múltiples marcos regulatorios (GDPR, LGPD, CCPA, y las que vayan emergiendo para Ley 21.719).

• Compliance automation y mapeo multi-marco: cuando una organización opera en varios países, Securiti AI permite mapear los controles implementados a múltiples leyes simultáneamente, evitando duplicar esfuerzo de documentación y manteniendo coherencia entre regulaciones que comparten principios pero difieren en detalle.

• AI security y governance: capacidades específicas para gobernar el uso de datos personales en proyectos de IA, protección de datos de entrenamiento, sanitización de prompts, trazabilidad de inferencias y de modelos derivados.

Cómo se integran en una arquitectura combinada

#

Una arquitectura madura de cumplimiento bajo Ley 21.719 combina ambas capas del portfolio Veeam operando en planos distintos pero coordinados:

1. Securiti AI en la capa de descubrimiento, clasificación, governance y privacy operations, actuando como el sistema de inteligencia que sabe qué datos personales existen, dónde viven, quién los procesa, con qué finalidad y bajo qué consentimiento.

2. Veeam Backup & Replication + Recovery Orchestrator en la capa de respaldo, recuperación, inmutabilidad y respuesta a incidentes, actuando como el sistema que asegura la integridad y disponibilidad de esos datos cuando algo sale mal.

3. Integración por APIs y etiquetas: la clasificación que produce Securiti AI se traduce en políticas diferenciadas en Veeam, jobs con cifrado y KMS dedicado para datos sensibles, retention extendida para datos sujetos a obligaciones legales específicas, replicación restringida a regiones LATAM para datos que no admiten transferencia internacional, alertas de Threat Center priorizadas según la criticidad regulatoria del dataset comprometido. Esta integración irá profundizándose durante 2026 a medida que avance la unificación del portfolio post-adquisición.

Qué evidencia adicional aporta Securiti AI al regulador

#

Frente a un proceso de fiscalización, Securiti AI contribuye con documentación que Veeam no puede generar de forma nativa:

• Reporte de inventario de datos personales por categoría y por sistema, con timestamp y trazabilidad de cambios.
• Registro de DSAR atendidas con tiempos de respuesta y trazabilidad de la acción ejecutada sobre los sistemas productivos.
• Mapeo de controles a artículos específicos de la Ley 21.719 y a marcos análogos como GDPR, LGPD o CCPA.
• DPIA documentadas, archivadas y con flujo formal de aprobación.
• Registro de consentimientos con timestamps, fuentes y trazabilidad de modificaciones.

La pregunta de fondo no es Veeam o Securiti AI, la pregunta es cómo se complementan para cubrir el ciclo completo del dato personal: descubrir, clasificar, gobernar (Securiti AI) → respaldar, proteger, recuperar (Veeam) → responder y evidenciar ante el regulador (ambos en conjunto).

Capacidades adicionales de Veeam alineadas con Ley 21.719: VRO, Coveware, Threat Hunter y más

#

Más allá de los pilares ya cubiertos (encryption con KMS, Hardened Repository, regla 3-2-1-1-0, Staged Restore, Recon Scanner, Threat Center), la Plataforma de Veeam tiene varias capacidades específicas que vale la pena conocer porque mapean directamente con principios de la Ley 21.719 y con las exigencias documentales que va a tener el proceso de fiscalización. Varias de estas son funcionalidades recientes incorporadas en v12.3 (early 2025) y v13 que muchas organizaciones todavía no han habilitado.

Veeam Recovery Orchestrator (VRO): el control de disponibilidad documentado automáticamente

#

Veeam Recovery Orchestrator es el componente que orquesta la recuperación ante desastres y, lo que es más relevante para nuestro caso, auto-genera la documentación que el auditor va a pedir. En lugar de mantener manualmente el plan de DR, los runbooks y los reportes de pruebas, VRO los produce y los actualiza automáticamente cuando el plan se ejecuta o se prueba.

Lo que aporta para Ley 21.719:

• Runbooks automatizados que detallan paso a paso cómo se recuperan las cargas críticas que contienen datos personales, sin depender de la memoria del operador de turno.
• Pruebas automatizadas con registro, los DR drills se ejecutan en un entorno aislado y dejan reporte fechado del resultado, lo que constituye evidencia formal del control de disponibilidad ante el regulador.
• Monthly Audit Report con Full Change Tracking (incorporado en v13 de la Plataforma), registra todas las actividades y cambios sobre los planes de recuperación durante el mes, generando una trazabilidad que difícilmente vamos a producir a mano.
• Offline malware scanning antes del recovery, los respaldos se escanean offline antes de levantarlos a producción, evitando reintroducir amenazas que puedan comprometer datos personales en el ambiente productivo.
• Compliance dashboards que muestran el estado del cumplimiento de DR contra los SLAs declarados internamente y los plazos comprometidos en el RAT.

Para una organización que tiene que demostrar ante la Agencia que sus medidas de disponibilidad son reales y verificables, VRO es la forma de pasar de “tenemos un plan” a “aquí están los reportes mensuales que demuestran que el plan funciona y se prueba periódicamente”.

Coveware by Veeam: el equipo de respuesta que activamos cuando la prevención falla

#

Veeam adquirió Coveware en abril de 2024 y la marca opera hoy como Coveware by Veeam. Es un servicio especializado en respuesta a incidentes de extorsión cibernética y ransomware, es decir, exactamente el escenario que dispara la obligación de notificación de 72 horas bajo Ley 21.719.

Lo que aporta:

• Incident Response Retainer: contrato preventivo que da acceso prioritario al equipo de respuesta cuando ocurre el incidente. En la práctica, evitar el “scramble” inicial de buscar y contratar especialistas mientras la crisis está activa, que típicamente quema los primeros días del plazo de notificación.
• Negociación con actores de extorsión cuando aplique, gestionada por un equipo con miles de casos cerrados. La decisión de negociar o no es legal y de negocio, pero la capacidad técnica de hacerlo o de evitarlo profesionalmente es algo que la organización promedio no tiene internamente.
• Forensics y damage assessment, análisis técnico del incidente, vector de entrada, datos afectados. Esta información es exactamente lo que el regulador va a requerir como parte de la notificación formal de la brecha.
• Recon y Unidecrypt, herramientas propias de Coveware para análisis de costo de incidente y descifrado en casos donde sea técnicamente posible.
• Integración con Veeam Cyber Secure program, el programa elite de servicios de Veeam Data Platform Premium que combina Ransomware SWAT team disponible 24/7 con SLA de 30 minutos, assessments de seguridad trimestrales ejecutados por expertos Veeam, onboarding avanzado de siete fases y, para los clientes inscritos, hasta dos incidentes por año atendidos por Coveware sin costo adicional.

Para Ley 21.719 esto es particularmente relevante porque la notificación de 72 horas no es solo “informar a la Agencia”: es entregar un análisis técnico que tenga sentido. Un equipo interno típico no puede producir ese análisis en tres días desde cero. Con Coveware en retainer, y más aún si la organización es cliente de Cyber Secure con SLA de 30 minutos, ese análisis empieza el día cero del incidente.

Veeam Threat Hunter, YARA e Inline Malware Scanning: detección integrada al backup engine

#

Desde la versión 12.3 de Veeam Backup & Replication (early 2025), la Plataforma incorpora capacidades de detección que antes requerían herramientas externas:

• Veeam Threat Hunter: combina escaneo con reglas YARA, detección estilo antivirus, machine learning y análisis heurístico, todo integrado al backup engine. Detecta malware polimórfico que evade firmas tradicionales. La base de datos de amenazas se actualiza varias veces al día desde Veeam.
• Inline Malware Scanning: el escaneo ocurre durante el job de respaldo, no como un paso posterior. Si una VM comprometida se está respaldando con archivos cifrados por ransomware o con binarios maliciosos, la alerta es inmediata y dentro de la ventana del propio job.
• Indicators of Compromise (IoC) Detection: identifica patrones conocidos de ataque dentro de los datos respaldados, alimentados por threat intelligence integrada.
• YARA rules personalizadas: el equipo de seguridad puede definir reglas propias para detectar amenazas específicas a su industria, su entorno o un caso particular bajo investigación.

Para Ley 21.719, lo crítico es el tiempo de detección. Recordemos que las 72 horas se cuentan desde el conocimiento de la brecha. Cada hora que pasa sin detectar el incidente erosiona el plazo disponible para una respuesta ordenada y para construir la notificación formal a la Agencia. Estas capacidades bajan ese tiempo de detección significativamente y, lo que es igual de importante, dejan logs auditables de cada detección y cada falso positivo descartado.

Four-Eyes Authorization: separación de responsabilidades exigible

#

Otra incorporación reciente es Four-Eyes Authorization, que requiere la aprobación de un segundo operador autorizado antes de ejecutar operaciones sensibles sobre la infraestructura de respaldo: eliminar jobs, modificar políticas de retention, deshabilitar encryption, modificar configuraciones de repositorios inmutables.

Esta capacidad ataca directamente el riesgo de insider malicioso y de acción accidental con consecuencias destructivas. Para Ley 21.719, cumple con el principio de “medidas razonables” en la separación de roles, especialmente para operaciones que afectan la retención o el borrado de datos personales, operaciones que de otro modo podrían ser usadas para evadir el cumplimiento o para destruir evidencia frente al regulador. Esto se conecta con el enfoque RBAC multi-tenant que ya conversamos en el post de Kasten RBAC multi-tenant multi-cluster con Keycloak, donde la separación de responsabilidades a nivel de plataforma se aplica también al respaldo de cargas Kubernetes.

Cada aprobación queda registrada en el audit log con ambos operadores identificados, fecha, operación realizada y justificación textual cuando aplica. Es el tipo de control que un auditor pide verificar de forma directa, y que sin Four-Eyes Authorization se construye con procesos manuales que rara vez se cumplen al 100%.

Matriz auditable y checklist de los 12 meses previos

#

Para cerrar, te dejo una tabla resumen con el cruce “principio de la ley → control técnico → componente Veeam → evidencia auditable”, y un checklist de hitos para que tu organización llegue preparada al 1 de diciembre de 2026.

¿Cómo se mapean los controles técnicos a los principios de la Ley 21.719?

#

La siguiente matriz traduce cada principio de la ley a un control técnico específico, su componente Veeam responsable y la evidencia documental que entregamos al regulador. Es la respuesta corta y accionable a la pregunta que casi todos los lectores van a tener al llegar acá.

Checklist de los 12 meses

#

• T-12 meses (diciembre 2025): implementación y prueba del KMS externo, integración con Veeam Backup & Replication, definición de política de rotación de llaves.

• T-9 meses (marzo 2026): despliegue del Hardened Repository en modo Compliance, migración de jobs críticos al destino inmutable, validación de aislamiento de red y de identidad.

• T-6 meses (junio 2026): realización de la DPIA del flujo de respaldo, especialmente para jobs que involucran datos sensibles o transferencia internacional. Actualización del Registro de Actividades de Tratamiento.

• T-3 meses (septiembre 2026): simulacro completo de notificación de brecha, midiendo tiempo de detección, tiempo de contención, tiempo de notificación. Ajustes al runbook según hallazgos.

• T-1 mes (noviembre 2026): auditoría externa de cumplimiento, revisión de toda la documentación que se entregaría a la Agencia ante un eventual requerimiento.

• 1 de diciembre de 2026: entrada en vigencia plena de la Ley 21.719.

Preguntas frecuentes

#

¿Cuándo entra en vigencia la Ley 21.719?

#

La Ley 21.719 fue publicada el 13 de diciembre de 2024 y entra en plena vigencia el 1 de diciembre de 2026, 24 meses después de su publicación. Desde esa fecha, la Agencia de Protección de Datos Personales puede fiscalizar el cumplimiento y aplicar sanciones.

¿Cuáles son las sanciones máximas de la Ley 21.719?

#

Hasta UTM 20.000 o el 4% de los ingresos anuales en Chile en la categoría más alta (~$1.392M CLP en su tope UTM). La reincidencia puede triplicar la multa, alcanzando hasta UTM 60.000.

¿Las PyMES deben cumplir con la Ley 21.719 desde el día uno?

#

Sí, pero con un margen de adaptación: durante el primer año de vigencia (1 dic 2026 al 1 dic 2027), las PyMES están sujetas únicamente a amonestación escrita, no a multa. Pasado ese plazo, las sanciones aplican plenamente.

¿Cómo cumplir con el derecho de supresión sobre respaldos inmutables?

#

Para arquitecturas tradicionales, la respuesta defendible es la combinación de Staged Restore (Veeam B&R 9.5 U4+) sobre el estado productivo activo, retention al mínimo legal aplicable documentada en el RAT, inmutabilidad del respaldo histórico durante ese plazo, y registro honesto que registre la acción ante el titular y el regulador.

¿Qué es Staged Restore en Veeam?

#

Es una funcionalidad de Veeam Backup & Replication (desde 9.5 Update 4) que permite recuperar una VM desde el respaldo a un entorno aislado, ejecutar un script de sanitización (PowerShell, Bash) sobre los datos restaurados, por ejemplo eliminar registros de un titular, anonimizar campos, y publicar el estado saneado en producción. El respaldo original sigue siendo inmutable.

¿Cómo se relaciona la Ley 21.719 con el GDPR europeo?

#

La Ley 21.719 toma el modelo conceptual de GDPR y replica casi todos sus principios, derechos del titular, obligaciones de DPO, DPIA y notificación de brechas en 72h. Las diferencias principales son la cuantía absoluta de sanciones, el alcance territorial (acotado a Chile en lugar de extraterritorial) y la jurisprudencia, que en Chile recién comienza a construirse.

Conclusión

#

La Ley 21.719 nos lleva, finalmente, a un escenario donde la protección de datos personales se traduce en obligaciones técnicas concretas y fiscalizables. Para las áreas de IT, y particularmente para los equipos a cargo de la infraestructura de respaldo y recuperación, esto representa una oportunidad para profesionalizar y documentar prácticas que muchas veces ya se aplican, pero que no estaban formalizadas como evidencia de cumplimiento.

La buena noticia es que la mayor parte de los controles que la ley exige se pueden implementar y evidenciar con las capacidades nativas de la Plataforma de Veeam, encryption con KMS, inmutabilidad real en modo Compliance, RBAC con MFA, retention justificada, Staged Restore para el derecho de supresión, detección automatizada con Veeam Threat Hunter y Threat Center, verificación periódica con SureBackup, orquestación con Veeam Recovery Orchestrator y respuesta especializada con Coveware by Veeam. Lo que diferencia un cumplimiento sólido de uno superficial es la disciplina de documentar cada control y mantener actualizada la matriz auditable que entregamos al regulador.

Para las PyMES chilenas hay un margen adicional durante el primer año de vigencia (1 dic 2026 al 1 dic 2027), donde las infracciones se sancionan solo con amonestación. Pero ese período no es para “empezar después”, es para terminar de aterrizar lo que ya debiera estar en marcha: al cierre del período de gracia, los antecedentes acumulados pasan a ser parte del historial frente a la Agencia.

Si tu organización todavía no tiene un plan claro para llegar al 1 de diciembre de 2026 con la casa en orden, la recomendación es partir hoy mismo por el checklist de los 12 meses, y avanzar de forma sistemática y documentada. Como siempre digo, en seguridad y resiliencia no hay atajos: o se hace bien, o no se hace.

Si te sirvió este post o tienes preguntas sobre cómo aplicar estos controles en tu arquitectura específica, escríbeme por LinkedIn.

Posts relacionados

#

• Veeam Hardened (Immutable) Repository
• Veeam Decoys - Detección Temprana
• Veeam + Kasten
• Veeam Capacity Tier Oracle Cloud Object Storage