El problema no termina en el proveedor
Una empresa puede enterarse de una intrusión porque un proveedor de software, soporte, nube o procesamiento dejó de responder, avisó de un acceso extraño o detectó actividad anormal en una cuenta con permisos. El primer impulso suele ser exigir una explicación y restablecer el servicio. Ambas cosas son necesarias, pero no bastan.
La empresa cliente debe construir su propio registro de lo ocurrido. El proveedor conoce su infraestructura; usted conoce qué información circulaba, quién necesitaba acceso y qué decisiones se tomaron dentro de su organización. Esa separación evita que toda la reconstrucción dependa de una versión externa que puede llegar incompleta o después de que ciertos registros hayan sido sobrescritos.
Separe contención, evidencia y responsabilidad
Durante una crisis conviene trabajar en tres líneas paralelas. La primera es la contención: reducir el acceso comprometido y mantener la operación segura. La segunda es la evidencia: conservar los datos que muestran qué ocurrió, cuándo y desde qué cuentas o sistemas. La tercera es la responsabilidad: determinar qué obligaciones tenía cada parte y qué decisiones deben tomarse frente al proveedor.
No confunda la necesidad de cerrar una sesión o cambiar una credencial con una conclusión sobre quién causó el incidente. Tampoco confunda el hecho de que el proveedor haya sufrido el ataque con una prueba automática de negligencia. La calificación penal y las responsabilidades contractuales se analizan con hechos, registros y documentos.
Mientras se contiene el incidente, deje constancia de cada acción importante: quién ordenó el cambio, qué sistema se aisló, qué información se recibió del proveedor y qué quedó pendiente de confirmar. Una bitácora sencilla puede ser más útil que una explicación reconstruida semanas después.
Qué debe pedir y conservar la empresa
El proveedor debería entregar información suficiente para que el cliente pueda dimensionar el incidente. Si la respuesta llega por teléfono, confirme los puntos principales por escrito y guarde cada versión, incluso cuando todavía sea preliminar.
En paralelo, resguarde dentro de su empresa lo que ya está disponible. No se trata de recolectar todo indiscriminadamente, sino de fijar el estado de la información antes de que cambie:
- El contrato, sus anexos de seguridad, niveles de servicio, reglas de acceso y procedimiento de aviso de incidentes.
- Correos, tickets, mensajes y archivos con los avisos del proveedor, incluyendo sus fechas y destinatarios.
- Registros de acceso, cambios de permisos, conexiones administrativas y alertas internas relacionadas con el servicio.
- Un inventario de los sistemas, datos y usuarios que dependían del proveedor, sin copiar información personal innecesaria.
- La cronología propia de la empresa: cuándo detectó el problema, qué hizo y qué información recibió en cada momento.
Qué relación tiene esto con las leyes de ciberseguridad
La Ley N° 21.459 tipifica conductas como el acceso ilícito y los ataques a la integridad de un sistema o de sus datos, además del fraude informático. Que el punto de entrada haya sido un proveedor no cambia la necesidad de preservar evidencia; sí puede hacer más compleja la reconstrucción porque intervienen varias infraestructuras y equipos.
La Ley N° 21.663 establece el marco chileno de ciberseguridad y la Agencia Nacional de Ciberseguridad explica en su portal qué se entiende por incidentes de efecto significativo y a qué instituciones puede alcanzar el régimen. No es prudente aplicar una obligación de reporte por intuición: primero hay que verificar si la empresa o el servicio está dentro de las categorías correspondientes y revisar la información oficial vigente.
La respuesta penal y la respuesta regulatoria no son la misma conversación. Una empresa puede necesitar preservar antecedentes para una investigación y, al mismo tiempo, revisar con asesoría si tiene deberes específicos frente a la autoridad o a sus propios clientes.
Cuando el contrato se vuelve parte de la evidencia
En una intrusión de terceros, el contrato deja de ser un documento guardado en una carpeta y pasa a explicar qué podía hacer cada parte. Revise quién administraba las credenciales, qué accesos eran indispensables, cuánto tiempo debían conservarse ciertos registros y cómo debía avisarse un incidente. No dé por hecho que una cláusula genérica responde a esas preguntas.
También importa la forma de comunicarse con el proveedor. Solicitar una preservación de registros, pedir que no se eliminen cuentas comprometidas sin copia previa y dejar por escrito las preguntas pendientes ayuda a evitar una discusión basada solo en recuerdos. Esa comunicación debe ser firme y técnica, sin acusaciones que todavía no puede sostener.
La empresa no tiene que esperar el informe final del proveedor para ordenar sus propios antecedentes. Si existe acceso compartido, datos de clientes o una interrupción relevante, conviene evaluar pronto la estrategia con asesoría legal y técnica coordinada.
Una intrusión en un proveedor exige coordinar operación, evidencia y contrato desde el primer momento. La empresa no puede controlar toda la infraestructura externa, pero sí puede conservar su propia versión de los hechos y tomar decisiones informadas antes de que los registros desaparezcan.
Preguntas frecuentes
¿El proveedor es automáticamente responsable por la intrusión?+
No. El hecho de que el ataque haya ingresado por un proveedor puede ser importante, pero no resuelve por sí solo la responsabilidad. Hay que revisar qué ocurrió, qué accesos existían, qué medidas se habían acordado, qué información entregó cada parte y qué decisiones se tomaron después de detectar el incidente. La empresa debe preservar antecedentes antes de formular conclusiones, porque una acusación prematura puede cerrar la cooperación y no reemplaza el análisis técnico ni contractual.
¿Debemos apagar la conexión con el proveedor de inmediato?+
La decisión depende del riesgo y del servicio afectado. A veces aislar una conexión reduce la propagación; otras veces una desconexión sin preservar registros elimina información útil para reconstruir el acceso. La medida debe coordinarse entre las personas responsables de la operación, la seguridad y la estrategia legal. Documente quién decidió, a qué hora, qué se aisló y qué se conservó antes de ejecutar un cambio irreversible.
¿La Ley N° 21.663 obliga a cualquier empresa a reportar el incidente?+
No se puede responder solo con el hecho de usar un proveedor tecnológico. El marco de la Ley N° 21.663 depende del tipo de servicio y de la categoría en que se encuentre la institución. La ANCI publica información oficial sobre incidentes de efecto significativo y las instituciones alcanzadas. Antes de afirmar que existe o que no existe un deber de reporte, verifique la situación concreta y la normativa vigente; este artículo no fija plazos ni reemplaza esa revisión.
¿Qué hacemos si el proveedor solo entrega una explicación verbal?+
Pida una confirmación escrita de lo informado, con fecha, alcance preliminar, sistemas involucrados y medidas adoptadas, y guarde el mensaje original. Envíe por su parte una solicitud clara de preservación de registros y antecedentes, sin agregar datos personales que no sean necesarios. La información puede ser incompleta en la primera hora; lo importante es distinguir lo confirmado de lo que todavía se está investigando y actualizar la cronología cada vez que cambie el cuadro.
Donde comprobarlo
Este articulo se apoya unicamente en fuentes oficiales. Si quiere ir al texto original:
Este articulo fue preparado por HM Legal a partir de fuentes oficiales, pero es informacion general y no constituye asesoria legal para un caso concreto. HM Legal es un estudio juridico privado y no tiene relacion con la Policia de Investigaciones, el Ministerio Publico ni la Agencia Nacional de Ciberseguridad.