Jueves por la tarde. El director de una empresa de software de diez personas en Bratislava abre un correo de su mayor cliente. Un banco. Adjunto hay un largo cuestionario de ciberseguridad sobre cifrado de datos, respuesta a incidentes, pruebas de penetración, gestión de accesos, copias de seguridad y recuperación ante desastres.
La empresa tiene un buen producto SaaS de nóminas que usan cientos de clientes. Su proceso de respuesta a incidentes no está formalizado, y la última prueba de penetración ya no cubre la versión actual. No puede dar al banco respuestas verificables.
Esto ocurre cada vez con más frecuencia. El motivo tiene nombre: NIS2.
NIS2 (Network and Information Security Directive 2) es una directiva de la UE. Eslovaquia la transpuso mediante una modificación de la Ley n.º 69/2018 de Ciberseguridad, en vigor desde el 1 de enero de 2025. Cubre a entidades de sectores como la energía, el transporte, la sanidad, la infraestructura digital y determinados servicios digitales. El alcance exacto debe comprobarse según la ley eslovaca, no deducirse solo del tamaño de la empresa.
Puede que su empresa de software no esté en esa lista. Algunos de sus clientes sí.
NIS2 obliga a las entidades reguladas a gestionar los riesgos de seguridad en toda su cadena de suministro. El artículo 21 hace referencia expresa a «la seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad en lo que respecta a las relaciones entre cada entidad y sus proveedores directos o proveedores de servicios». En la práctica esto significa que un banco que usa su sistema de nóminas es responsable de garantizar que usted, como proveedor, cumple un determinado nivel de seguridad.
Así que NIS2 no regula directamente a su empresa y aun así acaba en su mesa. Sus clientes empezarán a hacerle preguntas que tendrá que saber responder. Si no puede, buscarán alternativas.
¿Qué espera un cliente corporativo de un proveedor SaaS? A partir de los cuestionarios que vemos en nuestros clientes, varios ámbitos se repiten.
¿Quién tiene acceso a los datos de producción? ¿Cómo se conceden y revocan los permisos? ¿Tiene MFA para los administradores? ¿Sigue el principio de mínimo privilegio? Cuando un desarrollador deja la empresa, ¿cuánto tarda en revocarse su acceso a la infraestructura?
La mayoría de las pequeñas empresas de software gestionan los accesos de forma improvisada. La mitad del equipo conoce la contraseña de administrador de la base de datos. Las claves SSH no se rotan. Un empleado que se marcha sigue teniendo acceso a producción una semana después porque «no nos dio tiempo a revocarlo». Para un cliente corporativo, esto es inaceptable.
Use una versión de TLS actualmente soportada en tránsito y un cifrado fuerte con claves gestionadas en reposo. Abarque bases de datos, copias de seguridad y registros. Una copia de seguridad sin cifrar o unos registros sin un control de acceso adecuado son riesgos graves.
¿Analiza las dependencias? ¿Con qué frecuencia? ¿Qué ocurre cuando aparece una CVE crítica en una biblioteca que usa? Fije plazos de corrección basados en el riesgo y conserve pruebas de que los problemas se evaluaron y corrigieron. Una lista de materiales de software (SBOM) puede ayudar al cliente a evaluar más rápido el impacto de una nueva vulnerabilidad.
Revisión de código, análisis estático y pruebas de seguridad antes de publicar. Si solo revisa el código de vez en cuando y no tiene análisis de seguridad automatizados, este es el primer punto a mejorar. Los clientes preguntarán por su proceso de SDLC. Si no lo tiene documentado, «hacemos revisión de código» no es una respuesta suficiente.
NIS2 obliga a las entidades reguladas a notificar los incidentes de seguridad. En las 24 horas siguientes a la detección debe llegar una alerta temprana, en 72 horas una notificación detallada y en un mes el informe final.
Como proveedor, esto le afecta de forma indirecta. Si se produce una filtración de datos en su sistema SaaS, su cliente (el banco, la aseguradora) debe notificar el incidente al regulador. Y necesitará información de usted. Qué ocurrió, cuándo, cuál fue el alcance, qué datos se vieron afectados y qué medidas tomó.
Sin un plan de respuesta a incidentes, no podrá facilitar esta información a tiempo. «Le avisaremos cuando lo hayamos investigado» no es una respuesta que un banco acepte cuando tiene 24 horas para notificar a un regulador.
Un plan de respuesta a incidentes para una empresa pequeña no tiene por qué ser un documento de 50 páginas. Necesita saber quién es la persona de contacto, qué canal de comunicación usar, quién puede apagar el sistema, dónde están los registros y quién puede analizarlos. El proceso debe estar por escrito, probarse con regularidad y actualizarse tras cambios importantes en el sistema.
Los registros de eventos ayudan en las investigaciones de seguridad y en otras obligaciones. Por ejemplo, los sistemas de IA de alto riesgo según la Ley de IA también necesitan un registro adecuado. No necesita una plataforma de registro distinta para cada normativa. Necesita un único registro de auditoría bien diseñado que abarque los eventos de seguridad, las decisiones de IA y los cambios de datos importantes.
En la práctica, esto significa registros estructurados con marca de tiempo, identidad del actor, tipo de acción y resultado. El periodo de conservación debe ajustarse a la finalidad, el riesgo, el contrato y las normas aplicables. No existe un periodo universal único para cada sistema. Los registros deben ser resistentes a la manipulación y estar disponibles para auditoría sin pasar dos días rebuscando en archivos de texto ilegibles.
La seguridad de la cadena de suministro según NIS2 significa que su cliente regulado querrá pruebas. No promesas. Pruebas.
Formularios estandarizados (a menudo basados en el CAIQ de la Cloud Security Alliance, o en una plantilla propia del cliente) en los que responde a preguntas sobre cifrado, accesos, pruebas y políticas de copias de seguridad. Si no tiene las respuestas preparadas, cada cuestionario le costará días de trabajo.
Un cliente puede pedir la ISO 27001 u otra prueba independiente. La certificación no sustituye a los controles técnicos que funcionan. Sin ella, necesita otra vía acordada para demostrar que los procesos existen y funcionan.
Fije el alcance y la frecuencia según el riesgo y el contrato, con un tester independiente para los sistemas importantes. El cliente querrá ver el informe y la prueba de que las vulnerabilidades encontradas se corrigieron. Un informe de una versión desfasada del sistema no servirá.
Acuerde tiempos de respuesta y de corrección según la gravedad y el riesgo real de explotación. Si publica una vez al mes y descubre un fallo crítico que se está explotando activamente, necesita una vía para lanzar una corrección fuera del ciclo habitual.
Si opera un SaaS multiinquilino (multi-tenant) sobre infraestructura compartida, los clientes afectados por NIS2 esperarán un aislamiento de datos verificable.
El cliente A nunca debe ver los datos del cliente B. Ni por un error de la aplicación, ni por una consulta mal configurada, ni por una fuga en los registros. Una base de datos compartida con una columna tenant_id le da un aislamiento lógico, y algunos clientes corporativos querrán en su lugar una base de datos o un esquema separados. Elija lo que elija, la arquitectura tiene que mostrar con claridad cómo impone ese aislamiento y cómo lo prueba.
Con las copias de seguridad es donde esto se suele pasar por alto. Si respalda toda la base de datos de una vez, restaurar a un solo inquilino puede implicar los datos de todos los clientes. Determine de antemano cómo se puede restaurar a un único cliente de forma segura, sin tocar a los demás y sin exponerlos.
El RGPD y NIS2 se cruzan aquí. Para una solicitud de supresión, necesita un procedimiento documentado para eliminar el acceso en los sistemas activos y tratar los datos en las copias de seguridad según el calendario de conservación aplicable. Con copias de seguridad compartidas, eso no es trivial.
Si es una empresa de software que vende a clientes regulados, empiece aquí.
Identifique cuáles de sus clientes están regulados (bancos, aseguradoras, centros sanitarios, empresas energéticas) y qué requisitos de seguridad tendrán. Si no lo sabe, pregúnteles directamente. Es mejor prepararse con seis meses de antelación que sacar adelante un cuestionario a contrarreloj.
Formalice su plan de respuesta a incidentes. No tiene por qué ser largo, pero debe existir, estar actualizado y haberse probado.
Implemente el análisis automatizado de dependencias y fije plazos de corrección basados en el riesgo. Es una de las formas más rápidas de mejorar su nivel de seguridad sin una gran inversión.
Plantéese la certificación ISO 27001 cuando sus clientes o su segmento objetivo la exijan. Empiece por los controles que funcionan, porque un certificado no los sustituye.
Si no está seguro de por dónde empezar, póngase en contacto. Hacemos evaluaciones de seguridad y diseño de arquitectura para empresas que necesitan cumplir los requisitos de clientes regulados. También hablamos de la estrategia nacional de ciberseguridad de Eslovaquia y su impacto en los proveedores de TI en un artículo aparte.
Fundador y responsable técnico de Rise.sk. Diseña y entrega aplicaciones web, sistemas de datos y automatizaciones, y escribe sobre decisiones de software, IA y servicios digitales.
El Reglamento de Resiliencia Operativa Digital (DORA) de la UE está cambiando la forma en que las entidades financieras seleccionan y gestionan a sus proveedores de TI. Si desarrolla software para bancos o aseguradoras, esto es lo que necesita saber.
Los modelos chinos están ahora a meses, no a años, de la frontera estadounidense, y a una fracción del coste. Para una empresa europea la verdadera pregunta no es quién gana la carrera, sino si conviene usarlos y cómo.
La AI Act no es solo un tema jurídico. Las empresas necesitan un inventario de las herramientas de IA, los responsables, los datos, los riesgos, los registros, la revisión humana y las responsabilidades de los proveedores.
Su contexto determina la respuesta
