La elección de hosting para sitios municipales debe garantizar ENS, GDPR y continuidad. El pliego exige SLA medibles, residencia de datos y soporte para mantenimiento WordPress.
Hosting para sitios gubernamentales locales
La selección prioriza cumplimiento normativo, trazabilidad y soporte para mantenimiento WordPress. El proveedor debe acreditar evidencias técnicas y operativas.
Residencia y soberanía de datos
La sede física de los datos debe estar en España o la UE y constar en el contrato. El pliego exige listado de centros de datos, subcontratistas y flujos transfronterizos.
Certificaciones y evidencias
Solicitar ISO/IEC 27001, informes de auditoría y resultados de pentests. El RD 3/2010 (ENS) está vigente desde su entrada en vigor. La Directiva (UE) 2016/2102 obliga desde su adopción. El RGPD está en vigor desde su entrada en aplicación.
Cláusulas obligatorias en el contrato
Incluir cláusulas sobre tratamiento de datos, subencargados y derecho de auditoría. El proveedor notificará al responsable sin dilación indebida ante cualquier incidente de seguridad.
El responsable notifica a la AEPD en un plazo máximo de 72 horas desde que tiene constancia. El pliego debe aclarar responsabilidades y flujos entre encargado y responsable.
Cláusula modelo para incluir en el pliego:
"El proveedor garantizará la residencia de datos en centros localizados en España o, en su defecto, en la UE. El contrato incluirá un anexo con el listado de centros de datos y subprocessors. El proveedor mantendrá la certificación ISO/IEC 27001 vigente. El proveedor aportará, en la fase de adjudicación, informes de auditoría y resultados de pentest recientes. El SLA incorporará RTO y RPO por servicio; RTO ≤ 4 h y RPO ≤ 1 h para servicios críticos. El SLA incluirá penalizaciones por incumplimiento y la obligación de backups automáticos con retención mínima de 90 días. El proveedor realizará pruebas anuales de restauración y mantendrá evidencia. Se exigirá derecho de auditoría y acceso a logs en formato interoperable para la administración."
Seguridad y cumplimiento para sitios gubernamentales
La estrategia de seguridad combina controles técnicos, gobernanza contractual y auditorías periódicas. La evidencia documental debe vincularse al contrato.
Controles técnicos imprescindibles
Exigir WAF, mitigación DDoS y cifrado en tránsito y en reposo con AES-256. El proveedor debe ofrecer logs centralizados con retención mínima de 90 días para auditoría.
Gestión de incidentes y coordinación
Definir el proceso de notificación cuando ocurra una brecha. Establecer roles responsables y tiempos de respuesta claros.
La administración municipal y la AEPD deben poder acceder a registros para investigación. Esto debe constar en cláusulas y en procedimientos operativos.
Agencia Española de Protección de Datos (AEPD)
Auditorías y pruebas de seguridad
Solicitar pentest anual y pruebas de restauración documentadas. El error más frecuente en este punto es aceptar una declaración de cumplimiento sin revisar los informes técnicos.
Rendimiento WordPress para gobiernos: caché y CDN
El hosting debe facilitar configuraciones que mantengan conformidad y rendimiento del portal. El proveedor debe detallar dichas configuraciones en el pliego.
Asegurar que la CDN respeta headers que afectan a tecnologías de asistencia. Configurar caché con reglas que permitan bypass para páginas dinámicas y pruebas de accesibilidad.
Entornos staging y pruebas regresivas
Requerir entornos de staging para cada actualización del core, plugins y temas. Esto reduce riesgos y facilita pruebas controladas.
Esto funciona bien en teoría. En la práctica muchos municipios no exigen pruebas regresivas documentadas.
Configurar hosting para accesibilidad WCAG 2.1 y 2.2. El pliego debe detallar controles de caché y reglas de bypass por URL o cookie. El hosting debe servir encabezados Content-Language y Content-Type correctos.
El proveedor no debe sobrescribir atributos ARIA ni role en HTML. Habilitar compresión sin alterar texto accesible y garantizar que CDN y WAF no bloqueen validadores automáticos.
Documentar procedimientos para excluir rutas críticas de caché cuando la página genere contenido dinámico. Establecer pruebas regresivas automatizadas y manuales tras cada despliegue.
Backups automáticos y recuperación ante desastres
Las copias y el plan de recuperación determinan la continuidad de la sede electrónica. El pliego debe exigir evidencias en el SLA.
RTO y RPO exigibles
Definir RTO y RPO por criticidad. Se exige RTO máximo 4 horas y RPO máximo 1 hora para servicios críticos.
RTO y RPO deben figurar en el SLA y en el DRP del proveedor. Los tiempos deben medirse en simulacros reales.
Política de backups y pruebas
Exigir backups incrementales al menos cada hora para servicios con RPO de 1 hora. Mantener backups completos semanales con retención mínima de 90 días.
Solicitar documentación de simulacros de restauración anual y tiempos reales de recuperación. Incluir resultados en el expediente del proveedor.
Offsite y cifrado
Exigir backups cifrados y almacenamiento en centro alterno en España o UE. El proveedor detallará el proceso de restauración paso a paso en el pliego.
Soporte gestionado y actualizaciones críticas
El servicio de mantenimiento WordPress debe incluir actualización controlada y respuesta a incidentes. El proveedor debe documentar procedimientos y evidencias.
Niveles de soporte y tiempos
Definir niveles L1, L2 y L3 y tiempos de respuesta por prioridad. Establecer P1 ≤ 30 min, P2 ≤ 2 h y P3 ≤ 8 h.
Incluir soporte 24/7 para incidencias P1 que afecten a la sede electrónica. El contrato debe especificar el alcance del soporte.
Procedimiento de actualizaciones
Establecer ventanas de mantenimiento y pruebas en staging antes del despliegue en producción. Obligar a reportes post-actualización que indiquen impacto en accesibilidad y funcionalidad.
Inventario y control de plugins
Mantener inventario aprobado de plugins y temas. Prohibir componentes sin soporte o abandonados.
Un caso habitual: un plugin popular sin actualizaciones provoca una cadena de fallos tras una actualización del core.
Elegir proveedor local: SLA, datacenters y soberanía
Comparar proveedor local, cloud pública con región ES y soluciones híbridas según requisitos del pliego. Elegir según soberanía, SLA y control operativo.
Matriz comparativa de opciones
| Opción |
Soberanía |
SLA típico |
Control operativo |
| Proveedor local |
Alta (centros en ES) |
99.9%–99.95% |
Mayor trazabilidad y soporte cercano |
| Cloud pública (con región ES) |
Media-alta, según contrato |
99.95%–99.99% |
Escalabilidad, requiere cláusulas de soberanía |
| Solución híbrida |
Configuración a medida |
Depende del diseño |
Mejor balance entre control y servicios avanzados |
Cláusulas de trazabilidad
Exigir derecho de auditoría y registros accesibles a la administración municipal. Pedir transparencia sobre subprocessors y localización de réplicas.
Infraestructura y pruebas
Solicitar informe de arquitectura, zonas de disponibilidad y pruebas de failover. Incluir compromiso de simulacros y presentación de resultados.
1 Selección
Requisitos: ENS, GDPR, RTO/RPO
2 Contrato
Cláusulas: soberanía, subencargados
3 Verificación
Pentest, auditoría ISO, pruebas DRP
4 Migración
Staging y pruebas regresivas
5 Operación
Backups, mantenimiento WordPress
Garantías frente a transferencias internacionales: exigir cláusulas tipo SCCs cuando exista transferencia fuera de la UE. Tras Schrems II, pedir evaluaciones de impacto de transferencias y medidas complementarias.
Solicitar cifrado en reposo con claves gestionadas por el ayuntamiento, preferentemente AES-256. Requerir separación de roles y controles de acceso.
Para asegurar soberanía, solicitar réplicas y backups offsite dentro de la UE. Si se permiten réplicas fuera, detallar salvaguardas técnicas y contractuales.
Errores y advertencias en contratación
Excluir proveedores por precio sin evidencias de cumplimiento genera riesgos legales. Evaluar evidencias técnicas antes de decidir.
Riesgos contractuales habituales
Falta de métricas SLA claras y ausencia de penalizaciones por incumplimiento. El error más frecuente en pliegos es no definir RTO y RPO con cifras concretas.
Accesibilidad y dependencias
La conformidad WCAG falla si plugins o temas rompen las pruebas tras actualizaciones. Obligar a auditorías de accesibilidad tras cada despliegue mayor.
Subcontratación y transferencias
No aceptar cláusulas vagas sobre subcontratación ni transferencias fuera de la UE sin garantías. Solicitar siempre lista de subprocessors y acuerdos que restrinjan transferencias.
Para quien prepara un pliego, solicitar una revisión técnica externa reduce riesgos legales y operativos.
No aplicar estas recomendaciones si el sitio no es oficial o no gestiona datos personales sensibles, o cuando la contratación dependa de un órgano superior que impone proveedor único.
Solicite una revisión técnica externa antes de publicar el pliego.
Preguntas frecuentes
¿Qué hosting recomienda para WordPress en municipios?
Se recomienda un proveedor con centros en España o la UE, cumplimiento ENS y soporte WordPress gestionado. Comparar evidencias de auditoría y SLA antes de adjudicar.
¿Qué niveles de SLA exigir en un pliego?
Exigir al menos 99.95% de uptime y tiempos de respuesta P1 ≤ 30 minutos. Incluir RTO máximo 4 h y RPO máximo 1 h para servicios críticos.
¿Cómo mapear ENS con el servicio de hosting?
Solicitar catálogo de controles ENS aplicados y pruebas de auditoría que lo verifiquen. Distinguir entre autodeclaración y evidencia documental externa.
¿Qué pruebas pedir para accesibilidad WCAG?
Auditoría externa WCAG 2.1 o 2.2 con pruebas automatizadas y manuales. Exigir plan de remediación y verificación por el municipio.
¿Qué debe incluir la cláusula de subcontratación?
Lista de subprocessors, condiciones para añadir nuevos y derecho a auditar. Obligación de notificar transferencias fuera de la UE y aplicar garantías adecuadas.
¿Cuándo solicitar revisiones externas?
Solicitar revisión técnica antes de publicar el pliego y tras la adjudicación para validar entregables. La revisión reduce riesgos y comprueba cumplimiento real.
Qué hacer ahora
La recomendación práctica es preparar un pliego que incluya requisitos técnicos, métricas SLA y cláusulas de soberanía y auditoría. Adjuntar en el pliego el checklist mínimo: ENS o ISO, RTO y RPO, backups offsite, WAF y mitigación DDoS.
La evidencia documentada en contrato y los informes de auditoría hacen admisible a un proveedor. Sin ellos no procede adjudicar.
El plazo legal para notificar una brecha a la autoridad de protección de datos es de 72 horas. El plazo empieza cuando la organización tiene constancia de la brecha.
Centro Criptológico Nacional - CCN-CERT
