Es viernes por la tarde y una falla de almacenamiento ha afectado a varios sistemas. Además de restaurar el servicio, un segundo reloj está en marcha: si se trata de una incidencia importante, debe ser reportada dentro de un plazo breve. Alguien pregunta: “¿Qué servicios se vieron afectados, cuántos usuarios y qué tan críticos son?” La respuesta se arma a partir de la monitorización, una hoja de cálculo de servicios y la memoria de colegas experimentados. Las mismas preguntas vuelven a surgir durante una inspección – solo más tarde, y con una solicitud de evidencia.
Lo que piden las regulaciones
NIS2 y DORA difieren en alcance y en sus autoridades supervisoras, pero desde el punto de vista de las operaciones de TI, los mismos requisitos siguen volviendo:
- conocer el impacto de una interrupción en los servicios y su criticidad,
- reportar incidencias importantes dentro de plazos establecidos y con evidencia suficiente,
- gestionar cambios y vulnerabilidades y poder mostrar quién aprobó qué,
- mantener una visión general de los servicios y proveedores de TIC de los que dependen las operaciones,
- rastrear la responsabilidad – quién es el propietario del servicio y quién cambió qué, cuándo.
Ninguno de estos requisitos es nuevo. Lo nuevo es la presión para que las respuestas sean rápidas, completas y demostrables.
Lo que cubre Stilla hoy
La base de las respuestas regulatorias es la información que Stilla mantiene para las operaciones diarias:
- Un mapa de dependencias desde el servicio de negocio hasta la infraestructura y el cálculo de impacto que tiene en cuenta la redundancia – clústeres, replicación de bases de datos, almacenamiento espejado.
- Un propietario para cada servicio, roles delimitados y una matriz RACI que Stilla verifica con permisos.
- Un registro de auditoría inmutable durante cinco años; para la configuración, se almacena el estado antes y después de un cambio.
- Cambios gestionados aprobados por el propietario del servicio afectado, ventanas de mantenimiento y congelaciones de cambios.
- Contratos de servicio y SLA de proveedores, incluida la escalada de incidencias al proveedor según el contrato.
- Vulnerabilidades por servicio con plazos por gravedad, distinguiendo fallas activamente explotadas.
Cuando ocurre una incidencia, Stilla muestra los servicios afectados a partir del mapa de dependencias, no a partir de una estimación. El propietario del servicio se puede rastrear y el historial de cambios muestra qué ha cambiado en los días recientes.
Qué está en preparación
Sobre esta información estamos construyendo resultados regulatorios que aún no forman parte del producto:
- Clasificación de incidencias importantes contra criterios NIS2 y DORA, derivados del impacto en la CMDB,
- Un informe prellenado con línea de tiempo e impacto,
- Un registro de servicios y proveedores de TIC bajo DORA.
El principio seguirá siendo el mismo que en el resto del producto: Stilla prepara la evidencia, una persona siempre decide y envía. Confirmaremos el momento de lanzamiento con clientes piloto.
Dónde empezar
Una respuesta regulatoria solo es tan buena como la información que la respalda. Es por eso que recomendamos empezar donde se paga sin regulación: con los servicios clave, sus propietarios y el mapa de dependencias. Quien tenga esto en orden tiene la mayor parte del trabajo hecho – y el viernes por la tarde responde con datos, no con memoria.
Stilla no reemplaza la evaluación legal. Revisa las obligaciones específicas de tu organización con tu equipo de cumplimiento.
Stilla Standard
Para organizaciones que desean una CMDB fiable y procesos de ITSM gestionados.