Qué es la declaración de aplicabilidad (soa) y cómo se usa para cumplir la ley 21.719

La Ley 21.719, publicada en diciembre de 2024, establece un nuevo estándar de rigor para las organizaciones en Chile. Esta normativa cambia el enfoque hacia una responsabilidad demostrable, obligando a las empresas a contar con evidencia técnica de sus procesos. Bajo este esquema, la carga de la prueba recae en la organización, que debe acreditar medidas de seguridad efectivas.

En este contexto, la Declaración de Aplicabilidad (SoA) se consolida como una herramienta técnica indispensable para articular esta defensa. El documento funciona como un inventario de decisiones de seguridad que vincula los riesgos identificados con soluciones concretas. Si una empresa es incapaz de justificar técnicamente qué controles aplica y las razones detrás de esa selección, carece de los argumentos necesarios para validar su cumplimiento ante la futura autoridad.

Qué es la declaración de aplicabilidad (SoA)

La Declaración de Aplicabilidad (SoA) es un registro centralizado donde la empresa declara formalmente qué medidas de seguridad ha decidido implementar y cuáles ha descartado. No es un simple trámite burocrático para auditores externos ni una lista de verificación que se marca al azar; es un documento estratégico que justifica la postura de seguridad de la organización frente a sus riesgos específicos.

Aunque el concepto proviene de la norma ISO 27001, su uso para la Ley 21.719 es una decisión inteligente. Permite estructurar el cumplimiento legal de forma técnica y ordenada, evitando que la protección de datos quede dispersa en políticas sin ejecución real.

Una SoA efectiva se compone de una estructura lógica que permite auditar la seguridad de la información. Sus características principales incluyen:

• Un inventario de decisiones: Registra qué controles se seleccionan y, lo más importante, cuáles se descartan.
• Una declaración de estado: Refleja si la medida es una realidad operativa o un proyecto a futuro.
• Un respaldo argumentativo: Provee el razonamiento detrás de cada medida, vinculándola con la normativa vigente.

Por qué la SoA es clave para cumplir la Ley 21.719 (aunque no la mencione explícitamente)

La Ley 21.719 no exige un documento llamado “Declaración de Aplicabilidad”, pero sí establece un estándar mucho más alto y claro: las organizaciones deben ser capaces de demostrar, con evidencia técnica, que han adoptado medidas de seguridad proporcionales y efectivas para proteger los datos personales.

En este nuevo marco, el cumplimiento deja de ser declarativo y pasa a ser operativo. La carga de la prueba recae en la organización, que debe explicar qué controles aplica, por qué los eligió y cómo estos mitigan los riesgos reales de su operación. Sin un registro estructurado que articule estas decisiones, responder de forma coherente ante una fiscalización se vuelve extremadamente difícil.

Aquí es donde la Declaración de Aplicabilidad cobra relevancia práctica. La SoA funciona como el documento que traduce las obligaciones abstractas de la ley en decisiones técnicas concretas, conectando riesgos, controles y evidencia de forma trazable. No es una formalidad heredada de ISO 27001, sino el mecanismo que permite demostrar diligencia y criterio profesional frente a la autoridad.

Una SoA bien construida responde directamente a las siguientes exigencias de la Ley:

• Deber de seguridadLa ley exige adoptar medidas técnicas y organizativas adecuadas para proteger los datos personales. La SoA documenta cuáles son esas medidas, dónde se aplican y qué riesgos mitigan, evitando declaraciones genéricas sin respaldo técnico.
• Responsabilidad demostrableYa no basta con afirmar que se cumple. Ante una fiscalización o incidente, la organización debe probar que tomó decisiones razonables y ejecutables. La SoA actúa como el registro maestro que evidencia que los controles fueron evaluados, justificados e implementados de forma consciente.
• Enfoque basado en riesgo y proporcionalidadLa Ley 21.719 no impone un modelo único de seguridad. Exige que las medidas sean coherentes con el tipo de datos tratados y el impacto potencial de una brecha. La SoA permite demostrar que los controles seleccionados responden a un análisis previo de riesgos y no a una adopción arbitraria de estándares.
• Deber de prevención y diligenciaCuando ocurre un incidente, la autoridad evaluará tanto el resultado como el esfuerzo previo por evitarlo. Una SoA actualizada demuestra que la organización identificó amenazas, implementó controles razonables y mantuvo un proceso activo de revisión, lo que puede influir directamente en la calificación de la conducta.
• Capacidad de fiscalización y auditoríaLa futura Agencia de Protección de Datos necesitará verificar coherencia entre lo declarado y lo ejecutado. La SoA permite entregar un documento único que conecta obligaciones legales con controles técnicos y evidencia verificable, reduciendo la percepción de improvisación o desorden.

Visto así, la Declaración de Aplicabilidad no es un complemento opcional al cumplimiento de la Ley 21.719, sino el instrumento práctico que permite demostrar que las obligaciones legales se han traducido en decisiones técnicas reales, auditables y defendibles.

Qué ocurre cuando una organización no tiene una SoA

La falta de una Declaración de Aplicabilidad no suele ser evidente hasta que ocurre un incidente o una fiscalización. En ese momento, la organización debe explicar cómo protege los datos personales y por qué tomó ciertas decisiones de seguridad. Sin una SoA, ese relato suele ser fragmentado e inconsistente.

Esto se traduce en riesgos claros:

• Relato técnico disperso: Cada área explica la seguridad desde su propio ángulo, sin un documento que conecte riesgos, controles y decisiones.
• Dificultad para demostrar diligencia: Aunque existan controles, la ausencia de justificación documentada hace difícil probar que fueron proporcionales y razonables.
• Evidencia reactiva y desordenada: La recopilación de pruebas ocurre bajo presión, aumentando errores y contradicciones.
• Controles que no resisten verificación: Se declaran medidas que no están plenamente operativas o no cubren toda la operación.
• Mayor exposición a sanciones: La Ley 21.719 evalúa no solo el incidente, sino la capacidad de demostrar gestión preventiva.

Qué información debe contener una soa para que sea útil (y defendible)

Para que una Declaración de Aplicabilidad trascienda el cumplimiento burocrático y se convierta en un activo de defensa legal, su contenido debe ser preciso y auditable. No basta con enumerar herramientas; es necesario construir una narrativa técnica que explique la lógica de seguridad de la empresa.

A continuación, detallamos los componentes esenciales para que este documento sea realmente útil y defendible.

• Identificación del controlCada medida de seguridad debe estar claramente identificada mediante un nombre y una descripción técnica detallada. Esto implica especificar no solo la función del control, sino también su alcance en la infraestructura tecnológica. Al definir con precisión qué se está protegiendo y bajo qué parámetros, se elimina la ambigüedad y se facilita la supervisión de los responsables de TI.
• Justificación de inclusión o exclusiónEste es el núcleo argumentativo de la SoA. Se debe explicar en detalle por qué un control es fundamental para proteger la privacidad de los datos personales en el marco del modelo de negocio. Del mismo modo, si se decide omitir una medida, la justificación debe ser sólida para evitar interpretaciones de negligencia. Esta sección demuestra que cada decisión de seguridad fue analizada y no tomada al azar.
• Estado de implementaciónEs vital declarar con transparencia si una medida de seguridad se encuentra plenamente operativa, en etapa de despliegue o si aún requiere mejoras para ser efectiva. Un control que solo existe en la teoría no ofrece protección real. Registrar el estado actual permite a la gerencia priorizar inversiones y asegura que los auditores externos comprendan el nivel de madurez real de la organización.
• Vinculación con riesgosCada control seleccionado debe responder directamente a una amenaza identificada que afecte el cumplimiento de la Ley 21.719. Al conectar las medidas técnicas con riesgos específicos, como el acceso no autorizado o la pérdida de integridad de los datos, el SoA se convierte en un mapa estratégico. Esto permite demostrar que la empresa invierte sus recursos en mitigar vulnerabilidades críticas.
• Evidencia relacionadaUn documento de cumplimiento carece de valor sin pruebas que lo respalden. Esta sección debe incluir referencias directas a registros, manuales de configuración, contratos con proveedores o bitácoras de sistemas que acrediten la existencia del control. Proporcionar esta trazabilidad facilita enormemente las auditorías, ya que permite verificar de inmediato que lo declarado en el papel coincide con la realidad operativa.

Quién debe ser responsable de la declaración de aplicabilidad

Una Declaración de Aplicabilidad solo es defendible si cuenta con un responsable claro. Bajo la Ley 21.719, la seguridad de los datos personales no es un esfuerzo difuso ni una tarea compartida sin liderazgo; es una obligación que requiere ownership definido y trazable.

La SoA no pertenece a un área aislada, sino que se construye de forma colaborativa, con roles bien delimitados:

• Responsable final (accountability)Debe existir una figura claramente identificada —normalmente en Compliance, Seguridad de la Información o Gobierno de Datos— responsable de mantener la SoA actualizada y coherente con la operación real. Esta persona o este rol es quien responde ante auditorías, fiscalizaciones o incidentes.
• Equipo técnico (ejecución y evidencia)El área de TI o de Seguridad es responsable de implementar los controles declarados y de generar la evidencia técnica que los respalda. La SoA solo es válida si refleja configuraciones reales y verificables en los sistemas y dispositivos.
• Legal y Compliance (alineamiento normativo)Su rol no es definir controles técnicos, sino asegurar que las decisiones documentadas en la SoA estén alineadas con las obligaciones de la Ley 21.719 y con los principios de protección de datos. Actúan como validadores del criterio aplicado.
• Alta dirección (respaldo y priorización)Cuando la SoA revela brechas o controles pendientes, es la dirección quien debe priorizar recursos y tomar decisiones de riesgo. Este respaldo es clave para demostrar que la seguridad es una política organizacional y no solo una iniciativa técnica.

Definir estos roles evita uno de los errores más comunes en el cumplimiento: documentos bien redactados, pero sin un dueño real. Para la autoridad, una SoA sin responsable claro es una señal de desorden organizacional y debilita cualquier argumento de diligencia.

El rol de los dispositivos en la SoA

En el contexto profesional actual, los datos personales ya no están confinados a un servidor central; residen y circulan permanentemente en los endpoints. La mayoría de los colaboradores accede a información sensible desde laptops y smartphones, lo que convierte a estos dispositivos en el perímetro crítico que la Ley 21.719 busca proteger mediante el control efectivo y la responsabilidad técnica.

Para que una SoA sea sólida bajo este nuevo estándar, debe integrar controles específicos sobre estos dispositivos:

• Inventario: Mantener un registro exhaustivo y actualizado de cada equipo que accede a los datos de la organización.
• Control de acceso: Implementar una autenticación robusta y una gestión de privilegios para asegurar que solo el personal autorizado utilice los dispositivos.
• Borrado remoto: Capacidad técnica para eliminar datos ante pérdida o robo, mitigando el riesgo de una brecha de seguridad masiva.
• Trazabilidad: Registrar la actividad y el movimiento de la información para cumplir con la exigencia de auditabilidad.
• Gestión de incidentes: Protocolos claros para detectar y responder a amenazas que afecten directamente a los equipos finales.

Una SoA débil suele ignorar la realidad de los dispositivos móviles, la información que estos contienen y modalidades de trabajo flexibles como el trabajo remoto, dejando fuera del radar los activos más vulnerables. Debido a esto, sin un control real sobre los dispositivos, cualquier declaración de aplicabilidad queda incompleta y expone a la empresa a sanciones por falta de debida diligencia.

Cómo construir una SoA práctica paso a paso (en contexto ley 21.719)

Para construir una SoA bajo la Ley 21.719, el enfoque debe ser funcional y pragmático antes que puramente teórico. La idea es diseñar un inventario de seguridad que refleje cómo tu empresa protege los datos en el día a día. El objetivo es que cualquier fiscalizador comprenda rápidamente tu lógica de protección.

Es importante recordar que no necesitas una certificación formal en ISO 27001 para que este ejercicio sea útil. La SoA es, ante todo, una herramienta de gestión interna que profesionaliza tu cumplimiento de la ley chilena.

• Definir alcance real (no ideal)Evita la tentación de declarar que proteges toda la red si solo tienes control sobre ciertos sectores. Identifica con precisión qué procesos procesan datos personales y en qué dispositivos se encuentran. Ser honesto sobre el alcance permite aplicar medidas de seguridad donde realmente se necesitan, evitando dejar puntos ciegos peligrosos.
• Identificar riesgos relevantesAnaliza qué eventos podrían comprometer la privacidad según tu operación. No pierdas tiempo en amenazas genéricas; enfócate en riesgos tangibles como el robo de laptops con bases de datos o accesos no autorizados por parte de excolaboradores. La Ley 21.719 exige una protección proporcional a estos riesgos detectados.
• Seleccionar controles razonablesElige medidas con las que tu equipo técnico pueda operar con consistencia. Es preferible tener diez controles bien ejecutados y monitoreados que cincuenta declarados que nadie supervisa. La razonabilidad es clave, pues el control debe ser efectivo para mitigar el riesgo sin entorpecer la viabilidad operativa de la empresa.
• Documentar decisiones (no solo controles)Lo más valioso para una defensa legal es el "por qué". Registra las razones detrás de la elección de cada herramienta y, fundamentalmente, por qué decidiste que ciertos controles no eran necesarios. Esta bitácora de decisiones demuestra que existe un criterio profesional y no una omisión por descuido.
• Vincular controles a evidenciasCada ítem de tu SoA debe apuntar a una prueba tangible. Si declaras un control de borrado remoto, debes tener el registro de la plataforma que lo ejecuta. Esta trazabilidad permite que, ante una fiscalización, la entrega de pruebas sea inmediata y coherente con lo declarado en el documento.
• Revisar y ajustar periódicamenteLa seguridad no es un estado estático. Programa revisiones trimestrales para verificar si los controles siguen siendo efectivos o si han aparecido nuevos riesgos técnicos. Un documento actualizado refleja una gestión activa, lo cual es un factor determinante para demostrar la debida diligencia ante cualquier incidente.

Cómo usar la SoA como evidencia ante incidentes y fiscalización

Ante un incidente de seguridad o una fiscalización de la nueva Agencia de Protección de Datos, la improvisación es el peor enemigo. Si ocurre una filtración, la autoridad no solo evaluará el daño, sino también el esfuerzo previo de la empresa por evitarlo. Presentar una SoA sólida permite responder con hechos y datos, transformando una crisis en una demostración de gestión profesional.

El uso estratégico de la SoA en estos escenarios se divide en tres frentes:

• Durante un incidente: Sirve como manual de referencia para el equipo de respuesta, permitiendo identificar rápidamente qué controles fallaron y cuáles deberían haber contenido la brecha.
• Frente a la autoridad: En lugar de enviar correos explicativos aislados, entregas un documento maestro que justifica técnicamente tu postura de seguridad y las medidas de mitigación que estaban operativas.
• En procesos de mejora: Tras un evento crítico, la SoA se utiliza para ajustar los controles y documentar las lecciones aprendidas, cerrando el ciclo de responsabilidad que exige la ley.

La diferencia entre enfrentar una multa gravísima o una amonestación leve radica, muchas veces, en la capacidad de demostrar que existía un plan coherente. Responder con evidencia organizada proyecta una imagen de control que la simple narrativa no puede lograr.

SoA como herramienta de gestión, no como burocracia

La Declaración de Aplicabilidad es el documento que aterrizará las expectativas legales de la Ley 21.719 a la realidad técnica de los equipos de IT y Compliance. No debe verse como una carga burocrática heredada de las normas ISO, sino como el inventario estratégico que protege a la empresa de la incertidumbre regulatoria. Es el mapa que garantiza que cada peso invertido en seguridad tiene un propósito claro y una justificación legal sólida.

Lograr un cumplimiento operativo real implica dejar de gestionar la seguridad por intuición y empezar a hacerlo dentro de un marco de trabajo documentado. Si tu organización aún no tiene claro qué controles aplica a los dispositivos móviles o al trabajo remoto, partir por un inventario de endpoints es el paso más lógico y efectivo. Una SoA que refleja la realidad operativa es la mejor garantía de que, ante cualquier auditoría, la respuesta de la empresa será siempre técnica, clara y defendible.