Índice
El 11 de septiembre de 2001 casi 3.000 personas perdieron la vida en los atentados de Nueva York, Washington D.C. y Pensilvania. Antes de cualquier lección empresarial, merece la pena detenerse un momento a recordarlas: a ellas y a quienes las echan de menos cada año por estas fechas.
Aquel día, muchas empresas que operaban en el World Trade Center perdieron sus oficinas en cuestión de minutos. Algunas de ellas, sin embargo, siguieron operando como negocio ese mismo día. No porque tuvieran mejores oficinas, sino porque sus datos, sus sistemas y sus procesos críticos ya existían replicados en otro lugar.
Ese contraste marcó un antes y un después. Hasta entonces, la continuidad de negocio era un documento que muchas empresas tenían archivado "por si acaso". A partir de ese día, dejó de ser teoría.
En los años posteriores al 11-S nació y se profesionalizó toda una industria alrededor de la recuperación ante desastres. Las empresas financieras y tecnológicas empezaron a exigir centros de datos redundantes, geográficamente separados entre sí, capaces de asumir la operación si el principal caía.
Los backups dejaron de ser una tarea de mantenimiento y pasaron a ser una decisión estratégica. Se empezó a hablar de tiempos de recuperación, de puntos de recuperación, de pruebas periódicas de esos planes. No bastaba con tener una copia de seguridad: había que demostrar que funcionaba cuando se necesitaba.
Hoy la mayoría de las empresas no dependen de un edificio. Dependen de su software. Un servidor caído, un ataque de ransomware, un proveedor cloud con una interrupción o una brecha de seguridad en un tercero con el que trabajas, pueden paralizar tu operación con la misma contundencia que un desastre físico, solo que con mucha más frecuencia.
La lección del 11-S sigue siendo válida, solo que el escenario ha cambiado de lugar: ya no se trata de tener una oficina alternativa, sino de tener sistemas que puedan seguir funcionando o recuperarse rápido, cuando algo falla.
La Unión Europea ha traducido esa lección en ley. La Directiva NIS2 (Directiva UE 2022/2555) se adoptó en enero de 2023 y los Estados miembros debían transponerla a su legislación nacional antes del 17 de octubre de 2024, fecha a partir de la cual empezó a aplicarse su exigibilidad.
Su objetivo es elevar el nivel común de ciberseguridad en la Unión Europea, obligando a las empresas de sectores considerados esenciales o importantes a demostrar que pueden gestionar riesgos digitales y seguir operando ante un incidente, no solo intentar evitarlo.
Más allá del lenguaje legal, el Artículo 21 de la directiva concreta un conjunto de medidas mínimas que las empresas afectadas deben implementar. Entre ellas:
Análisis y gestión de riesgos: identificar qué puede fallar y cuál sería el impacto.
Gestión de incidentes: procedimientos claros para detectar, responder y notificar.
Continuidad de negocio: copias de seguridad probadas, gestión de crisis y planes de recuperación.
Seguridad en la cadena de suministro: evaluar también el riesgo que introducen tus proveedores y herramientas.
Control de accesos y cifrado: medidas básicas de higiene que siguen siendo, sorprendentemente, las más incumplidas.
Notificación temprana: obligación de informar a las autoridades en un plazo de 24 horas tras detectar un incidente significativo.
La directiva no impone una tecnología concreta. Exige un enfoque de "todos los riesgos", proporcional al tamaño y la actividad de cada empresa, pero exige que exista, esté documentado y se pueda demostrar.
NIS2 afecta a empresas medianas y grandes de numerosos sectores: energía, transporte, salud, banca, infraestructuras digitales, proveedores cloud y también fabricantes y proveedores de servicios que operan en cadenas de suministro reguladas. Como referencia habitual, se sitúa el umbral en torno a los 50 empleados o los 10 millones de euros de facturación en sectores regulados, aunque conviene verificar el caso concreto.
El incumplimiento no es una advertencia sin consecuencias. Las sanciones pueden alcanzar los 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor y por primera vez la dirección de la empresa puede ser considerada personalmente responsable en casos de negligencia grave.
Es fácil confundir ambos conceptos, pero cumplen funciones distintas. La seguridad trabaja para que el incidente no ocurra: control de accesos, cifrado, actualizaciones, buenas prácticas de desarrollo. La resiliencia asume que, tarde o temprano, algo va a fallar de todos modos y se centra en que el negocio pueda seguir operando cuando eso pase.
Un software puede ser muy seguro y, aun así, no ser resiliente: si cae, tarda semanas en recuperarse. Y puede ser resiliente sin ser seguro: se recupera rápido, pero sigue siendo vulnerable al mismo ataque. Las empresas que gestionan bien el riesgo trabajan ambas dimensiones a la vez, no como fases separadas.
Para un equipo de desarrollo, esto no es teoría legal, son decisiones concretas de arquitectura y proceso:
Copias de seguridad automáticas, almacenadas fuera del entorno principal, con restauraciones probadas periódicamente y no solo configuradas y olvidadas.
Entornos con redundancia real, de forma que la caída de un componente no derive en la caída de todo el sistema.
Monitorización activa y alertas que permitan detectar un incidente en minutos, no en días.
Un procedimiento documentado de respuesta a incidentes, con roles claros de quién hace qué.
Control de accesos basado en el principio de mínimo privilegio y cifrado de datos sensibles tanto en tránsito como en reposo.
Evaluación de los proveedores y librerías externas que forman parte de tu stack, porque su vulnerabilidad es también la tuya.
En muchos proyectos, la seguridad y la resiliencia se abordan al final, como un extra que se añade si sobra presupuesto o tiempo. Es exactamente al revés de cómo debería plantearse.
Las señales de alarma más comunes: no existe un plan de qué hacer si el sistema cae, nadie ha probado nunca una restauración real de las copias de seguridad, el acceso a sistemas críticos lo tienen más personas de las necesarias o no hay ningún proceso para evaluar el riesgo que introduce una nueva integración o proveedor antes de ponerla en producción.
Ninguna de estas cosas es cara de resolver si se plantea desde el diseño. Todas son muy caras de resolver después de un incidente.
No hace falta el presupuesto de un banco para aplicar el espíritu de NIS2. La proporcionalidad está en el propio texto de la directiva: lo que se exige a una pyme no es lo mismo que a una infraestructura crítica, pero el principio es el mismo.
Empezar por un inventario simple: qué sistemas son críticos y qué pasaría si dejaran de funcionar un día entero.
Asegurarse de que las copias de seguridad existen, están fuera del sistema principal y se han restaurado al menos una vez de verdad.
Revisar quién tiene acceso a qué y retirar accesos que ya no se necesitan.
Tener un documento breve, aunque sea de una página, con los pasos a seguir si un sistema clave falla.
Incorporar estas preguntas en cualquier decisión de desarrollo o de elección de proveedor tecnológico, no solo cuando ya hay un problema.
El 11-S enseñó a las empresas que la continuidad de negocio no se improvisa el día que se necesita. NIS2 convierte esa lección en una obligación legal para el mundo del software, con plazos, sanciones y responsabilidad directa para quienes toman las decisiones.
La pregunta que de verdad importa no es si tu empresa sufrirá un incidente. Es si, cuando ocurra, tu software está construido para seguir funcionando.
Cuéntanos qué sistemas dependen de tu software hoy y te ayudamos a construirlos para que resistan.
Es la capacidad de un sistema para seguir funcionando o recuperarse rápido, cuando algo falla: un servidor caído, un error humano, un ciberataque. Importa porque determina si un incidente te cuesta minutos o semanas.
Es la normativa europea de ciberseguridad que obliga a empresas de sectores clave a implementar medidas de gestión de riesgos, continuidad de negocio y notificación de incidentes. Afecta a empresas medianas y grandes de numerosos sectores, no solo a infraestructuras críticas.
Puede estarlo de forma indirecta, si eres proveedor de una empresa que sí está regulada o de forma directa si operas en uno de los sectores incluidos y superas los umbrales de tamaño. Conviene verificarlo caso por caso.
La seguridad busca evitar que ocurra el incidente. La resiliencia asume que ocurrirá y se centra en que el negocio pueda seguir funcionando de todos modos. Ambas son necesarias y se complementan.
Las sanciones pueden alcanzar los 10 millones de euros o el 2% de la facturación anual, lo que sea mayor, además de responsabilidad personal para la dirección en casos de negligencia grave.
Empezando por lo básico bien hecho: copias de seguridad probadas de verdad, control de accesos, un plan simple de qué hacer si algo falla y una arquitectura que no dependa de un único punto de fallo.
La satisfacción de nuestros clientes es nuestra mejor carta de presentación.
"Tengo un negocio de Paquetería, en el que vienen muchas personas diariamente, tanto para recoger como para dejar paquetes. Llevábamos años gestionando muchos de nuestros procesos de paquetería de forma manual, y gracias a Blimbur Technologies hemos dado un salto enorme. Nos desarrollaron una app móvil y una web totalmente adaptadas a nuestro flujo de trabajo, con las que ahora tenemos todo automatizado, trazable y mucho más rápido. Ahora, el cliente sabe si tenemos el paquete y al estar todo mucho más organizado, es mucho más rápido y ágil, lo que hace que los clientes vengan y se vayan con otra cara y sin esperas. El trato ha sido impecable y el resultado, todavía mejor. Un equipo serio, técnico y que se implica de verdad."
