La continuidad de los servicios financieros y de seguridad social depende de una infraestructura tecnológica que va mucho más allá de los sistemas que una institución administra directamente. Plataformas en la nube, software de gestión, servicios de autenticación, centros de datos, integraciones de datos y proveedores de soporte pueden formar parte de procesos cuya interrupción afecta la atención de clientes, el acceso a prestaciones o la operación de servicios esenciales.
En Chile, la Ley N ° 21.663, conocida como Ley Marco de Ciberseguridad, establece obligaciones para prevenir, reportar y responder a incidentes de ciberseguridad. Además, contempla exigencias reforzadas para determinadas instituciones calificadas como Operadores de Importancia Vital (OIV). Esto tiene consecuencias para bancos, administradoras de fondos de pensiones (AFP), cajas de compensación y otras entidades que administran prestaciones de seguridad social, pero también plantea una pregunta para las empresas que les prestan servicios tecnológicos: ¿qué controles deben demostrar y hasta dónde llegan sus obligaciones?
La respuesta requiere distinguir entre lo que la ley exige directamente al OIV, las obligaciones que pueden alcanzar al proveedor por su propia actividad y los controles que la institución contratante necesita incorporar en sus contratos y evaluaciones de terceros. No son categorías equivalentes, y confundirlas puede llevar tanto a exigir demasiado como a dejar riesgos relevantes sin gestionar.
Qué es la Ley Marco de Ciberseguridad y por qué importa
La Ley N° 21.663 fue publicada en el Diario Oficial el 8 de abril de 2024. Su objetivo es establecer una institucionalidad y un marco general para coordinar la ciberseguridad en Chile, fijar requisitos mínimos para prevenir y gestionar incidentes y definir obligaciones, mecanismos de supervisión y responsabilidades para las instituciones comprendidas en su ámbito de aplicación.
La norma creó la Agencia Nacional de Ciberseguridad (ANCI), organismo encargado, entre otras funciones, de desarrollar protocolos y estándares, coordinar la respuesta nacional ante incidentes y determinar qué instituciones deben ser calificadas como OIV. La ley distingue entre prestadores de servicios esenciales y operadores de importancia vital. Los primeros incluyen, entre otros, a instituciones que realizan actividades de banca, servicios financieros y medios de pago, así como de administración de prestaciones de seguridad social. También incorpora servicios digitales y servicios de tecnologías de la información gestionados por terceros.
Ser un prestador de servicios esenciales y ser un OIV no es exactamente lo mismo. La calificación como OIV se aplica mediante una resolución de la ANCI a instituciones que cumplen los criterios legales relacionados con su dependencia de redes y sistemas informáticos y con el impacto significativo que podría tener la interrupción de sus servicios. Esa calificación activa deberes específicos adicionales, sin eliminar las obligaciones generales de ciberseguridad y reporte que correspondan a la institución.
La dimensión de este proceso quedó reflejada el 24 de julio de 2026, cuando se publicó en el Diario Oficial la nómina final correspondiente a la segunda etapa del primer proceso de calificación. Según informó la ANCI, al sumar ambas etapas se alcanzaron 1.154 instituciones calificadas como OIV, de las cuales 25 corresponden a entidades que administran prestaciones de seguridad social, incluyendo AFP, cajas de compensación, Isapres y administradoras del seguro de cesantía (ANCI, 2026).
Esta cifra permite dimensionar el alcance institucional del proceso, pero no significa que todas las empresas del sector financiero y de seguridad social hayan recibido automáticamente esa calificación. Para determinar las obligaciones concretas de una institución es necesario revisar la resolución y la nómina oficial aplicable, además de la regulación sectorial correspondiente.
El artículo 8: una gestión continua del riesgo, no una revisión puntual
El artículo 8 de la Ley N° 21.663 establece deberes específicos para los operadores de importancia vital. Su primer requisito es implementar un sistema de gestión de seguridad de la información continuo, destinado a identificar los riesgos que puedan afectar las redes, los sistemas informáticos, los datos y la continuidad operacional del servicio. El sistema debe permitir evaluar tanto la probabilidad de que ocurra un incidente como el impacto potencial que podría producir.
La continuidad es central. No basta con acreditar que una organización cuenta con antivirus, políticas de contraseñas o una evaluación realizada durante el proceso de contratación de un proveedor. La lógica de la norma requiere identificar riesgos, registrar las acciones de gestión, revisar controles y mantener capacidades de prevención, detección, respuesta y recuperación.
El artículo 8 también exige mantener registros de las acciones que integran el sistema de gestión; elaborar e implementar planes de continuidad operacional y ciberseguridad, sujetos a certificación y revisión periódica; realizar operaciones de revisión, ejercicios, simulacros y análisis de redes y sistemas; adoptar medidas oportunas para reducir el impacto y la propagación de incidentes; informar a potenciales afectados en los casos previstos por la ley; mantener programas de capacitación continua y designar un delegado de ciberseguridad.
Estos deberes están dirigidos directamente a los OIV. La institución calificada debe poder demostrar que su gestión de ciberseguridad funciona como un proceso permanente y que contempla los riesgos relevantes para la prestación del servicio.
Sin embargo, la organización no puede analizar ese riesgo de manera aislada. Si una plataforma externalizada sostiene una operación crítica, una vulnerabilidad en el proveedor puede comprometer la disponibilidad, integridad o confidencialidad de los sistemas de la institución contratante. Por eso, aunque el artículo 8 no convierte automáticamente a cada proveedor en responsable de todas las obligaciones del OIV, sí vuelve especialmente relevante la gestión de los riesgos que dependen de terceros.
¿Qué cambia para los proveedores tecnológicos?
La primera distinción es jurídica. La calificación de un banco, una AFP o una caja como OIV no convierte, por sí sola, a su proveedor de software, nube, soporte o consultoría en otro OIV. La calificación depende del procedimiento y de la resolución correspondiente de la ANCI, no de una transferencia automática desde el cliente hacia sus contratistas.
Esto tampoco significa que los proveedores queden siempre fuera de la Ley N.º 21.663. El artículo 4 incluye dentro de los servicios esenciales determinados servicios digitales y servicios de tecnologías de la información gestionados por terceros. Por ello, un proveedor debe analizar si su propia actividad está comprendida en el ámbito de la ley y qué obligaciones le corresponden. Además, la ANCI puede calificar como OIV a una institución que cumpla los requisitos legales, conforme al procedimiento previsto.
En la práctica, conviene separar tres situaciones:
1. El proveedor está sujeto a obligaciones legales propias. Si presta un servicio comprendido en la ley, debe determinar cuáles son sus obligaciones generales, los deberes de reporte que correspondan y si existe una calificación o regulación sectorial aplicable. No debe asumir que su condición de proveedor lo excluye del marco legal.
2. El proveedor no está calificado como OIV, pero sostiene un proceso crítico de su cliente. En este escenario, la institución contratante necesita evaluar y controlar el riesgo de dependencia. Puede incorporar exigencias contractuales de seguridad, continuidad, notificación de incidentes, cooperación y entrega de evidencias, según la criticidad del servicio y los riesgos identificados.
3. El proveedor también ha sido calificado como OIV. En ese caso, tendrá que cumplir las obligaciones que le correspondan directamente por esa condición, sin perjuicio de las responsabilidades contractuales que mantenga con sus clientes.
La diferencia importa porque los contratos no deberían utilizarse para declarar, sin fundamento, que un proveedor asume todas las obligaciones legales del cliente. Su función es definir responsabilidades concretas, controles verificables y mecanismos de colaboración que permitan a la institución calificada gestionar sus propios riesgos.
Qué debería trasladarse a los contratos y a las evaluaciones de proveedores TI
La ley no establece en el artículo 8 una lista universal de cláusulas que todos los bancos, AFP o cajas deban incorporar de idéntica manera en todos sus contratos tecnológicos. Las exigencias concretas dependerán del servicio, de los riesgos, de las normas sectoriales aplicables y de las instrucciones pertinentes de la autoridad.
Aun así, los deberes del OIV ofrecen una base clara para estructurar evaluaciones de terceros. La pregunta práctica es qué necesita saber y poder demostrar la institución para determinar si la dependencia tecnológica está adecuadamente controlada.
Gestión de riesgos y alcance del servicio. La evaluación debe identificar qué sistemas, datos, integraciones y procesos dependen del proveedor. También conviene documentar las consecuencias de una interrupción, los accesos que mantiene, las dependencias de otros proveedores y los controles que utiliza para proteger el servicio. Una declaración genérica de que la empresa cumple con buenas prácticas de seguridad no reemplaza esta revisión.
Seguridad de la información y accesos. Según la naturaleza del servicio, se pueden solicitar políticas y procedimientos de seguridad, mecanismos de autenticación, gestión de privilegios, segregación de ambientes, cifrado cuando corresponda, registros de actividad y procesos para corregir vulnerabilidades. La evidencia debe permitir entender cómo se aplican los controles y quién responde por ellos.
Continuidad operacional y recuperación. Si el servicio es crítico, resulta pertinente solicitar información sobre respaldos, recuperación ante desastres, objetivos de recuperación, pruebas realizadas y dependencias que podrían impedir la restauración. También se debe verificar si los planes son compatibles con las necesidades operacionales del cliente. Un documento de continuidad que nunca se ha probado aporta menos información que un ejercicio documentado con resultados, brechas y medidas correctivas.
Gestión y comunicación de incidentes. El contrato debe establecer cómo se informa al cliente sobre incidentes o vulnerabilidades que puedan afectar el servicio, qué canales se utilizan, qué información se entrega y cómo se coordina la respuesta. Es importante definir un plazo contractual que permita a la institución cumplir oportunamente sus propias obligaciones legales de reporte. El proveedor debería cooperar con la investigación, la contención, la recuperación y la preparación de antecedentes, respetando las exigencias de confidencialidad y protección de la información.
Subcontratación y dependencias tecnológicas. Si el proveedor utiliza terceros para alojar información, operar componentes esenciales o entregar soporte, la evaluación debe determinar si esas dependencias generan riesgos adicionales. Las cláusulas pueden exigir que se identifiquen las subcontrataciones relevantes, se comuniquen cambios materiales y se mantengan controles adecuados a lo largo de la cadena de prestación del servicio.
Seguimiento y evidencias. La evaluación inicial no debería ser el único punto de control. Según el riesgo, puede acordarse la entrega periódica de indicadores, resultados de pruebas, certificaciones disponibles, informes de auditoría o planes de remediación. También conviene definir cómo se revisarán las brechas detectadas y qué ocurre si un control comprometido deja de funcionar.
El propósito no es acumular documentos. Es obtener evidencia suficiente para que la institución pueda evaluar el riesgo, justificar sus decisiones y demostrar que mantiene una gestión continua de las dependencias que pueden afectar la prestación del servicio.
Qué evidencia pedir sin convertir la evaluación en un trámite
Una evaluación útil debe relacionar cada solicitud con un riesgo identificable. No todos los proveedores necesitan entregar el mismo conjunto de antecedentes. Un proveedor con acceso privilegiado a sistemas de producción, que almacena información sensible o cuya indisponibilidad detendría una operación crítica, requiere un nivel de revisión distinto al de una empresa que presta un servicio auxiliar sin acceso a sistemas ni datos relevantes.
Para estructurar la revisión, el OIV puede solicitar, según corresponda:
Una descripción del servicio, sus componentes, los sistemas y datos involucrados y las responsabilidades de cada parte.
Una evaluación de riesgos del servicio y evidencia de los controles que los mitigan.
Políticas de seguridad pertinentes, procedimientos de gestión de accesos y registros o reportes de controles relevantes.
Información sobre gestión de vulnerabilidades, actualizaciones, pruebas de seguridad y tratamiento de hallazgos.
Planes de continuidad y recuperación aplicables al servicio, junto con resultados de pruebas o ejercicios recientes.
Procedimientos de notificación y respuesta a incidentes, incluyendo contactos, escalamiento y cooperación con el cliente.
Información sobre subcontratistas críticos y dependencias que puedan afectar la continuidad.
Certificaciones, informes independientes o resultados de auditoría que el proveedor ya tenga y que sean pertinentes para el servicio contratado.
La institución debe valorar la calidad y actualidad de la evidencia. Una certificación puede ser útil, pero su alcance, vigencia y cobertura deben revisarse: no necesariamente incluye todos los servicios prestados al cliente ni todos los riesgos relevantes. De igual modo, una política escrita no demuestra por sí sola que el control se encuentre implementado y opere eficazmente.
También es importante que el contrato permita acceder a la información necesaria para gestionar un incidente y verificar el cumplimiento de los compromisos acordados, sin solicitar acceso indiscriminado a sistemas, datos o documentos de otros clientes del proveedor. Las revisiones deben ser proporcionales y compatibles con la confidencialidad, la protección de datos y la seguridad del propio prestador.
Qué no corresponde exigir automáticamente
Una aplicación rigurosa de la ley requiere evitar que las obligaciones del OIV se conviertan en una lista indiscriminada de exigencias para toda empresa tecnológica.
En primer lugar, no corresponde afirmar que todo proveedor de un OIV debe designar un delegado de ciberseguridad, implementar exactamente el mismo sistema de gestión del cliente o certificar sus propios planes por el solo hecho de tener una relación comercial con él. Esas obligaciones deben evaluarse según el ámbito de aplicación de la ley, la condición jurídica del proveedor y las disposiciones que efectivamente le resulten aplicables.
En segundo lugar, tampoco puede darse por hecho que todo proveedor deba contar con una certificación específica, como ISO 27001, o entregar íntegramente sus matrices de riesgo, auditorías internas y planes de continuidad. Estos antecedentes pueden ser necesarios en determinados contratos o exigidos por una regulación sectorial, pero no deben presentarse como una obligación universal derivada, por sí sola, del artículo 8. Si se solicita una certificación, la institución debería justificar su pertinencia, definir el alcance esperado y aceptar, cuando corresponda, evidencias alternativas que permitan comprobar controles equivalentes.
En tercer lugar, no debe confundirse la notificación contractual al cliente con el reporte legal a la autoridad. El proveedor puede estar obligado por contrato a informar rápidamente un incidente para que el OIV evalúe su impacto y cumpla sus deberes. Sin embargo, la obligación legal de reportar a la ANCI o al CSIRT Nacional debe determinarse según el ámbito de aplicación de la ley y la situación concreta de cada institución. No nace automáticamente, en todos los casos, de la mera relación comercial con un OIV.
Por último, una evaluación no debería exigir controles desconectados del servicio, ni tratar como equivalentes a todos los proveedores. La propia Ley Marco de Ciberseguridad contempla el principio de racionalidad, que vincula las medidas de seguridad con el nivel de exposición al riesgo y el eventual impacto social y económico. El artículo 7 también dispone que la ANCI debe establecer medidas diferenciadas, considerando especialmente las características y posibilidades de las empresas de menor tamaño.
La proporcionalidad no significa rebajar la protección de un servicio crítico. Significa elegir controles adecuados al riesgo, solicitar evidencia pertinente y evitar que el cumplimiento se reduzca a una lista de documentos que no permite entender cómo funciona realmente el servicio.
Una pauta práctica para las áreas de compras, tecnología y cumplimiento
Antes de contratar o renovar un servicio tecnológico, una institución calificada como OIV puede ordenar su evaluación con cinco preguntas:
¿Qué proceso crítico depende del proveedor? Identificar el servicio, los sistemas, los datos, los accesos y las consecuencias de una interrupción.
¿Qué riesgos introduce la dependencia? Evaluar exposición a incidentes, vulnerabilidades, indisponibilidad, pérdida de datos y concentración en un prestador.
¿Qué controles existen y cómo se comprueban? Revisar evidencia relevante, no solo declaraciones de cumplimiento.
¿Qué debe ocurrir si falla el servicio? Acordar notificación, escalamiento, contención, recuperación, cooperación y responsabilidades.
¿Cómo se mantendrá la supervisión? Definir revisiones periódicas proporcionales a la criticidad, seguimiento de brechas y evaluación de cambios significativos.
Esta pauta ayuda a vincular la evaluación de proveedores con el sistema de gestión continuo que exige el artículo 8. También favorece una coordinación efectiva entre compras, tecnología, ciberseguridad, continuidad operacional, asesoría jurídica y cumplimiento, en lugar de delegar la revisión completa en una sola área.
La debida diligencia tecnológica como parte de la gestión del riesgo
La Ley N° 21.663 refuerza una idea que las instituciones críticas necesitan aplicar en sus relaciones con terceros: la seguridad de un servicio no depende exclusivamente de los controles internos de quien lo contrata. También depende de las capacidades de los proveedores, de las condiciones en que se presta el servicio y de la posibilidad de detectar y gestionar riesgos a lo largo de la relación.
Para bancos, AFP y cajas de compensación calificadas como OIV, esto implica evaluar las dependencias tecnológicas con una mirada continua, documentar las decisiones y verificar que los controles acordados respondan a los riesgos reales. Para los proveedores, supone poder explicar cómo protegen los servicios que entregan, qué evidencia respalda sus prácticas y cómo colaborarán si ocurre un incidente.
El desafío está en evitar dos extremos: asumir que el cliente puede trasladar todas sus obligaciones legales mediante un contrato, o limitar la evaluación del proveedor a una declaración general de cumplimiento. Una gestión eficaz requiere identificar responsabilidades, establecer controles verificables y mantener una relación de colaboración que permita prevenir incidentes, responder oportunamente y sostener la continuidad de los servicios.
La pregunta relevante ya no es solo si un proveedor tiene políticas de ciberseguridad, sino si la institución puede comprender, verificar y gestionar el riesgo que introduce esa dependencia tecnológica en la continuidad de un servicio esencial.
Referencias
Agencia Nacional de Ciberseguridad. (2026, 24 de julio). ANCI finaliza el primer proceso de calificación de Operadores de Importancia Vital. https://anci.gob.cl/noticias/anci-finaliza-el-primer-proceso-de-calificacion-de-operadores-de-importancia-vital/
Biblioteca del Congreso Nacional de Chile. (2024). Ley N.º 21.663: Ley Marco de Ciberseguridad. Ley Chile. https://www.bcn.cl/leychile/navegar?i=1202434
Biblioteca del Congreso Nacional de Chile. (2026). Resolución exenta N.º 187: Aprueba nómina de operadores de importancia vital correspondiente a la segunda etapa del primer proceso de calificación. Diario Oficial, 24 de julio de 2026. https://www.bcn.cl/leychile/navegar?i=1226358&f=2026-07-24
