Este es el primero de dos artículos dedicados al concepto de proporcionalidad en la norma ETSI EN 319 401 v3.2.1, publicada en enero de 2026. En esta primera entrega analizamos cómo la norma articula la proporcionalidad considerando el análisis de riesgos como motor operativo. En la segunda parte abordaremos el contexto regulatorio: eIDAS2, la familia ETSI 319 y la comparativa con NIS2, RGPD e ISO 27001.
Hay una tensión estructural en los servicios de confianza que rara vez se aborda con la profundidad que merece. Una firma electrónica cualificada emitida por una empresa de dos personas tiene el mismo valor jurídico que la emitida por un proveedor multinacional. Así lo establece el Reglamento eIDAS, y así debe ser para que el sistema funcione. Pero exigir arquitecturas de seguridad idénticas a ambos haría inaccesible el mercado a los prestadores más pequeños sin que eso mejorase la confianza de forma significativa. El concepto de proporcionalidad existe precisamente para resolver esta tensión: permitir que las medidas de seguridad se escalen en función del riesgo real, sin que esa flexibilidad se convierta en una vía para rebajar la protección.
La versión de enero de 2026 de la norma ETSI EN 319 401 introduce el marco de proporcionalidad más estructurado en la historia de la regulación europea de servicios de confianza. Su nueva cláusula 4.2 y el mecanismo de etiquetado [PRO] transforman la proporcionalidad de un principio implícito -encajado de forma difusa en el lenguaje de análisis de riesgos de versiones anteriores- en un sistema explícito, documentado y auditable con el que todo prestador de servicios de confianza (TSP) debe interactuar directamente.
Cómo articula la norma la proporcionalidad
La norma articula la proporcionalidad a través de varios mecanismos complementarios, algunos nuevos y otros heredados de versiones anteriores del estándar.
En la capa superior se sitúa la cláusula 4.2, que declara que todos los requisitos de la norma están sujetos a los criterios de proporcionalidad establecidos en dicha cláusula. Esta declaración general significa que ningún requisito existe de forma aislada respecto al contexto específico del TSP.
El REQ-4.2-01 obliga a los TSP a tener en cuenta factores como el tamaño y alcance de la organización, la naturaleza y grado del riesgo que plantean sus servicios de confianza, el tipo de servicio prestado y la criticidad de esos servicios. Se trata de un requisito con carácter de obligación (shall), no de orientación opcional. Todo TSP debe ponderar estos factores al implementar cualquier requisito de la norma.
A continuación, la norma introduce la etiqueta [PRO], un marcador formal aplicado a requisitos específicos que son explícitamente susceptibles de implementación proporcionada. El REQ-4.2-02 establece que los requisitos marcados con [PRO] deben implementarse sobre la base de los criterios de proporcionalidad. Entre los requisitos etiquetados se encuentran el PRO-7.1.1-04, sobre roles de seguridad dedicados (que permite, según el tamaño del TSP, que la seguridad de redes y sistemas de información sea cubierta por roles dedicados o por funciones asumidas adicionalmente a roles existentes), y el PRO-7.2-10, sobre diferenciación en descripciones de puestos (que permite, cuando sea apropiado, distinguir entre funciones generales y funciones específicas del TSP). La norma proporciona ejemplos concretos: un micro-TSP puede implementar controles compensatorios como una supervisión reforzada por parte de la dirección cuando la segregación completa de funciones resulta inviable, y un TSP que preste servicios de menor criticidad puede aplicar intervalos menos frecuentes de pruebas de seguridad.
Por último, la norma mantiene y refuerza la proporcionalidad implícita a través del lenguaje de análisis de riesgos: el enfoque heredado de la v2.3.1. Decenas de requisitos a lo largo de la cláusula 7 utilizan expresiones como «según sea apropiado para los servicios ofrecidos y el puesto» (REQ-7.2-01, sobre personal), «basado en el análisis de riesgos» (REQ-7.8-02, sobre segmentación de red), «dependiendo de la clasificación de los sistemas a los que se accede» (REQ-7.4.1-06, sobre autenticación) o «cuya seguridad sea crítica» (REQ-7.6-01, sobre acceso físico). Estas expresiones vinculan la intensidad de la implementación a los resultados del análisis de riesgos propio del TSP.
Las salvaguardas: proporcionalidad no es discrecionalidad
Lo que impide que este sistema se convierta en una vía de escape es un conjunto de cuatro requisitos de gobernanza que conviene conocer bien.
El REQ-4.2-03 exige a los TSP documentar su análisis de proporcionalidad como parte de la documentación de análisis de riesgos. El REQ-4.2-04 obliga a mantener esa documentación actualizada y disponible para revisión en auditoría. El REQ-4.2-05 establece que los requisitos [PRO] no pueden descartarse sin justificación adecuada, independientemente del tamaño o alcance del TSP. Y, de forma especialmente relevante, el REQ-4.2-06 exige que el efecto acumulativo de los requisitos [PRO] no aplicados no comprometa la postura de seguridad global de los servicios ni socave los objetivos de la norma.
Esta última salvaguarda -la de efecto acumulativo- es una decisión de diseño particularmente sofisticada. Impide que un TSP adopte múltiples decisiones de proporcionalidad individualmente defendibles que, sumadas, vacíen su seguridad. Dicho de otro modo: se puede justificar razonablemente no aplicar un requisito [PRO] concreto, pero no se pueden acumular excepciones hasta el punto de que el resultado final contradiga el propósito de la norma.
El análisis de riesgos como motor de la proporcionalidad
La cláusula 5 de la EN 319 401 v3.2.1 es el motor que alimenta la proporcionalidad en la práctica. El marco de análisis de riesgos determina qué cuenta como «proporcionado» para cada TSP, estableciendo la base fáctica sobre la que se calibran todas las medidas de seguridad.
El REQ-5-02 contiene la declaración de proporcionalidad más directa de la norma: el plan de tratamiento de riesgos debe asegurar que el nivel de seguridad sea proporcionado al grado de riesgo. Este lenguaje refleja casi literalmente el artículo 19.1 de eIDAS y crea la cadena vinculante entre la legislación y los requisitos operativos. El análisis de riesgos en sí debe seguir un enfoque integral (all-hazards approach) bajo el REQ-5-06, cubriendo amenazas, probabilidad, impacto y nivel de riesgo, y teniendo en cuenta la inteligencia de ciberamenazas y las vulnerabilidades. Los TSP deben identificar el riesgo en relación con terceros y evaluar las posibles disrupciones a la disponibilidad, integridad, autenticidad y confidencialidad en todo el entorno físico.
La v3.2.1 introduce en este ámbito varios elementos ausentes en las versiones anteriores. El concepto de apetito de riesgo aparece ahora de forma explícita, definido como la cantidad y tipo de riesgo que un TSP está dispuesto a aceptar en la consecución de sus objetivos de negocio. Un proceso obligatorio de gestión de riesgos de ciberseguridad debe integrarse en la gestión de riesgos global del TSP. Los órganos de dirección deben aprobar formalmente el marco de análisis de riesgos, incluido el plan de análisis y las medidas de gestión de riesgos de ciberseguridad (REQ-5-05). Y los análisis de riesgos deben revisarse al menos anualmente y actualizarse cuando se produzcan cambios significativos (REQ-5-04).
La cadena práctica funciona así: el análisis de riesgos del TSP identifica su panorama de amenazas específico, la criticidad de sus activos y las características de sus servicios. El plan de tratamiento de riesgos selecciona entonces controles cuya intensidad se corresponde con los niveles de riesgo identificados. Para los requisitos etiquetados con [PRO], el TSP documenta si procede la implementación completa o si se justifican alternativas proporcionadas. Toda esta cadena debe estar documentada, mantenida y disponible para el escrutinio del auditor. El resultado es que dos TSP que presten el mismo tipo de servicio pueden legítimamente implementar intensidades de control diferentes, siempre que sus análisis de riesgos reflejen perfiles de riesgo genuinamente distintos y su documentación demuestre un razonamiento sólido.
La proporcionalidad permea además dominios operativos específicos a lo largo de toda la norma. En seguridad del personal, el REQ-7.2-21 exige una verificación de antecedentes «en proporción a los requisitos de negocio, la clasificación de activos y los sistemas de redes e información a los que se accederá». En gestión de activos, el REQ-7.3.2-02 vincula los niveles de protección a los requisitos de confidencialidad, integridad, autenticidad y disponibilidad, indicando la protección requerida según su sensibilidad, criticidad, riesgo y requisitos de negocio. En continuidad de negocio, el REQ-7.11.2-01 exige copias de respaldo de acuerdo con el análisis de riesgos y el plan de continuidad de negocio. Incluso la retención de registros bajo el REQ-7.10-07 aplica proporcionalidad: los registros se conservan durante un período de tiempo «según sea apropiado».
La norma ha pasado de asumir que la proporcionalidad se infiere del lenguaje de riesgos a convertirla en un sistema articulado con niveles, etiquetas y salvaguardas. Pero este mecanismo no opera en el vacío: responde a un mandato legislativo concreto del Reglamento eIDAS2, se despliega de forma coordinada a través de toda la familia de normas ETSI 319, y presenta paralelos y diferencias relevantes con los enfoques de proporcionalidad de NIS2, el RGPD y la ISO 27001. Todo eso es lo que abordaremos en la segunda entrega de esta serie.
