El ENS distingue dos obligaciones sobre tus proveedores TIC que no son lo mismo: el artículo 2.3 del Real Decreto 311/2022 extiende las cautelas de seguridad a la cadena de suministro «en la medida que sea necesario» según el análisis de riesgos, desde cualquier categoría; y la medida op.ext.3 del Anexo II, que literalmente se llama «Protección de la cadena de suministro», solo es obligatoria en categoría ALTA. Confundir ambas lleva a exigir de más o de menos.
El ENS exige dos cosas distintas sobre tus proveedores tecnológicos, y confundirlas lleva a conclusiones falsas en los dos sentidos. Por un lado, el artículo 2.3 del Real Decreto 311/2022 obliga a extender las cautelas de seguridad a la cadena de suministro "en la medida que sea necesario y de acuerdo con los resultados del correspondiente análisis de riesgos", desde cualquier categoría. Por otro, la medida del Anexo II que literalmente se llama «Protección de la cadena de suministro» (op.ext.3) solo es obligatoria en categoría ALTA. Traducir estas obligaciones legales en cláusulas de contrato es parte de nuestro servicio de implantación técnica del ENS.
Qué dice el ENS sobre la cadena de suministro de tus contratistas (art. 2.3)
El artículo 2.3 del Real Decreto 311/2022 exige que los pliegos de los contratos que celebren las entidades sujetas al ENS contemplen los requisitos necesarios para asegurar la conformidad de los sistemas en los que se sustentan los servicios contratados, y añade:
«Esta cautela se extenderá también a la cadena de suministro de dichos contratistas, en la medida que sea necesario y de acuerdo con los resultados del correspondiente análisis de riesgos.»
— Real Decreto 311/2022, art. 2.3 (BOE-A-2022-7191)
La clave está en "en la medida que sea necesario": la obligación es proporcional al riesgo, no automática por categoría. El análisis de riesgo que determina esto empieza por calcular bien la categoría de tu sistema, aunque, como se ve en el siguiente apartado, el artículo 2.3 puede exigir cautelas contractuales sobre proveedores incluso antes de que la medida formal del Anexo II esté activa.
La medida específica del Anexo II, op.ext.3: por qué solo es obligatoria en categoría ALTA
op.ext.3 forma parte del mismo Anexo II que ya desglosamos aquí. Verificado directamente en la tabla oficial: op.ext.3 es "no aplica" tanto en básica como en media, y solo se convierte en exigencia formal en categoría alta; el resto de la familia op.ext (contratación, gestión diaria e interconexión) sí se activa ya en media, tal y como detallamos en qué añade la categoría media sobre la básica. Esto no significa que la cadena de suministro "no importe" hasta alta: el art. 2.3 puede exigir cautelas contractuales desde antes si el análisis de riesgos lo justifica, sin necesidad de que op.ext.3 esté activa como medida formal.
Cuando op.ext.3 sí está activa (categoría alta), incluye tres refuerzos con cláusulas muy concretas: R1, plan de contingencia con dependencia de proveedores críticos; R2, protección de flujos B2B; y R3, un registro de componentes software, muy parecido a lo que hoy se conoce internacionalmente como SBOM (software bill of materials):
«[...] se mantendrá actualizado un registro formal que contenga los detalles y las relaciones de la cadena de suministro de los diversos componentes utilizados en la construcción de programas informáticos [...]. Esta lista será proporcionada por el proveedor de la aplicación, librería o producto suministrado.»
— Real Decreto 311/2022, Anexo II, refuerzo op.ext.3.R3 (BOE-A-2022-7191)
Por qué esto no es una sola casilla: cuatro obligaciones con cuatro bases legales distintas
Es habitual tratar "seguridad de proveedores" como si fuera un único requisito que se cumple con una cláusula genérica de confidencialidad. El Real Decreto 311/2022 distingue en realidad cuatro obligaciones separadas, con base legal propia cada una: la extensión proporcional al riesgo del artículo 2.3, la certificación de productos del artículo 19, la cualificación del personal del artículo 16, y la medida formal de continuidad ante fallo de proveedor crítico del Anexo II (op.ext.3). Cumplir una no cumple las demás: un proveedor puede tener personal perfectamente cualificado (art. 16) y no ofrecer, aun así, ningún producto con certificación de seguridad proporcional a tu categoría (art. 19), o viceversa.
Antes de la cadena de suministro: qué exigir a cualquier proveedor desde MEDIA (op.ext.1 y op.ext.2)
Antes de llegar a op.ext.3, dos medidas de la misma familia ya aplican desde categoría media a cualquier proveedor externo, no solo a los críticos: op.ext.1 exige un Acuerdo de Nivel de Servicio (SLA) formal previo al uso del recurso, y op.ext.2 exige un sistema rutinario de medición de ese SLA y procedimientos de coordinación de mantenimiento. op.ext.3 solo aplica en alta; para el resto de medidas por categoría, consulta el desglose completo de básica y su continuación en media.
Si tu proveedor es de infraestructura cloud, además de estas cláusulas generales aplica lo que exige la medida específica op.nub.1: lo tratamos en esta guía sobre ENS en la nube. El modelo de servicio de tu proveedor (SaaS, PaaS o IaaS) ya lo explicamos aquí, y condiciona qué cláusula le corresponde exactamente.
Productos y servicios de seguridad certificados: qué exige el artículo 19 del RD 311/2022
El artículo 19 exige que los productos y servicios de seguridad adquiridos cuenten con funcionalidad de seguridad certificada, de forma proporcional a la categoría del sistema, y remite al CCN la determinación de requisitos funcionales y certificaciones adicionales. Es la base legal de por qué no cualquier producto "de seguridad" vale igual para cualquier categoría: cuanto más alta es la categoría, más exigente es el nivel de certificación que se puede requerir.
Personal cualificado del proveedor: qué exige el artículo 16 (profesionalidad)
El artículo 16 exige personal cualificado, dedicado e instruido en todo el ciclo de vida del sistema, y obliga expresamente a exigir, de manera objetiva y no discriminatoria, que las organizaciones que presten servicios de seguridad cuenten con profesionales cualificados. Es una obligación distinta de la certificación de productos del artículo 19: aquí lo que se certifica es la capacitación de las personas que prestan el servicio, no el producto.
El punto de contacto de seguridad obligatorio en servicios externalizados (art. 13.5) y por qué no te libera de responsabilidad
El artículo 13.5 obliga a que el proveedor de un servicio externalizado designe un punto de contacto de seguridad, pero es explícito en que eso no traslada la responsabilidad: "sin perjuicio de que la responsabilidad última resida en la entidad del sector público destinataria de los citados servicios". Exigir evidencia de pruebas de seguridad al proveedor conecta con pentesting y red teaming, que explicamos en detalle en esa guía: un punto de contacto sin evidencia técnica detrás es una casilla marcada, no una garantía real.
Las tres cláusulas concretas de op.ext.3 que pueden ir en un contrato
Para sistemas de categoría alta, o para cualquier organización que quiera anticiparse por análisis de riesgo, las tres cláusulas de op.ext.3 se traducen así en un contrato: (1) un plan de contingencia documentado ante el fallo de un proveedor crítico, con alternativas identificadas; (2) protección específica de los flujos de intercambio de información B2B con ese proveedor, no solo del acceso general; y (3) la obligación contractual de que el proveedor entregue y mantenga actualizado un registro de los componentes software (librerías, dependencias) que forman parte de lo que suministra. Estas cláusulas conviven con las que exige el cumplimiento GDPR/RGPD cuando el proveedor trata datos personales: son obligaciones paralelas, no sustitutivas una de otra.
Un caso frecuente: el proveedor que se resiste a firmar estas cláusulas
En la práctica, no todos los proveedores TIC —sobre todo los más pequeños o los que no trabajan habitualmente con el sector público— están familiarizados con estas exigencias, y algunos se resisten a firmar un SLA formal o a comprometerse a mantener un registro de componentes software. Aquí conviene separar dos situaciones: si el proveedor no puede ofrecer la evidencia porque su servicio no lo permite (por ejemplo, un componente cerrado sin visibilidad de sus dependencias internas), es una señal de riesgo real que debería pesar en la decisión de contratación. Si el proveedor simplemente no lo ha hecho nunca porque nadie se lo había pedido antes, la negociación suele resolverse explicando qué exige exactamente la norma y por qué la exigencia no es arbitraria de tu organización, sino una obligación que tú mismo tienes que trasladar hacia abajo en la cadena.
Checklist: qué pedir a un proveedor TIC según tu categoría
- Cualquier categoría (art. 2.3): cautelas proporcionales al riesgo si el análisis lo justifica, aunque la medida formal no esté activa todavía.
- Desde media (op.ext.1, op.ext.2): SLA formal por escrito y procedimiento de medición y coordinación de mantenimiento.
- Cualquier categoría (art. 19, art. 16): productos con certificación de seguridad proporcional a la categoría y personal del proveedor cualificado.
- Solo en alta (op.ext.3): plan de contingencia ante proveedor crítico, protección de flujos B2B y registro de componentes software.
Si el coste de auditar a tus proveedores es una barrera, existen ayudas de ciberseguridad para pymes que pueden cubrir parte de ese trabajo; conviene verificar la convocatoria vigente antes de darlo por hecho en una propuesta a un cliente.
Preguntas frecuentes
¿Tengo que exigir cláusulas de cadena de suministro si mi sistema es categoría básica?
La medida formal op.ext.3 no te obliga en básica: solo es exigible en alta. Pero el artículo 2.3 del Real Decreto puede exigirte cautelas contractuales proporcionales al riesgo desde cualquier categoría, si tu propio análisis de riesgos lo justifica. Son dos capas distintas, no una sola casilla.
¿Qué es la "lista de componentes software" que pide el ENS y a qué se parece?
Es el refuerzo R3 de op.ext.3: un registro actualizado de los componentes (librerías, dependencias) usados en la construcción de un programa informático, que debe proporcionar el propio proveedor. Es funcionalmente equivalente a lo que hoy se conoce internacionalmente como SBOM (software bill of materials), aunque el Anexo II no usa ese término.
¿El artículo 2.3 aplica también a proveedores de entidades privadas, o solo del sector público?
El artículo 2.3 se redacta en el marco de los pliegos de contratos de entidades del sector público. Las empresas privadas que actúan como proveedoras de esas entidades quedan alcanzadas por la relación contractual, no como sujeto directo del artículo, pero en la práctica es el mecanismo por el que la exigencia se traslada hacia abajo en la cadena.
Este contenido tiene carácter divulgativo y orientativo. No constituye asesoramiento legal ni sustituye el análisis de un profesional cualificado para tu caso concreto.