Tema 8: Accesibilidad, usabilidad y seguridad en el desarrollo

Accesibilidad web y diseño universal

La accesibilidad universal es la condición que deben cumplir los entornos, procesos, bienes, productos y servicios para ser comprensibles, utilizables y practicables por todas las personas en condiciones de seguridad y comodidad, de la forma más autónoma y natural posible. Aplicada a las tecnologías de la información, persigue que cualquier persona —incluidas las que tienen discapacidad o las de edad avanzada— pueda percibir, entender, navegar e interactuar con la web. La aplicación de la accesibilidad universal en el ámbito de las telecomunicaciones y la sociedad de la información está regulada por ley (en España, el Texto Refundido de la Ley General de derechos de las personas con discapacidad —RDL 1/2013— y su desarrollo reglamentario).

El W3C y la Web Accessibility Initiative (WAI)

El World Wide Web Consortium (W3C) es el organismo internacional que estandariza la Web. Dentro de él, la WAI (Web Accessibility Initiative) es la iniciativa encargada de la accesibilidad web. La WAI ha publicado tres grandes conjuntos de pautas complementarias:

• WCAG (Web Content Accessibility Guidelines): pautas de accesibilidad para el contenido web. Son unas pautas de accesibilidad de contenidos web promovidas por el W3C.

• ATAG (Authoring Tool Accessibility Guidelines): conjunto de normas que deben cumplir las herramientas de autor para ser accesibles y para generar, a su vez, contenidos accesibles.

• UAAG (User Agent Accessibility Guidelines): pautas que utilizan los desarrolladores en el diseño de agentes de usuario (navegadores, reproductores) para que la web sea más accesible para las personas con discapacidad.

WCAG: estructura y niveles de conformidad

Las WCAG organizan sus recomendaciones en una jerarquía que va de lo más general a lo más particular: Principios → Pautas → Criterios de conformidad → Técnicas (suficientes y recomendables/opcionales). Es decir, dentro de cada principio están las pautas, y dentro de cada pauta los criterios de conformidad (no al revés: afirmar que «dentro de cada pauta se encuentran los principios» es falso).

Existen tres niveles de conformidad: A, AA y AAA. Los criterios de nivel A son los de mayor importancia y prioridad para la accesibilidad final (los imprescindibles); el nivel AA exige cumplir todos los criterios de los niveles anteriores (A) más los propios de AA; y el nivel AAA es el más exigente. Ejemplos de criterios de nivel AAA en WCAG 2.0 son Contraste (mejorado) y Pronunciación.

Las WCAG no solo son aplicables a las tecnologías del W3C: pueden aplicarse a cualquier tecnología web. Además, permiten utilizar tecnologías «no accesibles» siempre y cuando el contenido no dependa de ellas para transmitir la información (principio de no dependencia).

Los cuatro principios (POUR) y las 13 pautas de WCAG 2.1

WCAG 2.1 se apoya en cuatro principios —Perceptible, Operable, Comprensible y Robusto (acrónimo POUR)— desglosados en 13 pautas. WCAG 2.1 amplía a 2.0 con una pauta nueva y 17 criterios de conformidad adicionales, pero no añade un nuevo nivel de conformidad (siguen siendo A, AA y AAA).

Puntos clave que suelen confundirse:

• Perceptible significa mostrar la información en formas que los usuarios puedan percibir. La pauta Distinguible (1.4) pertenece a este principio: su objetivo es facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo. La pauta Ataques epilépticos (no diseñar contenido que pueda causar ataques epilépticos) NO es de Perceptible: es de Operable (2.3).

• Operable: los componentes y la navegación deben poder manejarse. Incluye No diseñar contenido que pueda causar ataques epilépticos (2.3) y Modalidades de entrada (2.5), que facilita operar la funcionalidad mediante varios métodos además del teclado. La pauta Contenido multimedia dependiente del tiempo NO es de Operable: es de Perceptible (1.2).

• Comprensible: la información y el manejo deben entenderse. Contiene Legible, Previsible y Entrada de datos asistida (pauta 3.3). No son de Comprensible ni Distinguible (es Perceptible) ni Compatible (es Robusto: maximiza la compatibilidad con los agentes de usuario actuales y futuros, incluidas las tecnologías de asistencia).

• Un ejemplo de criterio propio de WCAG 2.1 es advertir a los usuarios de que la duración de cualquier periodo de inactividad puede causar la pérdida de datos (criterio Tiempos de espera, 2.2.6, AAA). El criterio Orientación (1.3.4) también es nuevo de 2.1 y, por tanto, no existe en WCAG 2.0.

• El criterio de que las páginas no contengan nada que destelle más de tres veces por segundo (2.3.1, Tres destellos o por debajo del umbral) sí es de nivel A.

Hacer la apariencia y el uso de las páginas imprevisibles contradice el principio Comprensible (la pauta Previsible busca justo lo contrario), por lo que es una afirmación falsa.

Web semántica

La web semántica dota de significado a los datos para que las máquinas los procesen. Sus estándares, promovidos por el W3C, son RDF, RDFS, OWL y SPARQL (el lenguaje de consulta es SPARQL, no «SPARK»). El RDF (Resource Description Framework) es el elemento que describe de forma sencilla y estructurada los recursos e información de la web.

Lectores de pantalla: NVDA

NVDA (NonVisual Desktop Access) es un lector de pantalla gratuito y de código abierto para el sistema operativo Microsoft Windows, que permite a las personas ciegas o con discapacidad visual (visión reducida o sin visión) utilizar el ordenador mediante voz sintetizada y braille.

RD 1112/2018: accesibilidad del sector público

El Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público (transposición de la Directiva UE 2016/2102), es la norma de referencia. Su artículo 3 define que el contenido accesible incluye la información textual y no textual, los documentos y formularios descargables, los contenidos multimedia pregrabados de base temporal, las formas de interacción bidireccional y la cumplimentación de los procesos de identificación, autenticación, firma y pago.

Otras reglas relevantes del RD:

• Solicitudes de información accesible y quejas: recibidas estas, la entidad obligada deberá responder a la persona interesada en el plazo de veinte días hábiles.

• Primera revisión de accesibilidad: debe realizarse antes de dos años desde la entrada en vigor en el caso de los sitios web, y antes de tres años en el de las aplicaciones móviles (por tanto, decir «antes de dos años» para las apps móviles es incorrecto).

Fuentes

• W3C – Web Accessibility Initiative (WAI): https://www.w3.org/WAI/standards-guidelines/wcag/es

• W3C – Web Content Accessibility Guidelines (WCAG) 2.1: https://www.w3.org/TR/WCAG21/

• BOE – Real Decreto 1112/2018, de 7 de septiembre: https://www.boe.es/buscar/act.php?id=BOE-A-2018-12699

• Universidad de Alicante – Accesibilidad Web (principios y pautas WCAG 2.1): https://accesibilidadweb.dlsi.ua.es/?menu=principios-2.1

• W3C – Semantic Web (RDF, RDFS, OWL, SPARQL): https://www.w3.org/standards/semanticweb/

• NV Access – NVDA screen reader: https://www.nvaccess.org/about-nvda/

Usabilidad: concepto y marco normativo

La usabilidad es, según la definición canónica de la norma ISO 9241-11:2018 (Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts), el grado en que un sistema, producto o servicio puede ser utilizado por usuarios específicos para alcanzar objetivos específicos con eficacia, eficiencia y satisfacción en un contexto de uso específico.

La idea central de la norma es que la usabilidad no es una propiedad intrínseca del producto, sino un resultado de la interacción entre el usuario, la tarea y el entorno. Por eso siempre se mide relativa a un contexto concreto: un mismo sistema puede ser muy usable para un colectivo de usuarios y muy poco usable para otro.

Las tres dimensiones (métricas) de la usabilidad

ISO 9241-11 descompone la usabilidad en tres componentes medibles:

El contexto de uso

Para evaluar la usabilidad la norma exige describir el contexto de uso, formado por cuatro elementos:

• Usuarios (características, experiencia, capacidades).

• Tareas (objetivos que se persiguen).

• Equipos (hardware, software y materiales).

• Entorno (físico, social y organizativo).

Medir la usabilidad requiere, por tanto: una descripción de los objetivos previstos, una descripción de los componentes del contexto de uso, y unos valores objetivo de eficacia, eficiencia y satisfacción.

Usabilidad, accesibilidad y diseño universal

La usabilidad se distingue de la accesibilidad (que persigue que las personas con el mayor rango de capacidades puedan usar el producto) y del diseño universal o diseño para todos (concebir productos utilizables por todas las personas sin necesidad de adaptación). No obstante, están íntimamente relacionadas: un producto accesible tiende a ser más usable, y la accesibilidad se considera un requisito de usabilidad para colectivos con diversidad funcional. En el marco español, la accesibilidad de los sitios web y aplicaciones del sector público se rige por el RD 1112/2018 (que transpone la Directiva UE 2016/2102 y remite a la norma UNE-EN 301549 y a las pautas WCAG del W3C).

Diseño centrado en el usuario (ISO 9241-210)

La norma ISO 9241-210 (Human-centred design for interactive systems) establece el Diseño Centrado en el Usuario / en las Personas (DCU / Human-Centred Design, HCD): un enfoque que hace los sistemas usables y útiles centrándose en los usuarios, sus necesidades y requisitos, aplicando conocimientos de factores humanos, ergonomía y usabilidad.

ISO 9241-210 fija seis principios del diseño centrado en las personas. Los cuatro nucleares son:

1. El diseño se basa en una comprensión explícita de los usuarios, las tareas y los entornos.

2. Los usuarios están implicados a lo largo de todo el diseño y desarrollo.

3. El diseño se guía y refina mediante evaluación centrada en el usuario.

4. El proceso es iterativo.

A ellos se añaden que el diseño aborda la experiencia de usuario completa y que el equipo de diseño incluye perspectivas y competencias multidisciplinares. El ciclo iterativo típico comprende: entender y especificar el contexto de uso → especificar los requisitos de usuario → producir soluciones de diseño (prototipos) → evaluar los diseños frente a los requisitos.

Modelo de calidad del producto software (ISO/IEC 25010)

Dentro de la familia SQuaRE, la norma ISO/IEC 25010 define un modelo de calidad del producto software con ocho características, una de las cuales es la usabilidad (usability). Sus subcaracterísticas son:

• Idoneidad reconocible (appropriateness recognizability): grado en que el usuario puede reconocer si el producto es adecuado para sus necesidades a partir de las primeras impresiones o la documentación asociada.

• Capacidad de aprendizaje (learnability): facilidad con que se aprende a usar el producto en un tiempo determinado.

• Operabilidad (operability): atributos que hacen el producto fácil de operar y controlar.

• Protección frente a errores del usuario (user error protection): grado en que el sistema protege a los usuarios de cometer errores.

• Estética de la interfaz de usuario (user interface aesthetics).

• Accesibilidad (accessibility).

Heurísticas de usabilidad de Nielsen

En el ámbito de la evaluación de interfaces, las 10 heurísticas de usabilidad de Jakob Nielsen (publicadas en 1994) son el conjunto de principios generales más utilizado para la evaluación heurística:

1. Visibilidad del estado del sistema — informar siempre al usuario de lo que ocurre.

2. Correspondencia entre el sistema y el mundo real — usar el lenguaje y conceptos del usuario.

3. Control y libertad del usuario — salidas claras, deshacer/rehacer.

4. Consistencia y estándares — seguir convenciones establecidas.

5. Prevención de errores — mejor evitar el error que gestionar el mensaje de error.

6. Reconocer antes que recordar — hacer visibles objetos, acciones y opciones para minimizar la carga de memoria.

7. Flexibilidad y eficiencia de uso — atajos para usuarios expertos.

8. Diseño estético y minimalista — sin información irrelevante.

9. Ayudar a reconocer, diagnosticar y recuperarse de los errores — mensajes de error claros y constructivos.

10. Ayuda y documentación.

Métodos de evaluación

La usabilidad se evalúa con métodos de inspección (evaluación heurística de Nielsen, recorrido cognitivo o cognitive walkthrough) y con métodos de test con usuarios (test de usabilidad, eye-tracking, card sorting, cuestionarios como el SUS – System Usability Scale). La evaluación de inspección la realizan expertos sin usuarios; el test de usabilidad observa a usuarios reales ejecutando tareas.

Fuentes

• ISO 9241-11:2018 — Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts. https://www.iso.org/obp/ui/#iso:std:iso:9241:-11:ed-2:v1:en

• ISO 9241-210:2019 — Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/77520.html

• ISO/IEC 25010:2011 — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models. https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en

• Nielsen, J. — 10 Usability Heuristics for User Interface Design (1994). Nielsen Norman Group. https://www.nngroup.com/articles/ten-usability-heuristics/

• Real Decreto 1112/2018, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público (BOE). https://www.boe.es/eli/es/rd/2018/09/07/1112

• W3C — Web Content Accessibility Guidelines (WCAG). https://www.w3.org/WAI/standards-guidelines/wcag/

Seguridad en el desarrollo de sistemas

La seguridad en el desarrollo consiste en integrar controles y buenas prácticas de seguridad a lo largo de todo el ciclo de vida del software (SDLC), y no como una capa que se añade al final. Este enfoque se conoce como Secure SDLC o seguridad por diseño (Security by Design): la seguridad se considera un requisito desde el análisis, se plasma en el diseño (modelado de amenazas), se aplica en la codificación (codificación segura), se comprueba en la fase de pruebas (SAST/DAST) y se mantiene en la explotación (gestión de vulnerabilidades y parcheo). El principio rector es que corregir un defecto de seguridad es más barato cuanto antes se detecta.

Principios de diseño seguro

Las normalizadoras (OWASP, NIST) coinciden en un conjunto de principios que deben guiar el diseño y la codificación:

• Mínimo privilegio (Least Privilege): cada usuario, proceso o componente dispone solo de los permisos estrictamente necesarios para su función, reduciendo el impacto de una brecha.

• Defensa en profundidad (Defense in Depth): se disponen múltiples capas de control, de modo que si una falla, otras siguen protegiendo la información (diseñar como si el cortafuegos ya estuviera comprometido).

• Denegación por defecto (Deny by Default / Secure by Default): salvo los recursos públicos, todo acceso se deniega si no se concede explícitamente; el sistema arranca en un estado seguro.

• Fallo seguro (Fail Securely): ante un error, el sistema no debe quedar en un estado que exponga datos ni conceda accesos indebidos.

• Validación en servidor: los controles de acceso y la validación de entradas solo son fiables en código de servidor de confianza, nunca delegados al cliente, que el atacante puede manipular.

• Superficie de ataque mínima y separación de privilegios.

OWASP Top 10 (2021)

El OWASP Top 10 es el documento de referencia sobre los riesgos de seguridad más críticos en aplicaciones web. En su versión 2021 las categorías, por orden, son:

A01 – Broken Access Control ascendió al primer puesto en 2021 (era el quinto en 2017): es la categoría con más incidencias. Incluye la elusión de comprobaciones modificando la URL o el estado interno, las referencias directas inseguras a objetos (IDOR), la falta de control en métodos POST/PUT/DELETE de una API y la manipulación de metadatos como tokens JWT o cookies. Su mitigación exige aplicar el control en servidor, denegar por defecto y reutilizar un único mecanismo de control de acceso. La categoría A04 – Diseño inseguro fue de nueva creación en 2021 y refuerza precisamente la idea de seguridad por diseño y el modelado de amenazas.

Codificación segura frente a las amenazas típicas

La fase de codificación debe neutralizar los defectos recogidos en enumeraciones como CWE:

• Inyección (A03): usar consultas parametrizadas / prepared statements frente a SQL Injection; escapar y codificar la salida frente a XSS; validar todas las entradas con listas de permitidos (allowlist).

• Criptografía (A02): cifrar los datos sensibles en tránsito (TLS) y en reposo, con algoritmos vigentes y sin claves ni secretos incrustados en el código.

• Autenticación (A07): gestión robusta de contraseñas, protección frente a fuerza bruta y sesiones seguras.

• Componentes (A06): mantener actualizadas las dependencias de terceros (análisis de composición de software, SCA).

Verificación: pruebas de seguridad

El SDLC seguro incorpora herramientas y actividades de verificación:

• SAST (Static Application Security Testing): análisis estático del código fuente sin ejecutarlo, para detectar patrones vulnerables.

• DAST (Dynamic Application Security Testing): análisis dinámico de la aplicación en ejecución, incluido el fuzz testing.

• Revisiones de código (manuales y automatizadas) y pentesting.

• Integración de estas comprobaciones en la cadena DevSecOps / CI-CD.

Marcos y normas de referencia

• NIST SP 800-218 – SSDF (Secure Software Development Framework), versión 1.1: organiza las prácticas en cuatro grupos: PO Prepare the Organization (preparar la organización: roles, formación, SDLC documentado), PS Protect the Software (proteger la integridad del código y los artefactos, firma de código), PW Produce Well-Secured Software (producir software bien asegurado: codificación segura, revisiones, análisis estático y dinámico) y RV Respond to Vulnerabilities (responder a las vulnerabilidades detectadas tras la entrega).

• ISO/IEC 27034: seguridad de las aplicaciones a lo largo de su ciclo de vida.

• ISO/IEC 27001 / 27002: controles de seguridad de la información, con dominios aplicables al desarrollo (adquisición, desarrollo y mantenimiento de sistemas).

• Esquema Nacional de Seguridad (ENS), RD 311/2022: en España exige aplicar seguridad en el ciclo de vida de los sistemas del sector público, incluyendo el desarrollo y la gestión de cambios.

• Métrica v3 contempla actividades de interfaz de seguridad en el desarrollo de sistemas de información.

Relación con la confidencialidad y disponibilidad en el puesto de usuario

Un desarrollo seguro contribuye directamente a las dimensiones clásicas de la seguridad —confidencialidad, integridad y disponibilidad— también en el puesto de usuario final: validar entradas y controlar accesos protege la confidencialidad de los datos; el registro y la monitorización (A09) permiten detectar incidentes; y una gestión adecuada de errores y de componentes evita caídas que comprometan la disponibilidad. La seguridad no termina con la entrega del software: la gestión continua de vulnerabilidades (parches, avisos, respuesta ante incidentes) es parte inseparable del desarrollo seguro.

Fuentes

• OWASP Top 10:2021 — https://owasp.org/Top10/2021/

• OWASP Top 10:2021 A01 Broken Access Control — https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/

• OWASP Developer Guide, Principles of security — https://devguide.owasp.org/en/02-foundations/03-security-principles/

• OWASP Secure Product Design Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secure_Product_Design_Cheat_Sheet.html

• NIST SP 800-218, Secure Software Development Framework (SSDF) v1.1 — https://csrc.nist.gov/pubs/sp/800/218/final

• BOE, Real Decreto 311/2022 (Esquema Nacional de Seguridad) — https://www.boe.es/eli/es/rd/2022/05/03/311

Confidencialidad y disponibilidad en el puesto de usuario final

El puesto de usuario final (ordenador de sobremesa, portátil corporativo, teléfono o tableta desde el que un empleado accede a los sistemas) es uno de los eslabones más expuestos de la cadena de seguridad. Proteger la información que se maneja en él exige combinar medidas técnicas, organizativas y de concienciación que garanticen los pilares clásicos de la seguridad de la información.

Los tres principios básicos: la tríada CIA

La seguridad en el acceso a la información se sustenta en tres principios básicos, conocidos como la tríada CIA por sus siglas en inglés (Confidentiality, Integrity, Availability):

• Confidencialidad

• Integridad

• Disponibilidad

Estos tres son los tres pilares fundamentales. En marcos como la norma ISO/IEC 27001 se manejan precisamente estas tres propiedades, mientras que el Esquema Nacional de Seguridad (RD 311/2022) amplía el modelo a cinco dimensiones, añadiendo la autenticidad y la trazabilidad. Cuando la pregunta se refiere a los tres principios básicos, la respuesta correcta es siempre Confidencialidad, Integridad y Disponibilidad.

Confidencialidad

La confidencialidad garantiza que la información solo sea accesible para las personas, entidades o procesos autorizados, protegiéndola frente a accesos, divulgación o revelación no autorizados. Es importante entender que la confidencialidad no garantiza por sí misma que los datos no se alteren (eso es integridad) ni que estén siempre accesibles (eso es disponibilidad): se limita a controlar quién puede ver la información. Por eso, en preguntas que ofrecen definiciones parciales o cruzadas de este principio, la opción correcta puede llegar a ser "Ninguna es correcta", cuando ninguna de las descripciones propuestas recoge con precisión que la confidencialidad es la protección del acceso no autorizado.

Integridad

La integridad es la dimensión de la tríada CIA que determina que los datos deben mantenerse libres de modificaciones o alteraciones por terceros. Garantizar la integridad de los datos significa evitar modificaciones o alteraciones en la información por terceros no autorizados, asegurando que la información permanece exacta y completa a lo largo de su ciclo de vida. Se apoya en mecanismos como funciones hash, sumas de verificación (checksums), firmas digitales y controles de acceso de escritura.

Disponibilidad

La disponibilidad garantiza que la información y los servicios estén accesibles y utilizables por los usuarios autorizados cuando los necesiten. En el puesto de usuario se protege con copias de seguridad, alimentación redundante, antimalware, actualizaciones y medidas frente a la denegación de servicio o la pérdida de datos.

Firma electrónica múltiple: cofirma y contrafirma

Cuando un documento debe ser firmado por varios firmantes hablamos de firma múltiple, que admite dos modalidades:

Por tanto, cuando en una aplicación de firma electrónica intervienen múltiples usuarios (solicitantes y responsables) y el orden es relevante porque cada firma refrenda o certifica la del firmante anterior, se está describiendo una contrafirma.

Buenas prácticas en la gestión de la información en el puesto de trabajo

La protección de la confidencialidad y la disponibilidad depende en gran medida del comportamiento del usuario. Son buenas prácticas, entre otras:

• Bloquear la sesión al ausentarse y aplicar la política de mesa limpia (clean desk).

• Emplear contraseñas robustas y no compartir credenciales.

• Cifrar la información sensible y los dispositivos portátiles.

• Realizar copias de seguridad y clasificar la información según su criticidad.

• Trasladar y difundir la normativa de utilización de internet y correo corporativo a TODOS los empleados, no únicamente a la dirección.

En consecuencia, NO es una buena práctica trasladar la normativa de utilización de internet y correo corporativo solo al director de la empresa: la política de uso aceptable debe conocerla toda la plantilla, ya que cualquier usuario puede comprometer la seguridad.

Ejemplos de mala praxis (y de praxis correcta)

Son ejemplos de mala praxis con los equipos informáticos: dejar la sesión abierta sin bloquear, apuntar las contraseñas en notas visibles, conectar dispositivos USB no autorizados, instalar software sin control o compartir cuentas de usuario.

En cambio, conectar un portátil corporativo a la red de la empresa es el uso previsto y legítimo del equipo, por lo que NO constituye una mala praxis: se trata de un dispositivo gestionado que se conecta a la red para la que está autorizado.

Medidas técnicas para reforzar los pilares de seguridad

Entre las medidas técnicas que sostienen la confidencialidad, la integridad y la disponibilidad en el puesto de usuario destacan el cifrado de disco, la autenticación robusta, el antivirus/EDR, el cortafuegos, las actualizaciones de seguridad y el control de dispositivos extraíbles.

Ahora bien, una medida incorrecta —que no refuerza los pilares de seguridad— sería "restringir la utilización de los puertos USB y obligar a utilizar otro tipo de interfaces más seguras como lectores de tarjeta SD". El razonamiento es que una tarjeta SD no es intrínsecamente más segura que un USB: ambos son soportes extraíbles con el mismo riesgo de fuga de información o de introducción de malware. Bloquear el USB para forzar otro soporte extraíble no aporta seguridad real; la medida correcta sería controlar o cifrar todos los soportes extraíbles, no sustituir uno por otro equivalente.

Fuentes

• Gobierno de España — Portal de la Firma Electrónica. Formatos de firma (firma múltiple: cofirma y contrafirma): https://firmaelectronica.gob.es/content/firmaelectronica/es/ciudadanos/cosas-deberias-saber/formatos-firma.html

• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (dimensiones de seguridad: confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad). BOE-A-2022-7191: https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191

• ISO/IEC 27001 — Information security management systems (tríada confidencialidad, integridad y disponibilidad): https://www.iso.org/standard/27001