Sede electrónica: requisitos técnicos, interoperabilidad y accesibilidad

Cada vez que una administración saca a licitación «la evolución de su sede electrónica», el anexo técnico del pliego mezcla en treinta páginas cosas muy distintas: artículos de la Ley 39/2015, normas técnicas de interoperabilidad, categorías del Esquema Nacional de Seguridad, criterios WCAG y nombres de plataformas comunes que nadie explica. El resultado habitual es un proyecto que se presupuesta como un portal web y se entrega como un sistema de información crítico, con la diferencia de coste y de riesgo que eso implica.

Este artículo es el mapa que nos habría gustado tener la primera vez: qué es exactamente una sede electrónica desde el punto de vista jurídico, qué requisitos técnicos se derivan de cada norma, qué plataformas comunes hay que integrar en lugar de reinventar, qué se audita de verdad en accesibilidad y qué cambia en los próximos meses. Está escrito desde el lado del proveedor —el que firma el pliego y responde de la conformidad—, no desde el lado del manual de oposiciones.

Hay dos razones para leerlo ahora. La primera: el 24 de diciembre de 2026 es la fecha límite para que la cartera de identidad digital europea (EUDI Wallet) esté operativa en todos los Estados miembros, y las sedes electrónicas están entre los servicios que deben aceptarla. La segunda: en septiembre de 2026 se publicó la versión 4.1.1 de la norma EN 301 549, que sube la referencia de accesibilidad a WCAG 2.2 — con un matiz legal importante que casi nadie está contando bien y que explicamos en la sección 7.

Si tu empresa trabaja o quiere trabajar con la administración, este artículo complementa lo que ya contamos sobre cómo licitar tecnología con la administración pública y sobre cómo cumplir el ENS cuando eres proveedor tecnológico.

1. Qué es una sede electrónica (y qué no)

La confusión de base de muchos proyectos es tratar la sede como «la web de la administración». No lo es. La sede electrónica es una dirección electrónica con régimen jurídico propio: lo que ocurre dentro de ella tiene efectos legales, y la administración titular responde de la integridad, veracidad y actualización de su contenido.

1.1 Tres artefactos distintos que el pliego suele mezclar

• Portal de internet (art. 39 de la Ley 39/2015): el escaparate informativo. Sin efectos jurídicos propios. Aquí viven las noticias, la agenda y el organigrama.
• Sede electrónica (art. 38): la dirección donde el ciudadano ejerce derechos y cumple obligaciones. Titularidad, gestión y administración pueden recaer en órganos distintos, y eso hay que documentarlo.
• Punto de Acceso General Electrónico (PAGe): el directorio que federa sedes y servicios. Tu sede debe estar dada de alta y descrita ahí, no solo existir.

Mezclarlos tiene consecuencias técnicas concretas: si publicas el catálogo de trámites en el portal y no en la sede, el trámite no es exigible; si publicas en la sede contenido que cambia a diario sin control de versiones, estás asumiendo una responsabilidad de integridad que no puedes sostener.

1.2 Sede asociada: la figura que resuelve los proyectos multi-organismo

El Real Decreto 203/2021 permite las sedes electrónicas asociadas: una sede de ámbito más reducido que se crea bajo una sede principal, con su propia resolución de creación pero compartiendo infraestructura. Es la respuesta correcta cuando un consorcio, un organismo autónomo o una entidad instrumental necesita identidad propia sin duplicar plataforma. En términos de arquitectura, se traduce en multi-tenancy: un mismo despliegue, dominios o rutas distintas, catálogos de trámites separados, sellos de órgano distintos y trazas de auditoría segregadas.

1.3 Contenido y servicios mínimos

El RD 203/2021 fija un contenido mínimo que en un proyecto real se convierte en una lista de páginas y servicios que hay que construir, no en una declaración de intenciones:

• Identificación de la sede y del órgano titular, con la disposición de creación.
• Catálogo de trámites y servicios con su información asociada: plazos, requisitos, normativa y órgano responsable.
• Acceso al registro electrónico y a la carpeta del interesado.
• Información sobre medios de identificación y firma admitidos, y sobre los sistemas de firma del propio órgano.
• Fecha y hora oficiales visibles, y calendario de días inhábiles.
• Servicio de verificación de documentos mediante CSV (código seguro de verificación).
• Enlace al PAGe, cláusulas de protección de datos y declaración de accesibilidad.
• Mecanismo de comunicación de incidencias y de quejas en materia de accesibilidad.

Cada uno de esos puntos es un entregable verificable. Es la primera lista que conviene convertir en criterios de aceptación del contrato: ahorra discusiones al final.

2. Las cinco capas normativas que definen el alcance técnico

Una sede no se rige por una norma, sino por cinco capas que se auditan de forma independiente y por organismos distintos. Entenderlas separadas es lo que permite estimar bien.

2.1 Procedimiento: Ley 39/2015, Ley 40/2015 y RD 203/2021

La Ley 39/2015 define los derechos del interesado y, con ellos, las funciones que tu sistema debe ofrecer: registro electrónico general, representación y apoderamiento, notificaciones electrónicas, archivo electrónico único, derecho a no aportar documentos que ya obren en poder de la administración. La Ley 40/2015 regula el funcionamiento interno —sede, sello electrónico, actuación administrativa automatizada, intercambio de datos entre administraciones—. El RD 203/2021 es el reglamento que baja todo eso a detalle operativo y es, en la práctica, el documento que más vas a consultar durante el desarrollo.

2.2 Interoperabilidad: el ENI y las Normas Técnicas

El Esquema Nacional de Interoperabilidad (RD 4/2010) se concreta en un conjunto de Normas Técnicas de Interoperabilidad (NTI) que son las que de verdad condicionan el código: documento electrónico, expediente electrónico, digitalización de documentos, copia auténtica y conversión, política de firma, catálogo de estándares, modelo de datos para el intercambio de asientos registrales, requisitos de conexión a la red de comunicaciones, procedimientos de reutilización. No son recomendaciones: definen esquemas XML, metadatos obligatorios y formatos admitidos.

2.3 Seguridad: el ENS vigente (RD 311/2022)

El Esquema Nacional de Seguridad actual es el del Real Decreto 311/2022, que sustituyó al RD 3/2010. Para un proyecto de sede importan tres cosas: la categorización del sistema (básica, media o alta) según el impacto en las cinco dimensiones, los perfiles de cumplimiento específicos que simplifican la aplicación en ciertos ámbitos, y el régimen de conformidad —autoevaluación con declaración para categoría básica, auditoría y certificación para media y alta—. Si la sede la opera un proveedor, el ENS le alcanza por la vía contractual. Lo desarrollamos en nuestra guía completa del Esquema Nacional de Seguridad y, en lo que toca a políticas y procedimientos, en el marco organizativo del ENS.

2.4 Identificación y firma

Capa transversal: qué medios acepta la sede para identificar al interesado, qué firma exige en cada trámite, cómo valida certificados y cómo firma la propia administración. Es donde más se improvisa y donde más caro sale improvisar.

2.5 Accesibilidad: RD 1112/2018 y UNE-EN 301 549

El Real Decreto 1112/2018 traspone la directiva europea de accesibilidad del sector público y remite a la norma UNE-EN 301 549, que a su vez remite a WCAG en nivel AA. A diferencia de las otras capas, esta tiene un órgano de seguimiento que publica informes y un mecanismo de reclamación al alcance de cualquier ciudadano. Es, con diferencia, la capa que genera más incidencias posteriores a la entrega.

3. Identificación y firma: del certificado a la cartera europea

3.1 Niveles de garantía y medios admitidos

No todos los trámites exigen lo mismo. El diseño correcto parte de clasificar cada trámite del catálogo por nivel de garantía exigido y asignarle los medios admitidos, en vez de aplicar el máximo a todo —que es lo que hace caer la tasa de finalización—:

• Cl@ve en sus distintas modalidades, para identificación y para firma no criptográfica en trámites de impacto bajo o medio. Cl@ve Móvil ha ido sustituyendo al clásico PIN por SMS.
• Certificado electrónico cualificado de persona física, de representante de persona jurídica o de empleado público, y DNIe, cuando se exige firma avanzada o cualificada.
• Registro de apoderamientos y apoderamiento apud acta electrónico, para que un tercero actúe en nombre del interesado. Lo olvida casi todo el mundo en el análisis y luego aparece como «fuera de alcance».

3.2 Las piezas que no hay que construir

Uno de los errores de presupuesto más caros es implementar a mano lo que el Estado ya ofrece como servicio compartido. Antes de escribir una línea de validación de certificados, hay que integrar:

• Plataforma de validación de firma y certificados (conocida como @firma) y su versión de escritorio para el ciudadano (Autofirma), más el servicio web de validación puntual.
• Servicio de firma en la nube para evitar que el ciudadano dependa de Java o de instalar software local.
• Servicio de sellado de tiempo cualificado, imprescindible para acreditar el momento exacto de presentación.
• Generación y verificación de CSV junto con el sello de órgano, para que cualquier documento emitido tenga copia auténtica verificable desde la propia sede.

3.3 Actuación administrativa automatizada

Cuando la sede resuelve sin intervención humana —un certificado de empadronamiento, un justificante, una resolución estandarizada— estamos ante actuación administrativa automatizada. Requiere acto previo de definición del procedimiento, del órgano responsable a efectos de impugnación y del sistema de firma empleado: sello electrónico de órgano o código seguro de verificación. Técnicamente implica trazabilidad completa de qué regla se aplicó, con qué versión y sobre qué datos. Si no puedes reconstruir eso a los cuatro años, no has cumplido.

3.4 El plazo que cambia el panorama: 24 de diciembre de 2026

El Reglamento (UE) 2024/1183 —el llamado eIDAS 2— obliga a los Estados miembros a poner a disposición de la ciudadanía al menos una cartera de identidad digital europea, y fija como fecha operativa el 24 de diciembre de 2026, veinticuatro meses después de los primeros actos de ejecución. Para una sede electrónica eso significa dos cosas: aceptar la cartera como medio de identificación y, cuando corresponda, como origen de atributos verificados; y darse de alta como parte receptora en el registro nacional correspondiente.

En términos de arquitectura, la recomendación es clara: la capa de identificación debe quedar aislada detrás de una interfaz propia. Quien acople Cl@ve o el validador de certificados directamente al controlador del formulario va a pagar dos veces el mismo trabajo. Quien tenga un proveedor de identidad abstraído añade la cartera europea como un adaptador más.

4. Registro electrónico, notificaciones y cómputo de plazos

4.1 El asiento registral y el estándar SICRES

Todo escrito que entra por la sede genera un asiento en el registro electrónico y un recibo automático para el interesado con número de asiento, fecha y hora de presentación y relación de documentos aportados. El intercambio de esos asientos entre entidades registrales se rige por la NTI de modelo de datos, aprobada en su versión SICRES 4.0 por resolución de 22 de julio de 2021. Si tu registro no habla SICRES, no es interoperable: es un formulario con base de datos.

4.2 Las plataformas de intercambio registral

El Sistema de Interconexión de Registros y sus aplicaciones asociadas permiten que un escrito presentado en un ayuntamiento llegue al organismo competente sin papel. La decisión de proyecto es si se integra el registro propio con el sistema de intercambio o si se adopta directamente una de las aplicaciones comunes. La segunda opción reduce drásticamente el alcance del desarrollo y la superficie de cumplimiento; la primera solo se justifica cuando hay un gestor de expedientes propio ya consolidado.

4.3 Notificaciones: donde se pierden los expedientes

La notificación electrónica es el punto de más litigio. Los requisitos técnicos relevantes:

• Puesta a disposición en la dirección electrónica habilitada única y en la carpeta del interesado, con aviso al correo o al móvil facilitado. El aviso no es la notificación: su fallo no invalida el acto, pero su ausencia sistemática sí es un problema de calidad.
• Acreditación de la puesta a disposición, del acceso y del rechazo, con sellado de tiempo. Tres evidencias distintas, tres registros distintos.
• Rechazo por transcurso del plazo: pasados diez días naturales sin acceder, la notificación se entiende rechazada y el procedimiento continúa. Ese temporizador debe vivir en el sistema de notificaciones, no en una tarea programada casera.
• Posibilidad de que el interesado consulte el histórico completo, incluidas las notificaciones ya rechazadas.

4.4 Fecha, hora y días inhábiles

Parece trivial y no lo es. La sede debe mostrar la fecha y hora oficiales —sincronizadas con la fuente oficial, no con el reloj del servidor— y publicar el calendario de días inhábiles aplicable. El cómputo de plazos depende de ambos. Un desajuste de zona horaria en el cambio de hora, o un servidor sin NTP fiable, genera presentaciones con fecha incorrecta y recursos ganados. Conviene tratar el reloj como un componente crítico, con monitorización y alerta de deriva.

5. Interoperabilidad: no volver a pedir lo que ya consta

5.1 Intermediación de datos

El derecho a no aportar documentos que ya estén en poder de la administración se materializa técnicamente a través del sistema de verificación y consulta de datos entre administraciones. Cada consulta tiene su servicio, su esquema de petición y respuesta y su requisito de consentimiento o de habilitación legal. El trabajo real del proyecto es: identificar para cada trámite qué datos se pueden obtener por intermediación, tramitar la autorización de acceso al servicio correspondiente, e implementar el fallback cuando el servicio no responde —porque va a no responder—.

El impacto en experiencia de usuario es enorme: un formulario que pasa de pedir ocho documentos a pedir uno multiplica la tasa de finalización. Es el argumento que mejor funciona para justificar la inversión en interoperabilidad ante un responsable no técnico.

5.2 Documento y expediente electrónico

Un documento electrónico administrativo no es un PDF. Es contenido, metadatos mínimos obligatorios y firma o sello, serializado según la NTI correspondiente. El expediente añade su índice firmado y la relación ordenada de documentos. Los metadatos siguen el esquema de metadatos para la gestión del documento electrónico, y las copias auténticas tienen su propia norma de generación y conversión de formato.

La consecuencia práctica para el equipo de desarrollo: la capa de documentos debe nacer como servicio con su propio modelo, no como una carpeta de ficheros con una tabla al lado. Reconstruir esto a mitad de proyecto cuesta más que hacerlo bien desde el principio, y es la causa número uno de que un expediente no se pueda remitir a otra administración ni a un tribunal.

5.3 Archivo electrónico único

Los documentos deben conservarse en formato que garantice autenticidad, integridad y conservación, con posibilidad de traslado a otros formatos y soportes a lo largo del tiempo. Esto obliga a decidir pronto: formato de preservación, política de firma longeva —resellado antes de que caduquen los certificados—, y estrategia de migración. Un expediente firmado hace ocho años con algoritmos ya débiles y sin resellado es un expediente con problemas de validez.

6. Seguridad: el ENS aplicado a una sede real

6.1 Categorizar antes de diseñar

La categoría del sistema determina qué medidas aplican, y por tanto el coste. Una sede que tramita subvenciones con datos económicos y personales difícilmente baja de categoría media. Categorizar al final del proyecto, cuando la arquitectura ya está cerrada, es la forma más fiable de descubrir que faltan medidas estructurales: segregación de entornos, doble factor para administración, cifrado en reposo, registro de actividad con retención suficiente.

6.2 Las medidas que tocan directamente al código

• Control de acceso: mínimo privilegio, segregación de funciones, doble factor para perfiles administrativos, revisión periódica de permisos.
• Registro de actividad con información suficiente para reconstruir quién hizo qué y cuándo, protegido contra manipulación y con retención acorde a la categoría. Un log que el propio administrador puede borrar sin rastro no cumple.
• Desarrollo seguro: ciclo de vida con requisitos de seguridad, análisis estático y de dependencias, gestión de vulnerabilidades y entornos separados con datos de prueba que no sean datos reales. Es el punto que mejor se evidencia con una auditoría de código profesional.
• Protección de las comunicaciones: TLS actualizado, cabeceras de seguridad, separación de redes y protección frente a denegación de servicio. Lo detallamos en el capítulo sobre medidas de protección de comunicaciones y aplicaciones del ENS.
• Monitorización y gestión de incidentes con procedimiento de notificación, según el marco operacional del ENS.

6.3 Conformidad: declaración, certificación y lo que firma el proveedor

Para categoría básica basta una autoevaluación con declaración de conformidad; para media y alta hace falta auditoría por entidad acreditada y certificación, con revisión al menos bienal. El distintivo debe publicarse en la propia sede. Si el sistema lo opera un tercero, el contrato debe reflejar qué medidas asume cada parte: la matriz de responsabilidades compartidas es el documento que evita el bloqueo en la auditoría. Para quien ya trabaja con ISO 27001, merece la pena revisar los solapamientos en nuestra comparativa de ENS frente a ISO 27001. Y si la entidad está además en el ámbito de la directiva europea de ciberseguridad, conviene cruzarlo con las obligaciones derivadas de NIS2.

7. Accesibilidad: qué se audita de verdad y qué norma es exigible hoy

7.1 La pregunta que casi todo el mundo responde mal

En septiembre de 2026 se publicó la versión 4.1.1 de la EN 301 549. Eleva la referencia a WCAG 2.2, incorpora los nuevos criterios de esa versión y retira el criterio 4.1.1 sobre análisis sintáctico, ya obsoleto. La tentación es escribir en el pliego «cumplimiento de la EN 301 549 v4.1.1» y dar el tema por resuelto.

El matiz legal importa: a fecha de hoy la nueva versión no ha sido citada en el Diario Oficial de la Unión Europea como norma armonizada. La referencia legalmente exigible sigue siendo la v3.2.1 (2021), basada en WCAG 2.1 nivel AA, tanto para la directiva de accesibilidad del sector público como para la ley europea de accesibilidad. Traducido a decisiones de proyecto:

• Lo exigible y auditable hoy es WCAG 2.1 AA. Es lo que debe recoger el criterio de aceptación contractual y lo que mide el seguimiento oficial.
• Lo prudente es diseñar ya contra WCAG 2.2: los criterios nuevos son de coste bajo si se contemplan desde el diseño y muy caro si hay que reintroducirlos en un rediseño posterior.
• Lo honesto en una oferta es decir exactamente esto, en vez de prometer conformidad con una norma que todavía no es la referencia legal.

7.2 Los criterios de WCAG 2.2 que más impactan en una sede

Los añadidos de WCAG 2.2 encajan sospechosamente bien con los puntos débiles de un trámite administrativo: foco no tapado por cabeceras fijas o banners de cookies, objetivos de clic con tamaño mínimo, alternativas a los gestos de arrastre, ayuda localizada de forma consistente, evitar que el usuario tenga que reintroducir información ya aportada en pasos anteriores del mismo proceso, y autenticación que no dependa de una prueba cognitiva. Cualquiera que haya auditado un formulario de subvenciones de siete pasos reconocerá los cinco últimos como fallos habituales.

7.3 La declaración de accesibilidad: el incumplimiento más frecuente

Es obligatoria, tiene contenido tasado y es lo primero que se revisa porque está a un clic. Debe indicar el grado de cumplimiento, la fecha de la revisión y el método empleado, el contenido no accesible con su justificación, el mecanismo de comunicación y el procedimiento de reclamación. Dos errores típicos: copiar la declaración de otra entidad —con su fecha y su alcance— y declarar «plenamente conforme» un sitio con PDF no etiquetados. Declarar parcialmente conforme con una lista honesta de excepciones y un plan de corrección es una posición mucho más defendible que una conformidad total que cualquier reclamación desmiente en diez minutos.

7.4 Los patrones que rompen una sede

• PDF como único canal. Un formulario en PDF descargable no es una alternativa accesible: si existe, debe estar etiquetado y, sobre todo, debe haber camino equivalente en HTML.
• Captchas visuales sin alternativa, que además chocan con el criterio de autenticación accesible.
• Expiración de sesión sin aviso: perder veinte minutos de formulario es un fallo de accesibilidad, no solo de usabilidad. Hace falta aviso y posibilidad de prolongar.
• Tablas de datos maquetadas como capas o, al revés, maquetación con tablas: resoluciones y listados de subvenciones son el caso clásico.
• Mensajes de error solo por color o inyectados sin anuncio en regiones activas, de modo que un lector de pantalla no los percibe.
• Visores de documentos embebidos que atrapan el foco del teclado.

La disciplina de accesibilidad es idéntica a la que aplicamos en proyectos privados tras la entrada en vigor de la ley europea de accesibilidad; en comercio electrónico lo vimos con detalle al tratar la accesibilidad WCAG aplicada a una tienda online. La diferencia en sector público es que aquí hay seguimiento oficial y un canal de reclamación con plazo de respuesta.

7.5 Unidad responsable, revisión y seguimiento

El RD 1112/2018 exige designar una unidad responsable de accesibilidad, mantener un mecanismo de comunicación con plazo de respuesta y someterse a revisiones de seguimiento. En un contrato de desarrollo o de mantenimiento esto se traduce en obligaciones concretas para el proveedor: revisión automatizada continua en integración continua, revisión manual periódica con tecnologías asistivas, informe por cada entrega y atención a las incidencias que entren por el mecanismo de comunicación dentro del plazo. Si el pliego no lo dice, conviene ofrecerlo: es lo que marca la diferencia entre una sede que pasa el seguimiento y una que acumula reclamaciones.

8. Rendimiento, disponibilidad y los picos que nadie planifica

Una sede electrónica tiene un patrón de carga brutalmente desigual: meses planos y picos de dos horas cuando abre el plazo de una convocatoria, una oposición o una subvención. La planificación debe partir de ese perfil, no de la media.

• Prueba de carga sobre el escenario real: miles de usuarios identificándose y firmando a la vez. El cuello de botella casi nunca es la base de datos: son los servicios externos de validación de firma y de intermediación de datos, que tienen sus propios límites de concurrencia.
• Colas y asincronía para registro, generación de justificantes y envío de notificaciones. El usuario debe tener su recibo al instante; el procesamiento posterior puede diferirse.
• Degradación controlada: si cae el servicio de intermediación, el trámite debe permitir aportar el documento manualmente en lugar de fallar.
• Métricas de experiencia real, no solo de servidor. Las mismas que aplicamos en proyectos de negocio: conviene revisar nuestro artículo sobre Core Web Vitals e INP, porque un formulario de siete pasos con interacciones lentas pierde solicitudes igual que un checkout.
• Ventanas de mantenimiento publicadas en la sede, con aviso previo. Una indisponibilidad no anunciada en el último día de plazo tiene consecuencias jurídicas: por eso la norma contempla la ampliación de plazos cuando hay incidencias técnicas.

9. Arquitectura de referencia y errores de proyecto que se repiten

9.1 Un esqueleto que funciona

La arquitectura que mejor envejece separa cinco responsabilidades, cada una con su interfaz propia: presentación (catálogo de trámites y formularios, el único punto donde se juega la accesibilidad), identidad (adaptadores para Cl@ve, certificado y cartera europea), registro (asientos e interoperabilidad SICRES), documentos y expediente (metadatos, firma, copias auténticas, archivo) y notificaciones. El gestor de expedientes consume esos servicios; no los contiene.

La ventaja es muy concreta: cuando cambia una norma, cambia un módulo. La llegada de la cartera europea toca identidad; una nueva versión de la NTI de asientos toca registro; un cambio de referencia en accesibilidad toca presentación. En un monolito donde el formulario valida el certificado y escribe el asiento, cada cambio normativo es un proyecto entero.

9.2 Los seis errores que más caros salen

1. Presupuestar una sede como un portal. El desarrollo visible es una fracción pequeña; las integraciones, las evidencias de conformidad y la accesibilidad son la mayor parte del esfuerzo.
2. Dejar la accesibilidad para el final. Es la única capa que se resuelve en el diseño. Auditarla con el desarrollo cerrado convierte correcciones de maquetación en rehacer flujos completos.
3. Construir lo que ya existe como servicio común. Validadores de firma, sellado de tiempo, intermediación de datos: integrar es más rápido, más barato y más defendible en auditoría.
4. Ignorar la representación. Los gestores, las empresas y los despachos tramitan en nombre de terceros. Si el apoderamiento no está en el análisis, aparecerá como cambio de alcance.
5. No diseñar la evidencia. Conformidad ENS, accesibilidad y validez del acto se demuestran con registros, informes y trazas. Si no se diseñan desde el principio, hay que fabricarlos a posteriori, que es lo más caro y lo menos creíble.
6. Entregar sin plan de mantenimiento normativo. Las normas se mueven: ENS revisado, nuevas NTI, nueva versión de la norma de accesibilidad, cartera europea. Una sede sin contrato de mantenimiento evolutivo queda desfasada en dos años.

10. Checklist de verificación antes de entregar

Lista corta, verificable y pensada para usarse como criterio de aceptación:

• Resolución de creación de la sede publicada y accesible desde la propia sede; alta en el punto de acceso general.
• Catálogo de trámites completo, con plazos, requisitos, normativa y órgano responsable por trámite.
• Fecha y hora oficiales visibles y sincronizadas; calendario de días inhábiles publicado y vigente.
• Registro electrónico operativo, con recibo automático y asientos conformes al modelo de datos vigente.
• Medios de identificación y firma declarados por trámite, con su nivel de garantía; representación y apoderamiento soportados.
• Verificación de documentos por CSV funcionando sobre documentos reales emitidos por el sistema.
• Notificaciones con acreditación de puesta a disposición, acceso y rechazo, y temporizador de diez días naturales probado.
• Categorización ENS documentada y aprobada; medidas implantadas y declaración o certificación de conformidad según categoría, con distintivo publicado.
• Revisión de accesibilidad frente a WCAG 2.1 AA —automatizada y manual con tecnologías asistivas—, informe de resultados y declaración de accesibilidad con fecha, alcance, no conformidades y mecanismo de comunicación.
• Prueba de carga del escenario de apertura de plazo, con comportamiento verificado ante caída de servicios externos.
• Protección de datos: base jurídica por tratamiento, información en capas en cada formulario y registro de actividades actualizado.
• Plan de mantenimiento normativo con responsable, periodicidad y presupuesto.

11. Conclusión: la conformidad se diseña, no se parchea

Una sede electrónica no es un proyecto web con requisitos legales añadidos: es un sistema de información con efectos jurídicos cuya arquitectura está determinada por cinco cuerpos normativos distintos. Las tres decisiones que más determinan el resultado se toman en las primeras semanas: aislar la capa de identidad —porque la cartera europea llega el 24 de diciembre de 2026—, tratar el documento electrónico como servicio con metadatos y firma desde el día uno, y diseñar contra criterios de accesibilidad reales antes de maquetar.

Y una última recomendación sobre accesibilidad, que es donde más ruido hay ahora mismo: contrata y audita contra WCAG 2.1 AA, que es lo legalmente exigible hoy, y diseña contra WCAG 2.2, que es hacia dónde va la norma. Prometer conformidad con la v4.1.1 antes de que sea la referencia citada en el Diario Oficial es un riesgo contractual sin ninguna ventaja competitiva real.

Preguntas frecuentes

¿Una sede electrónica puede ser un WordPress o un Drupal?

La capa de presentación e información sí, y de hecho es habitual: catálogo de trámites, contenidos obligatorios, declaración de accesibilidad y accesibilidad general se gestionan muy bien con un CMS maduro. Lo que no debe vivir en el CMS es el registro, la firma, el expediente ni las notificaciones: esos son servicios con requisitos de trazabilidad, integridad y conservación que un gestor de contenidos no está diseñado para cubrir. El patrón sano es CMS para la cara visible, servicios especializados detrás.

¿Qué norma de accesibilidad hay que poner en el pliego en 2026?

La referencia exigible es la UNE-EN 301 549 en su versión armonizada vigente, que remite a WCAG 2.1 nivel AA. La versión 4.1.1 de la norma europea, publicada en septiembre de 2026 y basada en WCAG 2.2, aún no está citada en el Diario Oficial de la UE. Lo recomendable es exigir conformidad con lo vigente y pedir, como mejora valorable, el diseño alineado con WCAG 2.2.

¿Qué pasa si la sede se cae el último día de plazo?

La normativa contempla que, cuando una incidencia técnica impide el funcionamiento ordinario del registro, se amplíe el plazo no vencido, con publicación en la propia sede de las condiciones de la ampliación. Para el proveedor eso significa dos obligaciones prácticas: monitorización con evidencia objetiva de la indisponibilidad y un procedimiento acordado para publicar el aviso con rapidez.

¿El ENS aplica al proveedor o solo a la administración?

La obligación es de la entidad del sector público, pero se extiende contractualmente a quien le presta servicios que tratan información o servicios afectados. En la práctica, el pliego exige medidas concretas, evidencias y, con frecuencia, certificación propia del proveedor. Conviene aclarar antes de firmar qué medidas asume cada parte mediante una matriz de responsabilidades.

¿Cuántas de las plataformas comunes hay que integrar como mínimo?

Para una sede que tramite de verdad, el mínimo realista son cinco familias: identificación, validación de firma y sellado de tiempo, intercambio registral, notificaciones e intermediación de datos. Cada una requiere trámite de alta, entorno de pruebas y tiempos de autorización que no dependen del equipo de desarrollo: hay que planificarlos al principio del proyecto, porque son la causa más frecuente de retraso en la puesta en producción.

¿Cada cuánto hay que revisar la conformidad una vez entregada?

La conformidad ENS de categoría media o alta se revisa al menos cada dos años. La accesibilidad requiere revisión periódica y actualización de la declaración cuando cambia el sitio o la norma. A efectos de contrato, lo sensato es una revisión anual completa más revisión automatizada continua en cada despliegue.