Contrato con un proveedor de TI tras NIS2: cláusulas de seguridad, SLA y notificación de incidentes

Un contrato con un proveedor de TI adaptado a NIS2 no debería limitarse a una declaración de conformidad, una cláusula genérica de seguridad y un indicador mensual de disponibilidad. Debe convertir el riesgo asociado al servicio en una asignación inequívoca de responsabilidades, niveles de servicio medibles, un flujo rápido de información sobre incidentes, acceso a evidencias y un plan de salida viable. El punto de partida es la criticidad del servicio y el reparto real del control entre las partes. Solo a partir de este análisis pueden definirse las salvaguardas, los plazos, los derechos de verificación y las obligaciones de notificación que deben incorporarse al contrato.

El contrato como mecanismo de control del riesgo

La revisión contractual no debería comenzar con un modelo estándar de cláusula de seguridad, sino con un mapa de las dependencias de la organización respecto de sus proveedores. Para cada proveedor deben identificarse los servicios, procesos, sistemas, datos y ubicaciones afectados, y evaluarse después las consecuencias de una indisponibilidad o de una vulneración de la seguridad. La prioridad corresponde a las dependencias cuya interrupción pueda detener la actividad, limitar el cumplimiento de compromisos o dificultar la gestión de un incidente. Por tanto, no todos los servicios de TI requieren las mismas garantías contractuales.

La clasificación de la criticidad de un proveedor debe basarse en el análisis del impacto sobre el negocio y en la evaluación de riesgos, no solo en el valor económico del contrato. Requieren especial atención los servicios cuya continuidad y gestión de incidentes siguen siendo responsabilidad de la empresa, mientras el proveedor controla la información técnica, los registros de eventos, las copias de seguridad o el entorno necesario para recuperar el servicio. La organización también debe designar a un propietario del riesgo asociado al proveedor. Sin esta función, las responsabilidades de Compras, TI, Seguridad y del propietario del proceso quedan dispersas.

El contenido contractual debe diseñarse a partir de escenarios de interrupción: fallo del servicio, ataque, pérdida o corrupción de datos, indisponibilidad del personal del proveedor, ruptura de la cadena de subcontratación y finalización de la relación. Para cada escenario deben establecerse las actuaciones de las partes, el alcance de sus responsabilidades, el flujo de información y las condiciones de recuperación. De estas decisiones se derivan los niveles de disponibilidad, los tiempos de respuesta y restauración, la documentación exigible y los derechos de verificación.

Una declaración de alta disponibilidad no determina cuánto tiempo puede permanecer inoperativo un sistema de control de la producción, desde qué momento se contabiliza la interrupción ni quién debe aportar los datos necesarios para evaluar el incidente. Tampoco garantiza el acceso a copias de los registros de eventos, información sobre subcontratistas o datos que permitan transferir el servicio de forma segura. Estas carencias suelen hacerse visibles durante una avería, cuando el reparto de responsabilidades ya no puede quedar implícito.

La referencia a NIS2 o a los requisitos aplicables de la KSC polaca debería cerrar el análisis de riesgos y responsabilidades, no sustituir el contenido operativo del contrato. El contexto de gestión más amplio se presenta en el artículo NIS2 para empresas industriales: a quién afecta, qué obligaciones introduce y cómo preparar la organización sin reducir la cuestión exclusivamente a TI. El alcance de los cambios contractuales debe adaptarse en cada caso al papel de la organización, la criticidad del servicio y el reparto efectivo del control entre las partes.

Alcance del servicio y responsabilidades

El reparto de obligaciones debe documentarse en un anexo técnico, en lugar de dejarlo dentro de una definición genérica del objeto contractual. El anexo debería identificar los activos y entornos cubiertos, las categorías de datos, las ubicaciones de tratamiento y prestación, las interfaces, los horarios de soporte y las exclusiones. Sin esta información no puede determinarse con claridad dónde termina la responsabilidad del proveedor, qué evento activa la medición del SLA ni quién protege los elementos situados en la interfaz entre sistemas.

Conviene definir las medidas de seguridad mediante el resultado exigido, la parte responsable y la evidencia de ejecución, manteniendo los detalles tecnológicos en documentación técnica sometida a control. De este modo se reduce el riesgo de que el contrato quede rápidamente obsoleto. El catálogo estándar de controles del proveedor solo debería aceptarse tras compararlo con los riesgos del servicio concreto y cubrir las brechas detectadas. La matriz de responsabilidades debe distinguir entre el propietario del control, quien lo ejecuta y quien autoriza las excepciones.

Cuando el proveedor administra el entorno, el contrato también debería regular el acceso privilegiado: segregación de funciones, método de autenticación, registro de las actividades administrativas y revocación inmediata de los permisos tras un cambio de función o la terminación de la relación. Una mera declaración de que se realizan copias de seguridad es insuficiente si el cliente desconoce quién las cifra, dónde se almacenan, quién puede restaurarlas y qué documento confirma el resultado de la prueba de recuperación.

El proveedor debería mantener una relación actualizada de los subcontratistas que intervienen en el servicio, con una descripción de sus funciones y ubicaciones de tratamiento, y exigirles condiciones no menos rigurosas que las acordadas con el cliente. El contrato debe diferenciar qué cambios requieren autorización previa y cuáles únicamente una notificación y una nueva evaluación del riesgo. Un certificado de sistema de gestión puede respaldar esta evaluación, pero no sustituye las responsabilidades definidas para el servicio concreto. Esta relación se desarrolla en el artículo NIS2 e UNE-EN ISO 27001: qué aporta el certificado y qué sigue faltando para cumplir la KSC.

Cláusulas de seguridad que pueden verificarse

Una cláusula de seguridad solo resulta exigible y evaluable cuando define el resultado esperado, su ámbito de aplicación, la frecuencia de ejecución, el método para acreditar el cumplimiento y el procedimiento de gestión de excepciones. Expresiones como «conforme a las mejores prácticas» o «con la diligencia debida» pueden complementar los requisitos, pero no permiten evaluar si el proveedor ha cumplido correctamente su obligación. Para cada control deben identificarse el propietario del requisito, el periodo de conservación de las evidencias y la parte autorizada para aceptar una excepción.

Los requisitos así definidos deberían abarcar, como mínimo, la gestión de vulnerabilidades y actualizaciones, el mantenimiento de configuraciones seguras, el cifrado, la protección y conservación de registros de eventos, las copias de seguridad, las pruebas de restauración, la gestión de cambios y el control de acceso. La frecuencia de las revisiones de permisos, las pruebas de recuperación y los informes, así como los plazos para corregir vulnerabilidades, deben derivarse de la evaluación del riesgo del servicio. No deberían ser idénticos para todos los proveedores.

Cada excepción debe incorporarse a un registro con su justificación, fecha límite de corrección, propietario del riesgo y controles compensatorios. Su aceptación exige valorar si esos controles reducen realmente el riesgo hasta el nivel admitido por la organización.

Una obligación de realizar copias de seguridad periódicas sigue siendo incompleta si no identifica los datos y sistemas cubiertos, el periodo de conservación, la protección frente a modificaciones o eliminaciones, las reglas de acceso y la frecuencia de las pruebas de restauración. También debería establecer cómo debe comunicar el proveedor una copia o una prueba fallida, quién aprueba las acciones correctivas y qué informe acredita su cierre. Del mismo modo, la obligación de corregir vulnerabilidades requiere definir el método de clasificación, los plazos de respuesta en función del riesgo, las reglas para aplazar actualizaciones y la documentación de las medidas temporales.

Las evidencias deben dividirse entre las entregadas periódicamente y las disponibles previa solicitud. En el primer grupo pueden incluirse resúmenes de vulnerabilidades, informes de actualización, resultados de pruebas de restauración y confirmaciones de revisiones de acceso. Tras un incidente, un cambio significativo o una desviación detectada, pueden ser necesarios resultados detallados de pruebas, registros de eventos, historiales de cambios, registros de excepciones y planes de acciones correctivas. Conviene vincular el alcance, los propietarios y el periodo de conservación de estos materiales con las reglas descritas en Documentación NIS2 y KSC antes de una inspección: qué políticas, registros y evidencias deben estar realmente disponibles.

El derecho de verificación debería ser gradual y viable también frente a un proveedor de servicios en la nube. El primer nivel puede comprender una revisión documental y una reunión aclaratoria; el siguiente, informes independientes o pruebas acordadas; y la auditoría in situ puede reservarse para situaciones de riesgo elevado, incidentes significativos o ausencia de evidencias fiables. El contrato debería regular los plazos, la confidencialidad, el alcance técnico y la resolución de hallazgos, sin otorgar al cliente derechos imposibles de ejercer en un entorno compartido.

Un SLA orientado a la resiliencia, no solo a la disponibilidad

El SLA debe derivarse del análisis de impacto sobre el negocio, no del catálogo estándar de parámetros del proveedor. El propietario del proceso debe definir primero el tiempo de interrupción tolerable, la pérdida de datos admisible y las consecuencias de la indisponibilidad para la producción, el servicio al cliente, la facturación y las obligaciones legales. Solo entonces pueden establecerse los objetivos de tiempo de recuperación, los requisitos para soluciones alternativas y operación en contingencia, y las prioridades de los tickets. Un indicador mensual de disponibilidad no permite saber si una única avería en un momento crítico paralizará el proceso durante más tiempo del que la organización puede aceptar.

Además de la disponibilidad, el contrato debería definir los tiempos para confirmar la recepción del aviso, iniciar el diagnóstico, restaurar las funciones y eliminar la causa, junto con la frecuencia de las comunicaciones, los niveles de escalado y la atención fuera del horario ordinario. El tiempo de respuesta no equivale al tiempo de recuperación, y activar una solución alternativa no significa que el problema esté completamente resuelto. Separar estos conceptos permite que el equipo operativo sepa cuándo podrá volver a trabajar y que el propietario del servicio determine cuándo debe concluir el proveedor el análisis de causas e implantar una acción correctiva permanente.

En un sistema que controla un proceso productivo, un incidente crítico puede exigir un escalado inmediato y comunicación continua hasta activar el modo de contingencia. La misma anomalía en un entorno de formación podría recibir una prioridad inferior. Por ello, la clasificación debe basarse en el impacto sobre la actividad, no únicamente en la descripción técnica del fallo. Si la organización dispone de datos históricos fiables, debería considerar los tiempos reales de respuesta y recuperación, los resultados de disponibilidad y el número de fallos recurrentes al establecer los umbrales.

El mecanismo de medición debe identificar la fuente de los datos, la zona horaria, el momento de inicio y detención del contador, el horario de prestación acordado, las ventanas de mantenimiento y las reglas para modificar la categoría del incidente. Las exclusiones de la medición deben recogerse en un catálogo cerrado y verificable. No pueden abarcar sucesos que permanezcan dentro de la responsabilidad del proveedor. La coherencia entre estos acuerdos y la capacidad operativa real puede evaluarse mediante una Auditoría NIS2 en una empresa industrial: cómo comprobar si la organización está preparada para las nuevas obligaciones.

Los créditos de servicio o las compensaciones simbólicas no restauran un proceso ni reducen las consecuencias de una interrupción. Tienen mayor relevancia la obligación de presentar un plan de mejora, el escalado a la dirección, las pruebas adicionales de resiliencia y el derecho a resolver el contrato ante incumplimientos persistentes o reiterados de los niveles acordados. Una penalización económica puede reforzar la responsabilidad, pero no sustituye los mecanismos para recuperar el servicio, eliminar las causas y prevenir nuevos fallos.

Incidentes y obligaciones de notificación

El contrato debería obligar al proveedor a comunicar sin demora cualquier evento que pueda afectar al servicio, a los datos, a la continuidad de la actividad o a la seguridad del cliente. La primera notificación no puede condicionarse a la confirmación completa de la causa, la magnitud del daño o la calificación jurídica del evento. El plazo contractual debe incluir un margen que permita al cliente realizar su propia evaluación y cumplir, cuando proceda, los plazos externos de notificación. Debe derivarse de la criticidad del servicio y de la disponibilidad de un punto de contacto permanente, no de la conveniencia organizativa de las partes.

El flujo de información debe dividirse en alerta inicial, actualizaciones de situación, informe posterior al incidente y análisis de causa raíz. Para cada fase deben definirse los datos exigidos, el canal autorizado, los destinatarios, la frecuencia de actualización y las reglas de escalado cuando no sea posible establecer contacto. La primera comunicación debería incluir, como mínimo, la hora de detección, los activos y servicios afectados, el impacto previsto, las medidas adoptadas, los indicadores técnicos disponibles, la evaluación del riesgo de propagación y el momento de la siguiente actualización. La lista de contactos debe incluir suplentes y comprobarse periódicamente, también fuera del horario habitual.

Si el proveedor detecta tráfico anómalo en el entorno que soporta una aplicación clave, debería advertir al cliente antes de determinar si se ha producido una vulneración. El cliente activa su propio proceso de gestión de incidentes, designa a la persona responsable de las decisiones, involucra al equipo de respuesta y, cuando corresponda, también a la aseguradora, y determina quién autoriza las notificaciones externas y la comunicación con los clientes. El proveedor preserva los registros y rastros técnicos acordados y colabora en el análisis, la contención y la determinación del alcance, pero no asume la responsabilidad regulatoria del cliente.

Las cláusulas también deberían establecer las reglas para preservar y facilitar evidencias, proteger su integridad, documentar decisiones y preparar los datos necesarios para las notificaciones y el posterior análisis de causa raíz. Los plazos, destinatarios y contenidos de las comunicaciones externas deben verificarse en cada caso conforme al marco jurídico vigente, la condición de la organización y la naturaleza del incidente. Los registros de notificaciones, decisiones, escalados y actuaciones deben vincularse con el artículo Documentación NIS2 y KSC antes de una inspección: qué políticas, registros y evidencias deben estar realmente disponibles, y el calendario de adaptación con Implantación de NIS2 tras la inscripción en el registro KSC: plan de actuación hasta el 3 de abril de 2027.

Implantación, supervisión y salida segura

La firma de una adenda no pone fin al proceso de gestión del proveedor. El propietario del contrato debería realizar revisiones periódicas de los resultados del SLA, los incidentes, las desviaciones, las acciones correctivas, los cambios de subcontratistas y la vigencia de las evidencias que acreditan el cumplimiento de los requisitos. La supervisión debe apoyarse en un registro de contratos que incluya, al menos, la fecha de renovación, el propietario, la criticidad del servicio y el estado de acuerdo de las salvaguardas. Una declaración de conformidad no sustituye los informes, resultados de pruebas o registros que demuestran el cumplimiento de las obligaciones.

Antes de renovar el contrato o introducir un cambio significativo en el servicio, deben reevaluarse su criticidad, las dependencias técnicas y de proceso, la concentración de servicios en un único proveedor, la viabilidad de las medidas de seguridad y la posibilidad de migrar a una solución alternativa. Esta revisión permite decidir si basta con una adenda o si es necesario iniciar un nuevo proceso de contratación. Si un proveedor estratégico rechaza una auditoría o una modificación de las condiciones, la organización debe documentar la brecha y elegir entre implantar un control compensatorio, aceptar formalmente el riesgo residual o cambiar de proveedor.

El plan de salida debe ser ejecutable antes de que se rescinda el contrato. Debería contemplar la devolución y transferencia de los datos en un formato utilizable, el apoyo a la migración, el mantenimiento de la continuidad durante la transición, la revocación de accesos, la eliminación de copias y la confirmación de estas actuaciones. Al mismo tiempo, deben conservarse los registros necesarios para fines legales, probatorios y de auditoría. Una comprobación práctica consiste en realizar una restauración de prueba de los datos con otro proveedor y verificar su integridad, el tiempo de migración y la posibilidad de desactivar las cuentas anteriores.

La modernización de la cartera de contratos debe comenzar por los servicios con mayor impacto sobre la actividad, priorizando las brechas según sus consecuencias y urgencia. Conviene comprobar la eficacia de los mecanismos adoptados mediante un ejercicio de gestión de incidentes y una auditoría por muestreo de las evidencias. Los resultados de las revisiones de SLA, incidentes, desviaciones, acciones correctivas y pruebas de salida mostrarán si los requisitos funcionan en la práctica o siguen siendo únicamente disposiciones contractuales.

El alcance de la evaluación puede vincularse con el artículo Auditoría NIS2 en una empresa industrial: cómo comprobar si la organización está preparada para las nuevas obligaciones. Las obligaciones de la organización deben determinarse teniendo en cuenta su condición, cuestión que se analiza en Directiva NIS2: ¿a quién afecta y qué empresas deben cumplir los nuevos requisitos?