Subcontratistas de la NIS2: una microempresa con menos de 50 empleados no suele verse afectada directamente por la directiva, pero sí puede verse afectada desde el punto de vista comercial si presta servicios a una empresa regulada. En la práctica, hay que estar preparado para cuestionarios de seguridad, cláusulas contractuales y pruebas sencillas: copias de seguridad, gestión de accesos, actualizaciones y plan de respuesta ante incidentes. La verdadera cuestión es el efecto en cadena en la cadena de suministro.
Subcontratistas de NIS2: por qué se produce el efecto en cadena
La Directiva europea NIS2, adoptada el 14 de diciembre de 2022 con el nombre de Directiva (UE) 2022/2555, sustituye a la anterior Directiva NIS de 2016. Entró en vigor el 16 de enero de 2023 y los Estados miembros debían transponerla a su legislación nacional a más tardar el 17 de octubre de 2024.
Su objetivo es fácil de entender: elevar el nivel de ciberseguridad las organizaciones consideradas esenciales o importantes para la economía y la sociedad. Esto abarca, en particular, determinados sectores digitales, industriales, sanitarios, energéticos, financieros o de transporte, según criterios de tamaño y actividad.
El punto que lo cambia todo para los proveedores se encuentra en el artículo 21. Las entidades reguladas deben gestionar la seguridad de su cadena de suministro, es decir, la seguridad relacionada con sus proveedores directos, sus editores, sus proveedores de alojamiento, sus gestores de sistemas, sus agencias web o sus proveedores de servicios digitales.
En otras palabras, aunque su empresa no entre dentro del ámbito de aplicación directo de la NIS2, es posible que su cliente tenga que comprobar que usted no se convierta en su punto débil. No se trata tanto de una obligación reglamentaria directa como de una condición de confianza y, en ocasiones, de mercado.
¿Se ven afectadas las microempresas por la NIS2?
En Francia, según la información publicada por la ANSSI y MesServicesCyber en 2026, las «entidades afectadas» incluyen, en particular, a aquellas organizaciones que emplean al menos a 50 personas o superan los 10 millones de euros de volumen de negocio y de balance anual, siempre que pertenezcan a los sectores contemplados. Por lo tanto, una microempresa de 12 personas que desarrolle un sitio web, una API o una aplicación para un cliente afectado no está automáticamente sujeta a la NIS2.
Pero esta distinción es engañosa. El Centro Nacional de Ciberseguridad de Irlanda, en sus preguntas frecuentes sobre la NIS2, explica claramente que una organización puede verse afectada indirectamente si forma parte de la cadena de suministro de una o varias entidades NIS2. No se trata de una transposición mágica de la directiva a todos los pequeños proveedores. Es una consecuencia de la gestión del riesgo de los proveedores.
A fecha de 8 de julio de 2026, Francia aún no había notificado sus medidas nacionales de transposición a la Comisión Europea, que, por otra parte, ha llevado a Francia, Irlanda, España y los Países Bajos ante el Tribunal de Justicia de la Unión Europea por este retraso. La ANSSI sigue indicando que la transposición francesa está pendiente y ofrece un servicio de prerregistro.
Este retraso no debe tranquilizar a tort. Los grandes donantes de ordre, las empresas de tamaño medio y las empresas reguladas ya están preparando sus compras, sus contratos y sus auditorías internas. En los proyectos que llevamos a cabo, vemos a menudo cómo la ciberseguridad pasa de ser un tema técnico que se aborda al final del proceso a convertirse en un criterio de selección ya desde la convocatoria de la licitación.
Lo que tus clientes pueden pedirte a partir de ahora
El Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, establece requisitos técnicos y metodológicos para determinadas entidades digitales, en particular en lo que respecta a la política de seguridad de la cadena de suministro. Aunque no se aplique directamente a su empresa, influye en las prácticas de compra.
En la práctica, los requisitos suelen adoptar tres formas: un cuestionario de seguridad, cláusulas contractuales y, por último, solicitudes de pruebas. Las plataformas especializadas como NISD2.eu señalan en 2026 que muchos equipos de compras europeos elaboran sus propios cuestionarios para proveedores basados en los requisitos de la NIS2 relacionados con el riesgo de los proveedores.
Un cuestionario puede preguntar si utilizas la autenticación multifactorial, cómo realizas copias de seguridad de los datos, quién tiene acceso a los entornos de producción, cómo gestionas las medidas de seguridad o, por ejemplo, en cuánto tiempo avisas a un cliente en caso de incidente. Nada fuera de lo común. Pero si no hay nada documentado, responder correctamente se convierte rápidamente en una tarea laboriosa.
En el caso de una web de WordPress, por ejemplo, la pregunta no es solo «¿está actualizada la web?». La cuestión pasa a ser: ¿quién aplica las actualizaciones, en qué plazo, con qué copia de seguridad previa a la intervención, qué registro (historial de acciones), qué alojamiento y qué cortafuegos de aplicaciones? Para profundizar en este punto concreto, existe un marco específico en los impactos de NIS2 en un sitio WordPress.
- Una cláusula de notificación de incidencias en un plazo de entre 24 y 72 horas, en función de la gravedad y del contrato.
- La obligación de cifrar los accesos de administración y las copias de seguridad confidenciales.
- Una restricción de las cuentas compartidas, que son demasiado frecuentes en las pequeñas empresas.
- Requisitos de prueba: captura de la configuración, política interna, registro de accesos, informe de análisis.
- Una cláusula de subcontratación en cadena, en caso de que usted mismo delegue el alojamiento, el soporte técnico o el desarrollo.
Presupuesto, plazos: el ordre, unas dimensiones realistas para una estructura pequeña
La trampa habitual consiste en buscar una «conformidad NIS2» completa, aunque tu pequeña empresa no se encuentre dentro del ámbito de aplicación directo. Con este presupuesto, es mejor apostar por una base de seguridad demostrable: medidas sencillas, que se mantengan a lo largo del tiempo y que puedas explicar a un cliente sin tener que improvisar.
Los costes varían en función de su sistema informático, pero el mercado francés ofrece algunas referencias. Una pequeña empresa que parte de cero suele poder alcanzar un primer nivel sólido en pocas semanas, siempre que se mantenga pragmática.
| Acción | Plazo habitual | Presupuesto orientativo en Francia | Interés por un cliente NIS2 |
|---|---|---|---|
| Auditoría de seguridad básica de un sitio web o una aplicación | 3 à 10 jours | Entre 1 500 y 5 000 €, sin IVA | Detectar las deficiencias evidentes antes de realizar una encuesta o renovar un contrato |
| Implementación de la autenticación multifactorial (MFA), gestión de accesos y medidas básicas de seguridad | 1 a 3 semanas | Entre 1 000 y 4 000 €, sin IVA | Reducir el riesgo de que se comprometa la seguridad debido al robo de una contraseña |
| Política de copias de seguridad y restauración probada | 1 a 2 semanas | Alrededor de 800 a 3 000 € sin IVA | Demostrar la capacidad de recuperarse tras un incidente o un ataque de ransomware |
| Documentación del proveedor: procedimientos, justificantes, respuestas tipo | 1 a 3 semanas | Entre 1 500 y 6 000 €, sin IVA | Responder más rápido a los pedidos y limitar las cláusulas ambiguas |
| Prueba de intrusión dirigida a una aplicación expuesta | 1 a 3 semanas | Entre unos 4 000 y 12 000 €, sin IVA | Apporter: una prueba más sólida en un servicio crítico |
Estas cantidades no sustituyen a un presupuesto. Ofrecen una idea aproximada. Sinceramente, una prueba de intrusión completa solo se justifica si la aplicación maneja datos sensibles, expone una API crítica o depende de un cliente importante; en el caso de una simple página web de presentación, el dinero suele estar mejor invertido en el alojamiento, las actualizaciones, las copias de seguridad y la supervisión.
Las decisiones técnicas también son importantes. Un alojamiento compartido básico puede ser suficiente para una pequeña web institucional, pero resultará difícil de justificar para un cliente conectado a un sistema de negocio. OVHcloud, Scaleway, AWS, Microsoft Azure o Google Cloud pueden ser adecuadas en función de las necesidades, siempre que se configuren correctamente los accesos, los registros, las copias de seguridad y las responsabilidades contractuales.
¿Qué se debe exigir a los propios subcontratistas?
El efecto en cadena no se limita a ti. Si eres una agencia, un proveedor de software como servicio (SaaS), un proveedor de servicios informáticos o un integrador, tus propios proveedores también entran en la ecuación: el proveedor de alojamiento web, los autónomos, la herramienta de envío de correos electrónicos, el proveedor de mantenimiento, la solución de pago y el soporte técnico externalizado.
El enfoque adecuado no consiste en enviar un cuestionario de 120 preguntas a todo el mundo. Es contraproducente. Es mejor clasificar a tus proveedores según el riesgo: acceso a datos personales, acceso de administrador, acceso al código, acceso al entorno de producción y dependencia de la disponibilidad del servicio.
Un profesional autónomo que trabaja en una maqueta pública de Figma no supone el mismo nivel de riesgo que un administrador con acceso SSH (acceso seguro al servidor) al entorno de producción. Lo mismo ocurre con una API móvil: si da acceso a cuentas de usuario o a datos de negocio, el control debe ser más riguroso. Los riesgos relacionados con las interfaces suelen subestimarse; en este análisis se detalla un aspecto relevante sobre la seguridad de las API móviles.
El mínimo aceptable se resume en unos pocos requisitos: autenticación multifactorial, cuentas a nombre del titular, supresión de los accesos al finalizar la misión, copias de seguridad verificadas, cifrado de las comunicaciones y procedimiento de alerta en caso de incidente. Por parte de la agencia, lo habitual es solicitar pruebas sencillas pero concretas, en lugar de una declaración general del tipo «estamos protegidos».
La trampa en la que caen los que no son expertos en tecnología: la prueba
Muchas empresas cuentan con buenas prácticas internas. El director sabe que existen copias de seguridad, que el desarrollador actualiza la página web y que el proveedor de alojamiento es de confianza. El problema surge cuando un cliente solicita una prueba fechada, legible y con valor probatorio.
Una prueba puede ser sencilla: un procedimiento de una página, una captura de pantalla que muestre que la autenticación multifactorial (MFA) está activada en Microsoft 365 o Google Workspace, un informe de copia de seguridad, un informe de actualización de WordPress, un certificado de alojamiento, un registro de incidencias, aunque esté vacío. Sin estos elementos, su respuesta se basa únicamente en la confianza. En un proceso de compras, eso es insuficiente.
Otra trampa: aceptar cláusulas demasiado amplias. Algunas solicitudes obligan al proveedor a garantizar el pleno cumplimiento de la Directiva NIS2, aunque no se vea afectado directamente y no tenga el control de todo el sistema. Hay que replanteárselo. Puede comprometerse a adoptar medidas concretas, plazos de notificación, un ámbito técnico y responsabilidades compartidas. Pero no a lo imposible.
El RGPD, en vigor desde 2018, ya ha acostumbrado a las empresas a esta lógica de subcontratación documentada. La NIS2 añade un nivel de seguridad más operativo: continuidad, vulnerabilidades, incidentes y proveedores. Ambos temas suelen estar relacionados, sobre todo cuando un sitio web o una aplicación trata datos personales.
Crear una base de seguridad aceptable sin pagar de más
El Marco de Referencia Cyber France (ReCyF), versión 2.5, publicado por la ANSSI el 17 de marzo de 2026, propone 20 objetivos de seguridad como base de trabajo para la NIS2. Para una pequeña empresa con un perímetro directo hors, puede servir de guía, pero no como una lista de comprobación que deba aplicarse de forma mecánica en toda su extensión.
Empieza por los riesgos más probables. Las contraseñas débiles, las cuentas compartidas, las extensiones desactualizadas, las copias de seguridad que nunca se han probado y los accesos que se mantienen tras la salida de un proveedor causan más daños que los escenarios muy sofisticados. Es sencillo. Pero requiere un gran esfuerzo mantenerlo.
En una aplicación móvil, la seguridad no se limita a la aplicación Store ni a Play Store. Es necesario comprobar las claves secretas integradas, las llamadas a la API, la gestión de sesiones, los registros y las bibliotecas de terceros. Antes de la publicación, una Lista de comprobación de seguridad de aplicaciones móviles ya permite evitar fallos evidentes y costosos.
En passkeys, estandarizadas por la Alianza FIDO y adoptadas progresivamente por Apple, Google y Microsoft, también pueden reducir el riesgo asociado a las contraseñas en determinados usos. No sustituyen a una gestión adecuada de los accesos, pero pueden resultar adecuadas para cuentas de cliente o interfaces sensibles. Este tema debe evaluarse con realismo, en particular a través de esta guía sobre las claves de acceso para la página web.
Una buena base para una pequeña empresa proveedora suele basarse en seis aspectos clave: inventario de los servicios ofrecidos, análisis de la disponibilidad de los sistemas (MFA) en las cuentas críticas, copias de seguridad comprobadas, actualizaciones controladas, procedimiento de gestión de incidencias y documentación del proveedor. No es nada espectacular. Y precisamente por eso funciona.
Definir bien este tipo de proyecto desde el principio evita la mayoría de las sorpresas desagradables: requisitos imposibles, presupuesto mal planificado, plazos subestimados o responsabilidades poco claras con los proveedores. Una perspectiva externa ayuda sobre todo a distinguir lo que realmente protege la actividad de lo que solo complica el proyecto.
Preguntas frecuentes sobre NIS2 y los subcontratistas
¿Debe una microempresa con menos de 50 empleados estar sujeta al régimen NIS2?
En general, no, salvo en casos concretos relacionados con su actividad o con una futura normativa nacional. Sin embargo, puede verse obligada a cumplir determinados requisitos contractuales si presta servicios a una entidad esencial o importante.
¿Puede un cliente imponer cláusulas de la Directiva NIS2 a su proveedor?
Sí, dentro de los límites del contrato y del alcance real del servicio. Es mejor aceptar compromisos concretos sobre las medidas de seguridad, las pruebas y los plazos de alerta que una promesa general de confidencialidad.
¿Qué documentación hay que preparar para responder a un cuestionario NIS2 para proveedores?
Elabora una ficha de seguridad de entre 2 y 5 páginas: alojamiento, copias de seguridad, autenticación multifactorial (MFA), gestión de accesos, actualizaciones, subcontratistas y notificación de incidentes. Añade algunas pruebas sencillas y fechadas.
¿Sustituye la NIS2 al RGPD en lo que respecta a los encargados del tratamiento?
No. El RGPD se centra principalmente en los datos personales, mientras que la Directiva NIS2 aborda la ciberseguridad y la continuidad de los servicios. Ambas normativas se complementan cuando un proveedor maneja datos de clientes o usuarios.