NIS2 y KSC 2026: checklist de ciberseguridad para empresas

NIS2 y la modificación polaca de la Ley del Sistema Nacional de Ciberseguridad (KSC) ya no son un tema regulatorio lejano. Para muchas organizaciones en Polonia, 2026 significa comprobar si la empresa está cubierta por las nuevas obligaciones y después ordenar la ciberseguridad en la práctica: accesos, backups, monitorización, procedimientos de incidentes y responsabilidad directiva.

Este material no es asesoramiento legal. Es una checklist IT práctica para propietarios, juntas directivas, responsables de operaciones y personas a cargo de tecnología. Ayuda a evaluar si la organización tiene bases operativas para un análisis posterior de KSC/NIS2.

Qué cambió en 2026

Según la información publicada por el Ministerio de Digitalización de Polonia, la modificación de KSC entró en vigor el 3 de abril de 2026. Desde esa fecha empezaron a correr los plazos para las entidades cubiertas por las nuevas normas.

Fechas clave:

• 3 de abril de 2026 - entrada en vigor de la modificación KSC,
• 7 de mayo de 2026 - inicio de la autorregistración en el registro KSC,
• 3 de octubre de 2026 - fecha límite para presentar solicitud de inscripción para entidades obligadas a autorregistrarse,
• 3 de abril de 2027 - fecha límite para implantar obligaciones para entidades clave e importantes que cumplían criterios al entrar en vigor la ley,
• 3 de abril de 2028 - fecha límite para la primera auditoría obligatoria de ciberseguridad para entidades clave.

La información oficial debe verificarse siempre en la fuente:

• entrada en vigor de la modificación KSC,
• a quién afecta la modificación KSC,
• autorregistración en el registro KSC.

A quién puede afectar KSC y NIS2

La modificación KSC sustituyó la división anterior por entidades clave y entidades importantes.

En la práctica las empresas deben comprobar:

• si operan en un sector indicado en la ley,
• si cumplen criterios de tamaño,
• si entran en el registro KSC de oficio o deben autorregistrarse,
• si proveedores tecnológicos soportan procesos críticos,
• si sus servicios digitales son relevantes para la continuidad de clientes o mercado.

Este análisis debe hacerse con abogado o asesor de compliance. IT no debe decidir por sí solo la calificación legal. IT debe preparar hechos: sistemas, procesos, proveedores, contratos, integraciones y controles.

Por qué es un tema operativo, no solo legal

El mayor error es tratar KSC/NIS2 como un documento a rellenar. En la práctica las regulaciones afectan la gestión diaria de tecnología.

Si la empresa no sabe quién tiene acceso a producción, cuándo se probó el último backup, dónde llegan las alertas o quién decide durante una incidencia, el problema no es formal. Es riesgo operativo.

KSC/NIS2 obligan a ordenar áreas que deberían estar bajo control:

• gestión de riesgos,
• supervisión de proveedores,
• continuidad de negocio,
• respuesta a incidentes,
• seguridad de accesos,
• documentación de sistemas y responsabilidades,
• pruebas y auditorías periódicas.

Checklist de ciberseguridad

Esta lista no sustituye una auditoría de compliance. Da un punto de partida práctico para ver rápido las brechas principales.

1. Responsable de ciberseguridad

Primero hay que definir quién responde realmente por ciberseguridad.

Comprueba:

• si dirección o propietario asignó responsabilidad de IT y ciberseguridad,
• si existe un modelo RACI simple,
• si el equipo técnico sabe cuándo escalar una incidencia a negocio,
• si hay contactos de emergencia para socio IT, hosting, proveedor de sistema y operador de dominio,
• si la responsabilidad de aplicaciones, web, infraestructura y puestos no está fragmentada sin coordinación.

Sin responsable, durante una incidencia la empresa pierde tiempo decidiendo quién puede decidir.

2. Inventario de sistemas y procesos críticos

No se puede proteger un entorno que nadie ha descrito.

Prepara como mínimo:

• lista de aplicaciones de negocio,
• lista de webs, tiendas, paneles de cliente y landing pages,
• lista de bases de datos y ubicaciones de backup,
• lista de proveedores SaaS,
• lista de dominios, certificados y cuentas de hosting,
• lista de integraciones con CRM, ERP, pagos, correo, analítica y automatización,
• identificación de sistemas críticos para ventas, atención al cliente, finanzas y operaciones.

Prueba práctica: si mañana se marcha la persona técnica principal, ¿la empresa sabe dónde están repositorios, servidores, dominios, accesos administrativos, backups y documentación?

3. Cuentas, permisos y MFA

En muchas empresas el mayor riesgo no es un ataque avanzado, sino permisos demasiado amplios.

Comprueba:

• si todas las cuentas administrativas tienen MFA,
• si exempleados o exproveedores aún conservan accesos,
• si las cuentas compartidas están limitadas o reemplazadas por cuentas nominales,
• si el acceso a producción se concede solo a quien lo necesita,
• si onboarding y offboarding incluyen gestión de accesos,
• si los permisos se revisan al menos trimestralmente.

Regla simple: menos privilegios permanentes, más control y trazabilidad.

4. Backups y pruebas de restauración

Un backup sin prueba de restauración es una suposición, no una protección.

La empresa debe saber:

• qué sistemas se copian,
• con qué frecuencia,
• cuánto tiempo se retienen las copias,
• quién puede restaurar datos,
• cuánto tarda recuperar un sistema crítico,
• si existe una copia resistente a borrado accidental o ransomware,
• cuándo fue la última prueba de restauración.

Define dos parámetros:

• RPO: cuántos datos puede perder la empresa,
• RTO: con qué rapidez debe volver el sistema.

Sin estos números, la continuidad de negocio queda demasiado genérica.

5. Monitorización, logs y alertas

La organización debe detectar problemas antes que el cliente.

Mínimo de monitorización:

• uptime de web y aplicaciones,
• errores 5xx y errores críticos de aplicación,
• uso de recursos de servidores y bases de datos,
• intentos fallidos de login,
• cambios de permisos administrativos,
• certificados y dominios próximos a caducar,
• éxito de backups,
• alertas de seguridad de cloud, hosting y SaaS.

También importa dónde llega la alerta. Una alerta enviada a un buzón que nadie lee no reduce riesgo.

6. Procedimiento de incidentes

Una incidencia no es el momento de diseñar el proceso.

Un runbook mínimo debe definir:

• qué consideramos incidencia crítica,
• quién recibe el aviso,
• quién evalúa impacto,
• quién decide rollback, bloqueo de cuentas o desconexión de integraciones,
• cómo comunicamos internamente,
• quién comunica con clientes o socios,
• qué logs y evidencias se conservan,
• cómo documentamos el evento,
• cuándo hacemos postmortem.

Un buen runbook acorta el tiempo del caos a la decisión.

7. Seguridad de aplicaciones y web

KSC/NIS2 suele empezar por compliance, pero el riesgo práctico aparece en código, configuración y despliegues.

Comprueba:

• si los repositorios tienen responsables y permisos protegidos,
• si CI/CD no guarda secretos en código,
• si las dependencias se actualizan,
• si las rutas críticas tienen tests,
• si existe rollback,
• si formularios, paneles admin y API están monitorizados,
• si la web tiene cabeceras de seguridad actuales,
• si la aplicación tiene rate limits y protección contra abuso.

Si la empresa desarrolla una aplicación existente, combina KSC/NIS2 con reducción de deuda técnica. Lo explicamos en: Mantenimiento de aplicaciones: cómo reducir la deuda técnica.

8. Proveedores y contratos

El IT moderno es una cadena de proveedores: hosting, cloud, SaaS, software house, agencia web, correo, analítica, CRM y helpdesk.

Prepara:

• lista de proveedores que soportan procesos críticos,
• datos a los que tienen acceso,
• responsable de negocio de cada contrato,
• requisitos SLA y tiempos de respuesta,
• procedimientos de escalación,
• reglas de entrega de documentación y accesos,
• plan de contingencia si un proveedor no está disponible.

El modelo más arriesgado es aquel donde cada proveedor posee un fragmento y nadie responde por el conjunto.

Plan 30/60/90 días

Si KSC/NIS2 acaba de llegar a la mesa directiva, no empieces con un proyecto de muchos meses. Empieza por ordenar hechos y reducir riesgos altos.

Primeros 30 días

• comprobar si la empresa puede estar cubierta por KSC/NIS2,
• preparar listas de sistemas, proveedores, dominios, integraciones y datos,
• activar MFA en cuentas administrativas,
• retirar accesos innecesarios,
• confirmar que los backups existen y están monitorizados,
• monitorizar servicios críticos,
• nombrar responsable del proceso en negocio.

Días 31-60

• ejecutar una prueba de restauración,
• preparar un runbook básico de incidentes,
• ordenar accesos de proveedores,
• describir RTO/RPO para sistemas críticos,
• revisar logs y alertas,
• eliminar vulnerabilidades urgentes en web y aplicaciones,
• definir un informe mensual de riesgos IT.

Días 61-90

• crear roadmap trimestral de ciberseguridad,
• conectar requisitos KSC/NIS2 con presupuesto IT,
• introducir revisión periódica de permisos,
• definir estándares para nuevos sistemas y proveedores,
• planificar auditoría o revisión de compliance,
• preparar informe para dirección: riesgos, estado, decisiones y costes.

Errores habituales

1. Esperar hasta el último plazo

Los plazos formales son una cosa. Preparar documentación, accesos, backups, monitorización y procedimientos puede llevar meses.

2. Tratar ciberseguridad como coste IT

La ciberseguridad protege continuidad de ventas, servicio, producción y finanzas. Es riesgo de negocio, no solo técnico.

3. Falta de una parte responsable

Si la aplicación la lleva un software house, la web una agencia, hosting un administrador y correo otro proveedor, la empresa necesita coordinación.

4. Falta de evidencias

En muchas organizaciones los controles “existen”, pero nadie puede demostrar cuándo se probó un backup, quién aprobó acceso, cuándo se revisaron permisos o quién recibió una alerta.

Resumen

NIS2 y KSC en 2026 no son solo temas formales. Son una buena ocasión para comprobar si la empresa controla bases de ciberseguridad:

1. responsable claro,
2. lista de sistemas y proveedores,
3. cuentas seguras y MFA,
4. backups con pruebas,
5. monitorización y logs,
6. procedimientos de incidentes,
7. modelo ordenado de proveedores.

Si necesitas un socio que pase de checklist a cambios operativos, consulta Socio IT.