Contratos de proveedores NIS2 con evidencias ISO 27001

Son las 07:40 de un lunes. El director de seguridad de la información (CISO) de una plataforma logística habilitada en la nube abre un correo electrónico de un proveedor de detección y respuesta gestionadas (MDR). El mensaje es breve, prudente e incómodo: el proveedor ha detectado un acceso sospechoso a un entorno de soporte utilizado por varios clientes. Los detalles son limitados. El proveedor promete una actualización “tan pronto como sea posible”.

A las 08:15, el responsable de cumplimiento pregunta si esto podría activar una notificación NIS2. A las 08:40, Compras está buscando el contrato. A las 09:10, el secretario del consejo solicita una sesión informativa sobre la responsabilidad del órgano de dirección. A las 10:00, Asesoría Jurídica pregunta si el contrato incluye notificación en 24 horas, derechos de auditoría, controles sobre subcontratistas, acceso a evidencias, obligaciones de continuidad del negocio, devolución de datos y disposiciones de supresión.

Nadie quiere descubrir durante un incidente en curso que el acuerdo con un proveedor crítico solo dice “medidas de seguridad razonables”.

Aquí es donde las cláusulas contractuales de proveedores NIS2 dejan de ser texto jurídico estándar y pasan a ser controles operativos. Para las entidades esenciales e importantes, la gobernanza de proveedores ya forma parte de la responsabilidad del consejo, las evidencias de supervisión, la preparación ante incidentes, el aseguramiento frente a clientes, el cumplimiento en privacidad y la planificación de la resiliencia. Un contrato firmado no basta. La organización debe demostrar que los riesgos de proveedores se identifican, aprueban, tratan, supervisan y evidencian.

El enfoque de Clarysec parte de un principio sencillo: si una cláusula de proveedor no puede supervisarse, evidenciarse y probarse, no es un control.

El Zenith Blueprint: hoja de ruta de 30 pasos para auditores sitúa las relaciones con proveedores en la fase de Controles en Acción, paso 23, donde los acuerdos, la supervisión, la incorporación, la reevaluación y las evidencias de auditoría se traducen en trabajo práctico del SGSI. La Zenith Controls: guía de cumplimiento cruzado mapea después los controles de proveedores de ISO/IEC 27002:2022 con NIS2, DORA, GDPR, NIST, COBIT 2019, normas ISO de apoyo y metodologías de auditoría.

El resultado es un modelo de gobernanza de proveedores que pueden utilizar Compras, Asesoría Jurídica, Seguridad, Privacidad y el consejo.

Por qué NIS2 convierte los contratos de proveedores en registros de evidencias

El artículo 20 de NIS2 exige que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y sean responsables de los incumplimientos. El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la adquisición y el mantenimiento seguros, la evaluación de la eficacia, la higiene cibernética, la criptografía, la seguridad de los recursos humanos, el control de acceso, la gestión de activos y la autenticación multifactor cuando proceda.

El artículo 21(3) explicita la diligencia debida de proveedores. Las organizaciones deben considerar las vulnerabilidades específicas de los proveedores directos y de los proveedores de servicios, la calidad general de los productos y las prácticas de ciberseguridad, así como los procedimientos de desarrollo seguro.

Ese lenguaje crea una obligación práctica: las relaciones con proveedores deben estar basadas en riesgos, ser exigibles contractualmente y estar sujetas a revisión. Un cuestionario de proveedor almacenado en una carpeta no basta. Un contrato genérico sin plazo de notificación de incidentes, sin derechos de acceso a evidencias y sin visibilidad sobre subcontratistas no basta. Una certificación de proveedor que nadie revisó no basta.

ISO/IEC 27001:2022 proporciona el modelo operativo. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda el contexto, las partes interesadas, las obligaciones legales y contractuales, el alcance del SGSI y las dependencias. Las cláusulas 5.1 a 5.3 exigen liderazgo, política, roles y comunicación. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos y Declaración de Aplicabilidad. Las cláusulas 8.1 a 8.3 exigen control operacional, repetición de evaluaciones de riesgos y resultados documentados.

Para la gobernanza de proveedores, los controles más importantes del Anexo A de ISO/IEC 27002:2022 incluyen:

• A.5.19 Seguridad de la información en las relaciones con proveedores
• A.5.20 Tratamiento de la seguridad de la información en los acuerdos con proveedores
• A.5.21 Gestión de la seguridad de la información en la cadena de suministro de las TIC
• A.5.22 Supervisión, revisión y gestión de cambios de los servicios de proveedores
• A.5.24 Planificación y preparación de la gestión de incidentes
• A.5.25 Evaluación y decisión sobre eventos de seguridad de la información
• A.5.26 Respuesta a incidentes de seguridad de la información
• A.5.27 Aprendizaje a partir de incidentes de seguridad de la información
• A.5.28 Recopilación de evidencias
• A.5.29 Seguridad de la información durante interrupciones
• A.5.30 Preparación de las TIC para la continuidad del negocio
• A.5.31 Requisitos legales, estatutarios, regulatorios y contractuales
• A.5.34 Privacidad y protección de PII
• A.8.8 Gestión de vulnerabilidades técnicas
• A.8.13 Copias de seguridad de la información
• A.8.15 Registro de eventos
• A.8.16 Actividades de supervisión
• A.8.24 Uso de criptografía
• A.8.32 Gestión de cambios

La clave es la propiedad. Una cláusula tiene poco valor si nadie es propietario del riesgo, nadie revisa las evidencias, nadie supervisa las excepciones y nadie escala los incumplimientos.

La política para grandes organizaciones Política de seguridad de terceros y proveedores lo hace explícito:

“Derechos de auditoría, inspección y solicitud de evidencias de seguridad”

De la sección “Requisitos de gobernanza”, cláusula de política 5.3.4.

Para pymes, la Política de seguridad de terceros y proveedores para pymes establece la misma expectativa práctica:

“Derechos de auditoría o disponibilidad de evidencias de cumplimiento”

De la sección “Requisitos de gobernanza”, cláusula de política 5.3.4.

Esta distinción importa. Una organización más pequeña puede no estar en condiciones de auditar in situ a todos los grandes proveedores de servicios en la nube, pero sí puede exigir acceso a evidencias de aseguramiento, como el alcance de certificación ISO/IEC 27001:2022, informes SOC, resúmenes de pruebas de penetración, atestaciones de remediación de vulnerabilidades, resúmenes de incidentes, informes de pruebas de continuidad del negocio y confirmaciones de supresión de datos.

La columna vertebral de tres controles del aseguramiento de proveedores NIS2

En el modelo de cumplimiento cruzado de Clarysec, tres controles de ISO/IEC 27002:2022 forman la columna vertebral de la gobernanza de proveedores NIS2: 5.19, 5.20 y 5.22.

A.5.19 identifica el riesgo del proveedor

El control A.5.19, Seguridad de la información en las relaciones con proveedores, es la base. Exige que las organizaciones protejan la información y los activos a los que acceden los proveedores, o que estos procesan, almacenan o gestionan.

Zenith Controls lo categoriza como un control preventivo que cubre confidencialidad, integridad y disponibilidad, con el concepto de ciberseguridad “Identificar” y la capacidad operativa “Seguridad de las relaciones con proveedores”. Conecta A.5.19 con A.5.20, A.5.21, A.5.14, A.5.36 y A.5.10. En términos prácticos, la organización identifica el riesgo del proveedor, define expectativas de seguridad, controla la exposición de la cadena de suministro de las TIC, protege la transferencia de información, supervisa el cumplimiento y extiende las obligaciones de uso aceptable a partes externas.

Para NIS2, esto se mapea directamente con la seguridad de la cadena de suministro del artículo 21(2)(d) y la diligencia debida de proveedores del artículo 21(3). Para GDPR, respalda el requisito de utilizar encargados del tratamiento que ofrezcan garantías suficientes. Para DORA, respalda la gestión del riesgo de terceros de TIC, la diligencia debida precontractual, la revisión de criticidad, el riesgo de concentración y la supervisión del ciclo de vida.

A.5.20 hace exigible el requisito

El control A.5.20, Tratamiento de la seguridad de la información en los acuerdos con proveedores, convierte las expectativas de seguridad en obligaciones contractuales. Zenith Controls explica con claridad la relación entre A.5.19 y A.5.20:

“5.20 actúa como la formalización contractual de las necesidades y riesgos de seguridad identificados en 5.19. Mientras que 5.19 implica evaluar riesgos de terceros y definir expectativas de seguridad, 5.20 garantiza que esas expectativas sean jurídicamente vinculantes mediante contratos o acuerdos de nivel de servicio (SLA). Sin 5.20, las medidas de seguridad identificadas en 5.19 carecerían de exigibilidad.”

Aquí es donde las decisiones de riesgo NIS2 se convierten en cláusulas: notificación de brechas de seguridad, derechos de auditoría y de acceso a evidencias, cifrado, control de acceso, gestión de vulnerabilidades, aprobación de subcontratistas, transferencia segura, continuidad, cooperación regulatoria, soporte de salida y supresión de datos.

A.5.22 demuestra que el contrato está vivo

El control A.5.22, Supervisión, revisión y gestión de cambios de los servicios de proveedores, evita que el aseguramiento de proveedores se convierta en un ejercicio puntual de incorporación. Zenith Controls vincula A.5.22 con A.5.19 y A.5.20, pero también con A.5.29, seguridad de la información durante interrupciones; A.8.8, gestión de vulnerabilidades técnicas; A.5.36, cumplimiento de políticas, reglas y normas de seguridad de la información; A.5.15, control de acceso; y A.8.27, arquitectura segura de sistemas y principios de ingeniería.

Esto importa porque los servicios de proveedores cambian. Cambian las ubicaciones de los datos. Cambian los subencargados del tratamiento. Aparecen vulnerabilidades. Caducan las certificaciones. Surgen patrones de incidentes. Un proveedor aceptable el año pasado puede ser demasiado arriesgado hoy.

Qué deben incluir las cláusulas contractuales de proveedores NIS2

El Zenith Blueprint, fase de Controles en Acción, paso 23, ofrece un conjunto práctico de áreas para acuerdos con proveedores:

“Las áreas clave que suelen abordarse en los acuerdos con proveedores incluyen:

✓ Obligaciones de confidencialidad, incluido alcance, duración y restricciones de comunicación a terceros; ✓ Responsabilidades de control de acceso, como quién puede acceder a sus datos, cómo se gestionan las credenciales y qué supervisión existe; ✓ Medidas técnicas y organizativas para protección de datos, cifrado, transmisión segura, copias de seguridad y compromisos de disponibilidad; ✓ Plazos y protocolos de notificación de incidentes, a menudo con plazos definidos (por ejemplo, “notificar en un plazo de 24 horas”); ✓ Derecho de auditoría, incluida frecuencia, alcance y acceso a evidencias relevantes (por ejemplo, informes de pruebas de penetración, SoA, certificaciones); ✓ Controles sobre subcontratistas, que exigen al proveedor trasladar obligaciones de seguridad equivalentes a sus socios posteriores; ✓ Disposiciones de fin de contrato, como devolución o destrucción de datos, recuperación de activos y desactivación de cuentas.”

De la fase de Controles en Acción, paso 23: controles organizativos.

Una cláusula sólida de proveedor NIS2 es suficientemente específica para poder probarse. “El proveedor mantendrá una seguridad adecuada” es débil. “El proveedor notificará al contacto de seguridad del cliente en un plazo de 24 horas los incidentes confirmados o sospechados que afecten a sistemas del cliente, datos del cliente, disponibilidad del servicio u obligaciones de notificación regulatoria” es auditable.

Las cláusulas de incidentes deben ajustarse al cómputo de plazos de notificación NIS2

El artículo 23 de NIS2 establece un modelo escalonado de notificación para incidentes significativos: una alerta temprana en un plazo de 24 horas desde el momento en que se tiene conocimiento, una notificación de incidente en un plazo de 72 horas, informes intermedios cuando se soliciten y un informe final en el plazo de un mes desde la notificación del incidente. Un incidente significativo es aquel que ha causado o puede causar una interrupción operativa grave, pérdidas financieras o daños materiales o inmateriales considerables a terceros.

Los contratos de proveedores deben respaldar ese calendario. Si un proveedor de servicios gestionados crítico tarda cuatro días en confirmar si los entornos de clientes se vieron afectados, el cliente puede incumplir su propia ventana regulatoria.

La política para grandes organizaciones Política de seguridad de terceros y proveedores exige:

“Plazos de notificación de brechas de seguridad (por ejemplo, en 24 o 72 horas, según criticidad y requisitos regulatorios)”

De la sección “Requisitos de gobernanza”, cláusula de política 5.3.3.

La política para pymes Política de seguridad de terceros y proveedores para pymes también exige plazos definidos de notificación de brechas de seguridad en la sección “Requisitos de gobernanza”, cláusula de política 5.3.3.

Para incidentes de PII, la política para grandes organizaciones Política de gestión de incidentes y brechas de PII conecta la notificación de ciberseguridad, sector financiero, clientes y destinatarios del servicio:

“[Condicional] El responsable de privacidad / responsable del PIMS DEBE coordinar cualquier notificación de incidente sectorial, de ciberseguridad, del sector financiero, a clientes o a destinatarios del servicio cuando un incidente de datos personales de alto impacto cumpla un umbral de notificación aplicable, y DEBE registrar la autoridad, destinatario, plazo, presentación y evidencias de acuse de recibo en REG01 y REG10.”

De la sección “Notificación y comunicaciones”, cláusula de política 4.4.6.

Esto es evidencia NIS2 madura: no solo un correo electrónico de notificación, sino un registro de la autoridad, destinatario, plazo, presentación, acuse de recibo, impacto, análisis de causa raíz y acciones de seguimiento.

Alineación con privacidad y DORA sin duplicar programas de proveedores

Muchos proveedores NIS2 también tratan datos personales. El artículo 28 del GDPR exige que los responsables del tratamiento utilicen encargados del tratamiento que ofrezcan garantías suficientes y que definan las obligaciones del encargado en un contrato escrito. El artículo 5 del GDPR exige responsabilidad proactiva respecto del tratamiento lícito y seguro. Las obligaciones del GDPR en materia de brechas de seguridad también exigen cooperación rápida cuando los incidentes de proveedores afectan a datos personales.

La política para grandes organizaciones Política de gestión de privacidad de encargados, subencargados y terceros establece el punto de control de aprobación:

“[Ambos] El responsable de proveedores / Compras DEBE garantizar que los contratos de encargados y subencargados del tratamiento incluyan asistencia en privacidad, aseguramiento de seguridad, interfaz de incidentes a través de PII15, devolución o supresión a través de PII10, vinculación de transferencias a través de PII13 y cooperación en auditoría o aseguramiento antes de la aprobación.”

De la sección “Controles contractuales e instrucciones documentadas”, cláusula de política 4.3.6.

También exige la revisión de evidencias antes de la aprobación:

“[Todos] El responsable de seguridad de la información DEBE revisar las evidencias de aseguramiento de seguridad para cada relación con encargado, subencargado o tercero con acceso a PII o alojamiento de PII antes de la aprobación, y DEBE registrar el resultado en REG08 o REG12.”

De la sección “Diligencia debida y evaluación de riesgos”, cláusula de política 4.2.2.

DORA añade otra capa cuando el proveedor presta servicio a una entidad financiera. Los artículos 28 a 30 de DORA exigen gobernanza de terceros de TIC, registros de contratos de servicios de TIC, diligencia debida basada en riesgos, evaluación de criticidad, análisis del riesgo de concentración, derechos de auditoría e inspección, derechos de terminación, estrategias de salida y disposiciones contractuales obligatorias. El artículo 30 es especialmente relevante porque exige contenido contractual sobre descripciones de servicios, ubicaciones, protección de datos, acceso y recuperación, niveles de servicio, asistencia ante incidentes, cooperación con autoridades, derechos de auditoría, subcontratación, medidas de contingencia y soporte de transición.

La respuesta práctica no son tres programas de proveedores separados para NIS2, GDPR y DORA. Es un único modelo armonizado de evidencias de proveedores, mapeado entre marcos.

NIST CSF 2.0 es útil porque su función GOVERN exige comprender dependencias, obligaciones legales, obligaciones contractuales, apetito de riesgo, políticas, responsabilidad y supervisión. Su categoría de cadena de suministro GV.SC cubre roles de proveedores, criticidad, requisitos contractuales, diligencia debida, supervisión, inclusión en incidentes, supervisión del ciclo de vida y disposiciones de fin de relación.

Un flujo de trabajo de Clarysec para incorporar un proveedor crítico

Suponga que está incorporando un proveedor de servicios de seguridad gestionados que supervisará telemetría de endpoints, recibirá alertas que contienen identificadores de usuario y apoyará el triaje de incidentes para una organización incluida en el alcance de NIS2.

Paso 1: clasificar el proveedor

Registre el proveedor en el registro de proveedores con la descripción del servicio, sistemas y datos a los que accede, participación de PII, soporte a servicios esenciales o importantes, acceso privilegiado, países de prestación del servicio, subcontratistas, dependencias de cuartas partes, clasificación de criticidad, propietario del riesgo, responsable de Compras y revisor de seguridad de la información.

Esto implanta las cláusulas 4.2, 4.3, 6.1.2 y 8.1 de ISO/IEC 27001:2022 al conectar requisitos de partes interesadas, dependencias, propiedad del riesgo y control operacional.

Paso 2: mapear el riesgo con la SoA

En el Zenith Blueprint, fase de Gestión de riesgos, paso 13, Clarysec recomienda establecer referencias cruzadas con regulaciones en el Registro de Riesgos o en la Declaración de Aplicabilidad (SoA):

“Establezca referencias cruzadas con regulaciones: si determinados controles se implantan específicamente para cumplir con GDPR, NIS2 o DORA, puede indicarlo en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.”

De la fase de Gestión de riesgos, paso 13: planificación del tratamiento de riesgos y Declaración de Aplicabilidad.

Para el MSSP, incluya al menos A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 a A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 y A.8.24.

Paso 3: exigir cláusulas aplicables

Utilice un anexo de seguridad de proveedores que exija notificación inicial de incidentes en 24 horas, actualización detallada en 72 horas, informe final de incidentes, MFA para acceso privilegiado, cuentas de usuario nominativas, controles sobre subcontratistas, transferencia segura, cifrado, evidencias de aseguramiento, cooperación regulatoria, evidencias de BCP y DR, soporte de salida, devolución o supresión de datos y revocación de acceso.

La política para grandes organizaciones Política de gestión del riesgo de dependencia de proveedores proporciona el requisito de continuidad:

“Cuando proceda, un requisito para que el proveedor mantenga sus propios Planes de Continuidad del Negocio (BCP/DRP) y planes de gestión de incidentes, los pruebe y nos proporcione resúmenes o informes de prueba previa solicitud.”

De la sección “Requisitos de implantación”, cláusula de política 6.8.4.

Paso 4: construir el paquete de evidencias de aseguramiento

Antes de la aprobación, solicite el acuerdo firmado, acuerdos de nivel de servicio (SLA), anexo de seguridad, alcance de certificación ISO/IEC 27001:2022 o aseguramiento equivalente, informe SOC cuando esté disponible, resumen ejecutivo de pruebas de penetración, resumen de gestión de vulnerabilidades, resumen del procedimiento de respuesta a incidentes, resumen de pruebas de BCP o DR, atestación de control de acceso y MFA, lista de subcontratistas, procedimiento de supresión de datos y salida, y DPA cuando se trate PII.

La política para pymes Política de seguridad de terceros y proveedores para pymes hace medibles las evidencias contractuales básicas:

“Acuerdos y SLA firmados”

De la sección “Aplicación y cumplimiento”, cláusula de política 8.3.2.1.

También identifica evidencias recurrentes de proveedores:

“Certificaciones de seguridad válidas o evidencias de control actualizadas”

De la sección “Requisitos de implantación de la política”, cláusula de política 6.3.1.2.

Para una diligencia debida de proveedores más amplia, la Política de auditoría y supervisión del cumplimiento establece:

“La diligencia debida de proveedores incluirá la revisión de certificaciones (por ejemplo, ISO 27001, SOC 2), cuestionarios de seguridad y registros de incidentes.”

Paso 5: supervisar en función de la criticidad

La política para grandes organizaciones Política de gestión de privacidad de encargados, subencargados y terceros exige supervisión trimestral para relaciones de PII de alto riesgo:

“[Todos] El responsable de proveedores / Compras DEBE supervisar trimestralmente las relaciones activas de alto riesgo con encargados y subencargados del tratamiento, y anualmente las demás relaciones activas con encargados y subencargados de PII, frente a condiciones de diligencia debida, estado contractual, estado de aseguramiento, incidencias abiertas y fechas de revisión en REG08.”

De la sección “Supervisión continua, asistencia, interfaz de comunicación y salida”, cláusula de política 4.5.1.

Así es como A.5.22 se convierte en realidad. La revisión debe determinar si el proveedor permanece dentro del apetito de riesgo, si las evidencias están vigentes, si existen incidencias abiertas, si se produjeron incidentes y si los cambios del servicio requieren reevaluación.

Cómo probarán los auditores las cláusulas de proveedores NIS2

Los auditores rara vez empiezan leyendo la política de forma aislada. Seleccionan una muestra de proveedores y siguen la trazabilidad de evidencias.

Un auditor ISO/IEC 27001:2022 solicitará el inventario de proveedores, clasificación de riesgos, criterios de proveedores, registros de diligencia debida, contratos, evidencias, mapeo con la Declaración de Aplicabilidad (SoA) e historial de supervisión. Para el Anexo A 5.20, el auditor inspeccionará si los contratos muestreados contienen cláusulas exigibles. Para el Anexo A 5.22, el auditor comprobará si los informes se revisaron, las excepciones se registraron y las acciones tuvieron seguimiento.

Una autoridad competente NIS2 puede centrarse en si las prácticas de ciberseguridad de proveedores y los procedimientos de desarrollo seguro fueron evaluados conforme al artículo 21(3). Un revisor orientado a DORA puede solicitar entradas del registro de contratos de TIC, estrategias de salida, análisis de riesgo de concentración y disposiciones obligatorias del artículo 30. Un auditor de privacidad puede probar contratos de encargados del tratamiento, traslado contractual a subencargados, interfaces de brechas de seguridad y evidencias de garantías suficientes.

La política para grandes organizaciones Política de seguridad y control de acceso de PII muestra cómo el control de acceso, las vulnerabilidades, la configuración, la supervisión y la criptografía se vinculan de nuevo con ISO/IEC 27001:2022:

“ISO/IEC 27001:2022 — Cláusula 6.1.3; Cláusula 8.1; controles del Anexo A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Cubierto por las cláusulas [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

De la sección “Normas y marcos de referencia”, cláusula de política 13.9.

Cuando un proveedor tiene acceso a PII, sistemas privilegiados o datos de supervisión, las evidencias de control de acceso no están separadas del aseguramiento de proveedores. Forman parte de la misma pista de auditoría.

La trampa de Compras: contratos firmados sin operación de aseguramiento

El fallo más común de la gobernanza de proveedores NIS2 no es la ausencia de contratos. Es la brecha entre el lenguaje contractual y la operación diaria.

Un contrato puede exigir resúmenes anuales de pruebas de penetración, pero ningún responsable los solicita. Puede exigir notificación de incidentes en 24 horas, pero el proveedor solo dispone de una dirección genérica de soporte. Puede exigir aprobación de subcontratistas, pero Compras nunca recibe notificaciones de cambios. Puede incluir derechos de auditoría, pero la organización no tiene un proceso para evaluar excepciones en informes SOC. Puede exigir supresión de datos a la salida, pero TI nunca valida la desactivación de cuentas.

El Zenith Blueprint, fase de Controles en Acción, paso 23, explica cómo los controles de proveedores cobran vida:

“En la práctica, este control cobra vida mediante:

✓ Evaluaciones de riesgos de proveedores, ✓ Cuestionarios de diligencia debida previos a la contratación, ✓ Plantillas contractuales con términos de seguridad incorporados, ✓ Listas de verificación de incorporación de proveedores que incluyen aprovisionamiento de accesos y configuración de la supervisión, ✓ Reevaluaciones continuas, especialmente cuando cambia el alcance del proveedor, se producen incidentes o vencen renovaciones.

Y este control no se detiene en los proveedores de primer nivel. Su proveedor puede externalizar a sus propios proveedores, y usted puede seguir soportando el riesgo.”

Ese es el mensaje NIS2 para el consejo: externalizar la prestación del servicio no externaliza la responsabilidad.

Lista de verificación de remediación de contratos de proveedores NIS2

Empiece por sus 20 principales proveedores por criticidad y ejecute un ejercicio focalizado de remediación:

• Identifique los proveedores que dan soporte a servicios esenciales o importantes.
• Confirme si cada proveedor trata PII, da soporte a servicios regulados o tiene acceso privilegiado.
• Asigne un propietario de negocio, un responsable de compras y un revisor de seguridad.
• Verifique que la evaluación de riesgos del proveedor esté vigente y alineada con el alcance real del servicio.
• Confirme que el contrato incluya configuración base de seguridad, notificación de incidentes, derechos de auditoría o evidencias, controles sobre subcontratistas, continuidad, transferencia segura, control de acceso, cooperación en vulnerabilidades y cláusulas de salida.
• Confirme que los plazos de brecha de seguridad respalden necesidades de escalado de 24 y 72 horas cuando sea relevante.
• Solicite evidencias de aseguramiento actualizadas, incluidas certificaciones, informes SOC, resúmenes de pruebas de penetración, pruebas de BCP o DR e historial de incidentes.
• Revise las evidencias; no se limite a almacenarlas.
• Registre excepciones y asigne responsables de remediación.
• Actualice la SoA y el Registro de Riesgos cuando los controles de proveedores respalden NIS2, GDPR, DORA o compromisos con clientes.
• Programe la frecuencia de supervisión según la criticidad del proveedor.
• Pruebe una ruta de escalado de incidentes de proveedor.
• Pruebe una ruta de terminación de proveedor, incluida la devolución de datos, supresión, recuperación de activos y revocación de acceso.

Si no puede demostrar estos puntos para un proveedor crítico, el contrato aún no está preparado para auditoría.

Convierta las cláusulas de proveedores en evidencias de supervisión

La gobernanza de proveedores NIS2 es ya una disciplina operativa viva. Las autoridades de supervisión, clientes, auditores de certificación, equipos de privacidad, socios del sector financiero y consejos no solo preguntarán si existen cláusulas de proveedores. Preguntarán si las cláusulas están basadas en riesgos, son exigibles, se supervisan, se evidencian y están conectadas con notificación de incidentes, continuidad, control de acceso, gestión de vulnerabilidades, traslado contractual a subcontratistas y salida.

Clarysec ayuda a las organizaciones a cerrar esa brecha con el Zenith Blueprint, que convierte controles de proveedores en fases del SGSI, tratamiento de riesgos, entradas de la Declaración de Aplicabilidad (SoA), rutinas de incorporación y evidencias de auditoría. Zenith Controls mapea los controles de proveedores ISO/IEC 27002:2022 A.5.19, A.5.20 y A.5.22 con NIS2, DORA, GDPR, NIST, COBIT 2019, normas ISO de apoyo y metodologías de auditoría. Las políticas de proveedores y privacidad de Clarysec proporcionan la estructura de cláusulas, expectativas de evidencias y rutinas de supervisión que hacen defendible el aseguramiento de proveedores.

Su siguiente acción es sencilla: seleccione cinco proveedores críticos, muestree sus contratos, mapee cada cláusula con el tratamiento de riesgos ISO/IEC 27001:2022 y los controles del Anexo A, solicite evidencias de aseguramiento actualizadas y ejecute un ejercicio de mesa de notificación de incidentes en 24 horas. Si la trazabilidad de evidencias se rompe, los toolkits de Clarysec le proporcionan la estructura para repararla antes de que lo haga un incidente, una revisión de cliente o un requerimiento de supervisión.