Todas las guías

Guía · 8 min de lectura

NIS2 Art. 21(2): lista de verificación de seguridad para proveedores

Un guion de trabajo para equipos de adquisición y seguridad: tanto para la incorporación de un nuevo proveedor como para la revisión anual. Para cada una de las seis cláusulas del artículo 21(2) de NIS2 relevantes para la cadena de suministro: qué preguntar, por qué importa, qué evidencia reclamar y cómo reaccionar cuando la respuesta se queda corta.

Puntos clave

  • Seis subcláusulas del artículo 21(2) cargan con la mayor parte del peso de la cadena de suministro. Esto es lo que preguntar en cada una y el documento que lo prueba.
  • La mitad son técnicas y cambian sin aviso, por lo que requieren comprobación continua y no una línea en un cuestionario anual.
  • Una brecha no es un veredicto. Una decisión de remediación documentada y asumida es lo que hace que su posición sea defendible ante un auditor.

El artículo 21(2)(d) convierte la evaluación de la seguridad de sus proveedores en parte de su propia gestión de riesgos, y no es un acto único. La obligación cubre tanto al proveedor que está a punto de firmar como a aquel con el que lleva años trabajando. Una revisión anual es el suelo, no el techo. Lo difícil es que el estándar («medidas adecuadas») escala con el riesgo y nunca se queda quieto, de modo que una evaluación limpia en primavera puede decirle muy poco en otoño.

Lo que sigue recorre las seis subcláusulas del artículo 21(2) que cargan con más peso para la cadena de suministro. Cada una se expone tal como es realmente útil en la sala: qué preguntar, por qué importa y qué documento reclamar como prueba. Úselo como guion para la conversación de incorporación y para la revisión anual por igual, y lea las cláusulas técnicas como cosas que verificar de forma continua, no una sola vez.

Una nota sobre el alcance. Esto es orientación, no un dictamen jurídico: su autoridad competente o su auditor pueden esperar más según su sector y tamaño, y la redacción contractual merece el ojo de un abogado. Los plazos mencionados (ventanas de parcheo y similares) son referencias razonables, no plazos legales de NIS2.

Las seis subcláusulas, en el orden en que conviene preguntarlas:

Art. 21(2)(a)Gestión de riesgos

Empiece por la diferencia entre un proveedor que gestiona el ciberriesgo como una disciplina permanente y otro que se apresura una vez al año. Un sistema de gestión de seguridad de la información documentado (ISO 27001 es el atajo limpio, aunque una política de SGSI escrita sirve) muestra que el proceso existe; la pregunta más reveladora es cuándo lo revisó por última vez la alta dirección o el consejo, y si los sistemas y datos críticos se han inventariado y clasificado de verdad. Pida la política o el certificado y anote la fecha de esa última revisión: un programa que nadie ha abierto en dos años lo es solo de nombre.

Art. 21(2)(b)Gestión de incidentes

Si este proveedor es lo bastante importante como para que su brecha pueda perturbar su servicio, su incidente pone en marcha su reloj de notificación del artículo 23, y solo lo cumple si le avisa rápido. La buena voluntad no carga con eso; el contrato debe hacerlo: una ventana definida para notificarle un incidente de seguridad, un contacto nombrado que responde las 24 horas y, detrás, un plan de respuesta probado en lugar de un documento que nadie ha ensayado. Pida el resumen del plan de respuesta a incidentes y convierta la notificación en 24 horas en una cláusula contractual escrita, no en una línea de un correo.

Art. 21(2)(d)Cadena de suministro

Su exposición va más allá del proveedor que firmó hasta aquellos de los que depende: el riesgo de cuarta parte. Un proveedor capaz sabe nombrar a los subcontratistas que tocan sus datos o sistemas, los somete a condiciones de seguridad escritas en sus propios contratos en lugar de un vago guiño a los «estándares del sector», y los reevalúa al menos cada año. Pregunte si puede aportar un registro de subcontratistas y describir cómo evalúa a esas partes; un proveedor que no sabe nombrar a sus cuartas partes críticas acaba de decirle algo que vale la pena saber.

Art. 21(2)(e)Adquisición y desarrollo

Las vulnerabilidades conocidas sin parchear y el software en fin de vida están entre las vías de entrada más usadas, así que el proveedor debe mostrar que la gestión de vulnerabilidades es real y no aspiracional. Referencias razonables: nada más allá del fin de soporte en producción, los fallos críticos (CVSS 9,0 y superior) parcheados en torno a un mes desde la divulgación, y todo lo que figure en el catálogo de vulnerabilidades explotadas conocidas de CISA tratado como una emergencia. Pida una descripción del proceso de parcheo y una instantánea reciente de vulnerabilidades: la distancia entre la política y el último análisis suele ser donde vive la verdad.

Art. 21(2)(h)Criptografía

Esta es la cláusula más visible desde fuera, y la que se desliza más en silencio. Los certificados TLS caducados o autofirmados, los sitios que no fuerzan HTTPS y la autenticación de correo dejada a medias son todos comunes, cambian sin aviso y son todos comprobables desde fuera. El listón es poco lucido: certificados válidos en todas partes, HTTPS forzado en cada sitio y API, y SPF, DKIM y DMARC realmente configurados (hardfail, firmado, al menos una política de cuarentena) en lugar de dejados en sus valores por defecto. Pida el proceso de gestión de certificados y una lectura DMARC o DNS.

Art. 21(2)(i)/(j)Control de acceso y autenticación

Las credenciales robadas siguen siendo la forma más común en que un atacante gana pie, así que un proveedor debe mostrar tanto que el uso indebido es difícil como que se detectaría pronto. En la práctica eso significa autenticación multifactor forzada en cada sistema crítico y cuenta de administrador sin excepciones silenciosas, supervisión de credenciales filtradas que aparecen en datos de brechas y de la dark web, y el hábito de rotar de inmediato cualquier acceso expuesto y dejar constancia del incidente. Pida ver la política de aplicación de la AMF y cómo se lleva la supervisión de fugas de credenciales.

Cuando un proveedor se queda corto

Una sola brecha rara vez es razón para marcharse; una autoridad supervisora (y su propio consejo) buscará la prueba de que la advirtió y tomó al respecto una decisión deliberada y asumida. Calibre la respuesta según cuánto falta, y dónde.

Una o dos brechas: documentar y aceptar

Regístrelas en su registro de proveedores, pida un plan de remediación en unos 90 días y haga un seguimiento en la próxima revisión. Un riesgo anotado y aceptado es una posición defendible; uno olvidado no lo es.

De tres a cinco brechas, o cualquier brecha en la gestión de incidentes: estreche la vigilancia

Eleve al proveedor a un nivel de riesgo superior, pida un plan de remediación escrito con fechas y considere limitar su acceso a sus sistemas más críticos hasta que las brechas se cierren.

Seis o más brechas, o una vulnerabilidad técnica crítica: escalar

Llévelo a su CISO o a la alta dirección, sopese los recursos contractuales que realmente tiene y (si el proveedor puede alcanzar datos o sistemas de producción) considere suspender ese acceso hasta que el panorama esté claro.

Vea cómo puntúan realmente sus proveedores

7 días gratuitos · sin tarjeta de crédito · cancele cuando quiera

Lo que no puede hacer a mano

Varias de estas comprobaciones son técnicas, y se degradan sin que nadie le envíe un aviso: un certificado caduca, una credencial aparece en una filtración, un proveedor acaba en una lista de víctimas de ransomware. Un cuestionario respondido una vez al año no ve nada de eso: que es precisamente la distancia entre una revisión de papel y la diligencia continua que espera el estándar de «medidas adecuadas».

norppa.io ejecuta la mitad técnica de esta lista cada día, para cada proveedor que añade:

  • Criptografía (h): validez de certificados TLS y forzado de HTTPS, configuración SPF/DKIM/DMARC, DNSSEC
  • Acceso y autenticación (i): credenciales de empleados y clientes que aparecen en datos de brechas y de la dark web
  • Adquisición y desarrollo (e): inscripciones en el catálogo de vulnerabilidades explotadas y hallazgos de vulnerabilidades puntuados por gravedad
  • Gestión de incidentes (b): apariciones en listas de víctimas de ransomware, con una alerta en el momento en que un proveedor aparece

Las subcláusulas de nivel de proceso (gestión de riesgos, gestión de incidentes y gobernanza de la cadena de suministro) son justo para lo que sirve el cuestionario de autoevaluación; puede enviarlo a un proveedor directamente desde el portal y leer sus respuestas junto a los hallazgos técnicos.

¿Aún no listo para empezar? Reciba el estado NIS2 de su país

Le enviaremos el estado de transposición NIS2 de su país (autoridad, ley nacional, fechas clave) y una checklist concisa de diligencia de proveedores. Un correo y, después, novedades NIS2 ocasionales.

Nunca compartimos su correo. Baja con un clic. Almacenado en la UE.

Automatice la mitad que no puede hacer a mano

norppa.io comprueba los elementos visibles desde fuera de esta lista cada día, para todos los proveedores a la vez, y asigna cada hallazgo a la subcláusula del artículo 21(2) a la que responde. El cuestionario de autoevaluación cubre el resto.

7 días gratuitos · sin tarjeta de crédito · cancele cuando quiera

Última revisión: 19 de junio de 2026

Esta guía es información general sobre el Derecho de la UE, no asesoramiento jurídico. NIS2 entra en vigor a través de la ley de transposición nacional de cada Estado miembro de la UE, que puede diferir en los detalles. Verifique las obligaciones que le aplican con su autoridad competente o asesor jurídico.

Guías relacionadas

Cómo cumplir NIS2: una hoja de ruta paso a paso

Los pasos hacia el cumplimiento de NIS2 en orden: confirmar el ámbito, registrarse, responsabilidad de la dirección (art. 20), las medidas del art. 21.2, seguridad de la cadena de suministro, notificación de incidentes (art. 23) y garantía continua y evidenciada.

¿Quién está sujeto a NIS2? Entidades esenciales e importantes, sectores y umbrales de tamaño

Determina si NIS2 te aplica: los dos niveles, los sectores de los anexos I/II, los umbrales de tamaño, las excepciones independientes del tamaño y cómo la cadena de suministro te involucra aunque no estés designado.

NIS2 para proveedores: usted no está designado, pero sus clientes sí

La mayoría de las empresas nunca son designadas conforme a NIS2, pero muchas deben cumplirla igualmente. Cómo el deber de cadena de suministro de un cliente afectado (artículo 21, apartado 2, letra d) desciende hasta usted, qué pedirá y cómo responder de forma creíble.

NIS2 y el requisito de la cadena de suministro: qué significa en la práctica

NIS2 obliga a las entidades esenciales e importantes a evaluar los ciberriesgos de su cadena de suministro. Clasificación de proveedores, riesgo de cuarta parte, notificación Art. 23 y lo que buscan los auditores.

Cómo ocurre una brecha en 2026: su superficie externa y su cadena de suministro

La cadena de ataque de 2026 paso a paso — credenciales robadas, dispositivos de borde explotados, suplantación de correo — en su propia superficie externa y la de sus proveedores, y dónde norppa.io rompe la cadena.

Evaluación del ciberriesgo del proveedor: qué comprueba el monitoreo NIS2 automatizado

Todas las categorías de comprobación explicadas: ransomware, filtraciones dark web, TLS/DNSSEC, seguridad de cookies, CVE/EPSS, sanciones, listas negras MX y SAQ. Ciclo de vida de hallazgos y mapeo de artículos NIS2.

Cuestionario de proveedores NIS2 (SAQ): qué preguntar, cómo puntuarlo y una plantilla gratuita

Qué preguntar a los proveedores bajo el art. 21.2.d, cómo puntuar respuestas y responder a brechas, por qué la autodeclaración necesita verificación, y una plantilla gratuita.

Notificación de incidentes NIS2: los plazos de 24 y 72 horas explicados

Qué es un incidente significativo, el calendario del artículo 23 (alerta a 24 h, notificación a 72 h, informe final a un mes) y cuándo el incidente de un proveedor se convierte en su obligación.

NIS2 y la responsabilidad de la dirección: lo que el consejo y la alta dirección deben saber

Qué espera NIS2 del órgano de dirección: deberes de aprobación y supervisión, responsabilidad personal (art. 20), formación, KPI de reporte al consejo y sanciones del art. 34.

ISO 27001 y NIS2: lo que su SGSI ya cubre, y las brechas que no

Si tiene ISO 27001: qué se traslada a NIS2 y qué no (notificación legal, responsabilidad de la dirección, registro y garantía continua de la cadena de suministro) y cómo cerrar la brecha.

Multas y sanciones NIS2: cuánto, quién es responsable y cómo evitarlas

Qué son las sanciones NIS2: los topes del artículo 34 (10 M€ / 2 % para entidades esenciales, 7 M€ / 1,4 % para importantes), la responsabilidad personal de la dirección (art. 20, art. 32), las medidas no pecuniarias y cómo evitarlas.

NIS2 vs DORA: en qué se diferencian, dónde se solapan y cuál te aplica

En qué se diferencian y solapan los dos regímenes de la UE, por qué DORA es lex specialis para entidades financieras, cuál te aplica, y qué significan ambos para el riesgo de terceros.

RGPD vs NIS2: solapamiento, diferencias y cuándo un incidente activa ambos

En qué se diferencian y solapan RGPD y NIS2, cuándo un incidente activa ambos (RGPD art. 33 72 h a la autoridad de control vs NIS2 art. 23 24 h/72 h/un mes al CSIRT), la cooperación del art. 35 y la prohibición de doble multa, y qué significan ambos para la diligencia de proveedores.

El Reglamento de Ciberresiliencia de la UE (CRA): ámbito, calendario y qué significa para su cadena de suministro

Qué exige el CRA, sus fechas escalonadas (en vigor 2024, notificación sept 2026, plena conformidad dic 2027), a quién se aplica y por qué el SaaS puro a menudo no, cómo complementa a NIS2 y qué significa para la contratación y la diligencia de proveedores.

El Reglamento de IA de la UE: niveles de riesgo, calendario y qué deben hacer los responsables del despliegue (artículo 26)

Qué exige el Reglamento de IA de la UE: los niveles de riesgo, las fechas escalonadas (en vigor 2024, prohibido feb 2025, GPAI ago 2025, alto riesgo ago 2026), las obligaciones del art. 26 del responsable del despliegue, cómo se suma a NIS2 y el RGPD, y qué significa para la adquisición de IA.

Estado de transposición de NIS2: en qué países de la UE está en vigor

Cuáles de los 27 Estados miembros de la UE han incorporado NIS2 a la ley nacional y cuáles aún la ultiman, y por qué las diferencias alcanzan su cadena de suministro igualmente.

Cláusulas contractuales para proveedores NIS2: qué exigir a sus proveedores

Las cláusulas que hacen exigible la obligación de cadena de suministro de NIS2: mínimo de seguridad, ventana de notificación, derechos de prueba y auditoría, traslación a subcontratistas y verificación continua.

Su postura de seguridad externa bajo NIS2: lo que ven proveedores y clientes

Las señales públicamente visibles que los clientes evalúan bajo el art. 21(2)(d) de NIS2: suplantación de correo (SPF/DMARC), higiene de certificados, sistemas expuestos a internet y credenciales filtradas, por qué importa cada una y cómo comprobarlas y corregirlas.

¿Sus proveedores usan IA? El riesgo de proveedores de NIS2 y el Reglamento de IA de la UE

Los proveedores integran cada vez más IA en los servicios de los que depende, y sus proveedores también. Dónde la IA de proveedores y de la enésima parte crea riesgo bajo el art. 21(2)(d) de NIS2 y el Reglamento de IA, qué evaluar y cómo mantener la visibilidad.

Suplantación de proveedor y fraude del CEO (BEC): suplantación de correo, DMARC y NIS2

Uno de los ataques a la cadena de suministro más comunes no necesita ninguna brecha: un correo suplantado que desvía un pago o roba datos. Cómo funcionan el BEC y la suplantación de proveedor, los ajustes SPF, DKIM y DMARC que los detienen, y cómo encaja en el art. 21(2)(d) de NIS2.