NIS2 y su sitio web: lo que sus clientes le preguntarán como proveedor

El correo llega de un cliente con el que trabaja desde hace años. Adjunta un cuestionario de seguridad para proveedores: decenas de preguntas sobre cifrado, parches, copias de seguridad e incidentes, con entrega a final de mes. Usted dirige una empresa pequeña. No es un banco, ni un hospital, ni una eléctrica. ¿A qué viene este interés repentino?

A que su cliente muy probablemente está sujeto a NIS2, la directiva de la UE sobre ciberseguridad, que le hace responsable de la seguridad de su cadena de suministro. A usted no le impone ninguna obligación directa. El cuestionario es la forma en que su cliente cumple su propia obligación y la deja por escrito.

Este artículo explica qué dice la norma, cuáles de esas preguntas responden por usted su sitio web público y su dominio de correo, y cómo reunir las pruebas antes de que nadie se las pida. No es asesoramiento jurídico. Si no está seguro de si su propia empresa entra en NIS2, consulte primero la guía de su autoridad nacional.

De dónde salen las preguntas

La Directiva (UE) 2022/2555, conocida como NIS2, enumera en su artículo 21 las medidas de gestión de riesgos de ciberseguridad que deben adoptar las entidades esenciales e importantes. La letra d) del apartado 2 dice: «la seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos».

El apartado 3 va más allá. Al elegir esas medidas, las entidades deben tener en cuenta las vulnerabilidades específicas de cada proveedor y prestador de servicios directo, y la calidad general de sus productos y de sus prácticas de ciberseguridad.

Su cliente no puede valorar sus prácticas de ciberseguridad sin preguntar. Así que traslada parte de la obligación hacia abajo en la cadena, mediante cuestionarios, cláusulas contractuales y peticiones de pruebas. Si usted suministra software, alojamiento o soporte informático, o tiene acceso a sus sistemas, espere una lista larga. Si vende algo que no tiene relación con eso, la lista puede ser más corta, pero puede llegar igualmente, porque para un equipo de compras es más sencillo enviar el mismo formulario a todos los proveedores.

Hay además un motivo muy corriente por el que su dominio importa. Usted es una de las direcciones desde las que su cliente recibe facturas. Si alguien puede enviar un correo que parezca suyo, puede enviar una factura falsa con otros datos bancarios. Para su cliente eso es un riesgo de la cadena de suministro, aunque usted nunca toque sus servidores.

Por qué ahora

Una directiva no obliga a las empresas por sí sola. Cada país de la UE la incorpora a su legislación nacional, con su propio calendario. Polonia, por ejemplo, lo hizo con una ley de 23 de enero de 2026 que modifica su Ley del Sistema Nacional de Ciberseguridad (Dz.U. 2026, posición 252), en vigor desde el 3 de abril de 2026. El artículo 8 modificado de esa ley incluye la seguridad y la continuidad de la cadena de suministro TIC entre las medidas que debe implantar una empresa sujeta.

El Ministerio de Asuntos Digitales de Polonia concede a las empresas que ya cumplían los criterios cuando la ley entró en vigor hasta el 3 de octubre de 2026 para registrarse y hasta el 3 de abril de 2027 para cumplir sus obligaciones. Otros países tienen sus propias fechas. Esté donde esté su cliente, el patrón es el mismo: a medida que se acerca su plazo, sus equipos de seguridad y de compras van repasando la lista de proveedores.

Preguntas que responden su sitio web y su correo

Una parte de cada cuestionario trata cosas que cualquiera puede comprobar desde fuera en unos minutos. Su cliente o su auditor pueden hacerlo sin preguntarle, así que es mejor que usted conozca las respuestas antes.

Cifrado en tránsito. Suele formularse como «¿Se cifran los datos en tránsito?» o «¿Qué versiones de TLS admite?». Una buena respuesta: el sitio funciona solo con HTTPS, http:// redirige a https://, el certificado es válido y las versiones antiguas del protocolo, TLS 1.0 y 1.1, están desactivadas. El comprobador gratuito de certificados SSL (en inglés) lo muestra todo.

Autenticación del correo. «¿Usa SPF, DKIM y DMARC?». Esta pregunta aparece a menudo, porque tiene que ver con que alguien suplante a su empresa. Una buena respuesta son los tres en su DNS, con DMARC en p=quarantine o p=reject. Un registro p=none solo observa y no detiene nada. Pase su dominio por la comprobación de SPF, DKIM y DMARC (en inglés), y si las siglas le resultan nuevas, este artículo las explica.

Parches. «¿Cómo gestiona las actualizaciones de seguridad?», «¿Con qué rapidez aplica los parches críticos?». Su sitio web revela más de lo que podría pensar. WordPress y sus plugins muestran a menudo sus números de versión en el código de la página, y un escáner puede cruzarlos con vulnerabilidades conocidas. Si su sitio usa un plugin con un fallo publicado, «aplicamos los parches con rapidez» no superará la primera comprobación.

Archivos expuestos. Las preguntas sobre protección de datos y copias de seguridad también tienen una vertiente externa. ¿Hay un backup.zip, un volcado de la base de datos o un archivo de configuración con contraseñas donde cualquiera puede descargarlo? Los bots prueban esas direcciones en cada sitio al que llegan. Más sobre esto en la copia de seguridad olvidada en su servidor.

Cabeceras de seguridad. Rara vez se mencionan por su nombre, pero están detrás de las preguntas sobre el bastionado de aplicaciones web. Que falte la cabecera HSTS o la Content Security Policy no significa que el sitio esté abierto de par en par. Sí muestra si alguien lo está cuidando. La comprobación de cabeceras de seguridad (en inglés) enumera lo que hay y lo que falta.

Notificación de vulnerabilidades. Algunos cuestionarios preguntan cómo puede alguien de fuera comunicarle un problema de seguridad. La respuesta más sencilla es una dirección de contacto de seguridad publicada en un archivo /.well-known/security.txt de su sitio.

Preguntas que su sitio web no puede responder

El resto es invisible desde fuera. Quién tiene acceso de administrador a su sitio web, a su correo y a su dominio, y si usa inicio de sesión en dos pasos. Dónde están sus copias de seguridad y si alguien ha restaurado alguna vez una. Qué hace usted tras un incidente y con qué rapidez avisa al cliente. Si su personal detectaría un correo de phishing.

Ningún escáner ayuda con esto. Ayudan respuestas breves y ciertas, con un documento que las respalde.

No marque «sí» en todo. Las respuestas del cuestionario acaban a menudo en el contrato como declaraciones, y una falsa es peor que un honesto «en curso, listo en diciembre». Su cliente necesita proveedores cuyo riesgo pueda gestionar. No espera proveedores sin ningún riesgo.

Preparar las pruebas

Antes de responder, prepare una carpeta, con la fecha en el nombre de cada archivo.

1. Un informe sobre su sitio web y su dominio. Muestra el estado del certificado, los registros de correo, las cabeceras y los archivos expuestos en un día concreto. Si hubo algo que corregir, añada un segundo informe después de la corrección. Una pareja de antes y después le dice al cliente más que un solo resultado.
2. Su resultado de SPF, DKIM y DMARC. Basta con una captura de pantalla con fecha.
3. Una página sobre actualizaciones. Quién actualiza el sitio web y sus demás sistemas, con qué frecuencia y con qué rapidez se aplican los parches críticos.
4. Una página sobre copias de seguridad. Dónde se guardan, con qué frecuencia se hacen y cuándo se restauró una por última vez.
5. Una lista de accesos. Quién tiene cuentas de administrador del sitio web, del correo, del registrador del dominio y del alojamiento, y si cada una de esas cuentas tiene inicio de sesión en dos pasos.
6. Un contacto para incidentes. Nombre, correo y teléfono de la persona responsable, y con qué rapidez avisará al cliente de un incidente que le afecte.

Redacte los puntos 3 a 6 junto con quien cuida su sitio web y su informática. Si no sabe cómo empezar esa conversación, las cinco preguntas del final de este artículo son un buen comienzo.

Repita la revisión del sitio web cada trimestre y después de cualquier cambio importante. Su cliente volverá con otro cuestionario, y un informe de hace dos años no demuestra nada.

Qué hacer esta semana

Si el cuestionario ya está sobre su mesa:

1. Revise su sitio web y su dominio desde fuera. Lleva minutos, y el resultado puede cambiar algunas de sus respuestas.
2. Corrija lo rápido: pase DMARC de p=none a quarantine, saque los archivos de copia de la carpeta web, fuerce HTTPS, desactive las versiones antiguas de TLS. Con SPF y DKIM ya funcionando, suele ser cuestión de horas, no de semanas.
3. Describa el resto con honestidad: qué funciona, qué está en curso y cuándo estará listo.

El primer paso puede darlo con ShieldWave. Escriba su dirección y en unos 90 segundos revisa desde fuera el certificado, las cabeceras, SPF, DKIM y DMARC, las versiones de software y los archivos expuestos, y después explica el resultado con lenguaje claro, con un encargo listo para su desarrollador. La primera revisión es gratuita, y un análisis completo puntual con el informe íntegro para su carpeta cuesta 9 $.