IMAGEN CABECERA — Sustituye src="" https://itoptraining.com/wp-content/uploads/2026/04/como-hacer-una-auditoria-de-tu-plataforma-lms.pngChecklist de auditoría técnica para Moodle™: qué revisar: guía completa paso a paso
Si gestionas una plataforma de formación online, lo que no revisas periódicamente acaba siendo un problema en el peor momento posible: una inspección de SEPE, una fuga de datos, una integración rota antes de un lanzamiento crítico. La auditoría técnica de un LMS no es un lujo; es el mantenimiento preventivo que separa las plataformas que funcionan de las que simplemente parecen funcionar.
En esta guía desglosamos, apartado por apartado, qué debes revisar en una auditoría técnica completa: desde las configuraciones básicas y los roles de usuario hasta el análisis de la base de datos, la seguridad y el cumplimiento de la LOPD/RGPD. Sin jerga innecesaria, con checklists accionables.
1. Configuraciones generales, roles y permisos
La configuración base de un plataforma e-learning es como los cimientos de un edificio: si están mal puestos, todo lo que construyes encima hereda el problema. Lo que resulta especialmente engañoso es que una mala configuración puede permanecer invisible durante meses o años, hasta que una auditoría externa, una inspección o un incidente la saca a la luz.
El primer bloque de cualquier auditoría técnica empieza aquí: revisar que la plataforma está configurada para hacer exactamente lo que se supone que debe hacer, y que no hay ajustes por defecto heredados de la instalación inicial que nadie ha revisado desde entonces.
Qué revisar en las configuraciones generales
- Nombre del sitio, URL canónica y configuración de zona horaria (errores aquí afectan a los registros de tiempo de FUNDAE)
- Política de contraseñas: longitud mínima, caducidad, bloqueo por intentos fallidos
- Configuración del idioma predeterminado y paquetes de idioma instalados
- Límites de subida de archivos (muchos plataforma formativa tienen 2MB por defecto, insuficiente para vídeo)
- Modo de mantenimiento: ¿está desactivado en producción? ¿existe un procedimiento documentado para activarlo?
- Configuración del registro de eventos: ¿se están guardando los logs de acceso con el nivel de detalle requerido?
La trampa de los roles y permisos heredados
En Moodle™ y la mayoría de sistema de formación online basados en roles, los permisos se heredan en cascada: un rol de "Manager" puede tener acceso a datos que en realidad no debería ver en tu contexto específico. El problema habitual es que nadie ha revisado los roles desde la configuración inicial, y los roles por defecto del sistema no coinciden con la estructura real de la organización.
Los profesores pueden ver datos de alumnos de otros cursos. Hay usuarios con rol de administrador que ya no trabajan en la organización. Los responsables de área no tienen acceso a los informes que necesitan. Se usan roles por defecto sin personalización.
Cada rol tiene exactamente los permisos que necesita, ni más ni menos. Los accesos están documentados. Existe un proceso de revisión periódica de usuarios activos. Los roles están alineados con la estructura organizativa real.
Checklist de revisión de roles
- Listar todos los usuarios con rol de administrador y verificar que siguen siendo necesarios
- Revisar permisos del rol "Profesor" o equivalente: ¿puede ver datos de otros cursos? ¿puede matricular usuarios manualmente?
- Verificar que los roles de solo lectura (gestores, responsables de área) no tienen permisos de escritura accidental
- Comprobar roles a nivel de categoría vs. nivel de curso: los permisos globales son un riesgo de seguridad
- Detectar usuarios con cuentas activas que ya han dejado la organización
- Revisar el rol de "Invitado" y si el acceso anónimo está habilitado (en la mayoría de casos no debería estarlo)
Los registros de acceso que se envían al sistema FUNDAE incluyen el identificador de usuario y la marca temporal. Si hay usuarios ficticios, cuentas compartidas o accesos realizados desde el rol de administrador para "probar" cursos, estos registros pueden invalidar las bonificaciones en una inspección.
La auditoría de roles no es solo un tema de seguridad: es también un tema de cumplimiento normativo.
IMAGEN 1 — Configuraciones, roles y permisos2. Versión del plataforma LMS y plugins instalados
Mantener el herramienta de formación actualizado no es una recomendación de buenas prácticas: es una necesidad de seguridad. Las versiones desactualizadas son el vector de ataque más común contra plataformas Moodle™, y la mayoría de brechas documentadas en los últimos años han afectado a instalaciones que llevaban más de seis meses sin actualizar.
Pero el problema no es solo la versión del núcleo: los plugins son igual de críticos, o más. Un plugin con una vulnerabilidad conocida y sin actualizar deja la puerta abierta aunque el núcleo esté perfectamente al día.
Cómo revisar el estado de versiones
Identificar la versión exacta instalada
En Moodle™: Administración del sitio → Notificaciones. Anota la versión exacta (por ejemplo, 4.3.2+). Compara con la última versión estable publicada en moodle.org. Si hay más de una versión de diferencia, es urgente actualizar.
Revisar el ciclo de vida de la versión
Moodle™ publica un roadmap de soporte para cada versión (LTS y estándar). Si tu versión está en "end of life", ya no recibe parches de seguridad. Esto es un riesgo crítico independientemente de cualquier otra consideración.
Inventariar todos los plugins instalados
Administración del sitio → Plugins → Plugins overview. Exporta la lista completa con versión instalada vs. versión disponible. Presta atención especial a plugins con estado "Requiere actualización" o "No compatible con la versión actual de Moodle™".
Detectar plugins abandonados o sin mantenimiento
Verifica en el directorio oficial de Moodle™ (moodle.org/plugins) si cada plugin sigue teniendo mantenimiento activo. Un plugin sin actualizar desde hace más de un año en un plataforma de formación online moderno es un candidato a eliminar o sustituir.
Revisar plugins activos vs. instalados
Es habitual encontrar plugins instalados pero deshabilitados que nadie recuerda haber instalado. Cada plugin añade superficie de ataque y puede afectar al rendimiento aunque esté desactivado. Si no se usa, se desinstala.
| Elemento | Frecuencia de revisión recomendada | Riesgo si se ignora |
|---|---|---|
| Versión del núcleo Moodle™ | Mensual | Crítico |
| Plugins de autenticación (LDAP, SSO) | Mensual | Crítico |
| Plugins de actividad (SCORM, H5P, etc.) | Trimestral | Alto |
| Plugins de informes y analítica | Trimestral | Medio-alto |
| Temas visuales (themes) | Semestral | Medio |
| Plugins de integración (Zoom, Teams, etc.) | Trimestral | Alto |
Los plugins desarrollados internamente o adquiridos a proveedores externos son los más problemáticos: no aparecen en el directorio oficial de Moodle™, no reciben actualizaciones automáticas y pueden quedar obsoletos con cada actualización del núcleo. En la auditoría hay que tratarlos con especial atención y exigir al proveedor un compromiso documentado de mantenimiento.
IMAGEN 2 — Versión y plugins3. Tareas programadas, correos y copias de seguridad
Las tareas programadas (cron) son el sistema nervioso autónomo de un plataforma e-learning: se ejecutan en segundo plano, gestionan los recordatorios de cursos, procesan las matriculaciones automáticas, envían los correos de notificación y actualizan los informes de progreso. Cuando el cron falla, la plataforma parece funcionar, pero por dentro está paralizada.
Este es el apartado de la auditoría que más sorpresas suele deparar, porque los problemas de cron son silenciosos: los alumnos no reciben recordatorios, los managers no ven los informes actualizados, los correos de certificación no se envían. Y nadie lo detecta hasta que alguien pregunta por qué.
Revisión del sistema Cron
- Verificar que el cron se ejecuta correctamente: Administración → Servidor → Tareas programadas. La columna "Última ejecución" no debería tener entradas con más de 1 hora de retraso en tareas críticas
- Revisar el log de errores de cron: Administración → Informes → Registros → Tareas programadas fallidas
- Confirmar que el cron del sistema operativo (crontab en Linux) está configurado para ejecutarse cada minuto, no cada hora
- Comprobar que las tareas de caché, indexación de búsqueda y limpieza de archivos temporales se ejecutan en horarios de baja carga
- Verificar tiempos de ejecución: si alguna tarea tarda más de 5 minutos de forma habitual, hay un problema de rendimiento o configuración
Sistema de correo electrónico
El correo saliente en un plataforma formativa es más crítico de lo que parece: matriculaciones, recordatorios, notificaciones de calificación, recuperación de contraseña, certificados automáticos. Un servidor SMTP mal configurado o bloqueado por un filtro antispam puede estar dejando sin comunicaciones a todos los alumnos sin que nadie lo note.
- Revisar la configuración SMTP: host, puerto (587 para TLS, 465 para SSL), autenticación y credenciales
- Enviar un correo de prueba desde Administración → Servidor → Correo electrónico de prueba
- Verificar que el dominio remitente tiene registros SPF, DKIM y DMARC correctamente configurados para evitar que los correos del sistema de formación online caigan en spam
- Revisar la cola de correos pendientes: en sistemas saturados puede haber miles de correos sin entregar
- Comprobar que las notificaciones de actividades críticas (certificaciones, vencimiento de formación obligatoria) están activadas y configuradas correctamente
Copias de seguridad
Documentar el procedimiento de recuperación ante desastres (RTO/RPO): ¿cuánto tiempo tardaríais en restaurar la plataforma si el servidor principal falla? ¿quién tiene acceso a las copias? ¿dónde están las credenciales de acceso al almacenamiento de backups? Estas preguntas tienen que tener respuestas escritas antes de que haya una emergencia, no durante.
IMAGEN 3 — Cron, correos y backups4. Análisis de la base de datos
La base de datos es donde vive todo: los usuarios, los cursos, los registros de acceso, las calificaciones, los logs de actividad, los trazados SCORM. Una base de datos mal mantenida es el origen más común de problemas de rendimiento, pérdida de datos y errores de seguimiento en plataformas plataforma LMS.
El análisis de base de datos en una auditoría no requiere ser DBA: hay una serie de verificaciones accesibles desde el propio panel de administración de Moodle™ y desde herramientas estándar como phpMyAdmin o la CLI de MySQL/MariaDB que cualquier administrador de sistema debería poder ejecutar.
Verificaciones básicas de estado
- Revisar el tamaño total de la base de datos y su tasa de crecimiento: una base de datos que dobla su tamaño cada seis meses sin que el número de usuarios haya crecido es señal de logs sin purgar o tablas huérfanas
- Ejecutar CHECK TABLE en las tablas principales para detectar tablas corruptas (especialmente tras caídas del servidor)
- Verificar la versión de MySQL/MariaDB y que es compatible con la versión de Moodle™ instalada
- Comprobar el motor de tablas: todas deberían usar InnoDB, no MyISAM (MyISAM no soporta transacciones y es más vulnerable a corrupción)
- Revisar el conjunto de caracteres: utf8mb4 es el estándar actual; tablas en latin1 o utf8 pueden causar problemas con caracteres especiales y emojis
- Verificar que existen índices en las columnas más consultadas (userid, courseid, timecreated en las tablas de log)
Tablas críticas que revisar en Moodle™
| Tabla | Qué contiene | Riesgo si está corrupta o incompleta |
|---|---|---|
| mdl_logstore_standard_log | Todos los eventos y accesos de usuarios | Pérdida de registros FUNDAE |
| mdl_scorm_scoes_track | Trazas SCORM de cada alumno | Datos de completación incorrectos |
| mdl_grade_grades | Calificaciones de actividades y cursos | Informes erróneos, diplomas incorrectos |
| mdl_user | Datos personales de todos los usuarios | Incumplimiento RGPD si hay datos de ex-usuarios |
| mdl_enrol / mdl_user_enrolments | Matriculaciones activas y caducadas | Accesos no autorizados o matriculaciones perdidas |
| mdl_files | Referencias a todos los archivos del herramienta de formación | Archivos huérfanos, ocupación innecesaria |
Optimización y limpieza
Con el tiempo, las bases de datos de plataforma de formación online acumulan datos que ya no son necesarios y ralentizan todas las consultas. Antes de tocar nada, haz siempre un backup completo. Las operaciones de limpieza recomendadas son:
- Purgar logs antiguos: Administración → Servidor → Limpieza de datos. Mantener los últimos 12 meses como mínimo (4 años si hay formación FUNDAE)
- Ejecutar OPTIMIZE TABLE en las tablas de log y de trazas SCORM después de purgas masivas
- Eliminar usuarios borrados que siguen ocupando espacio con la herramienta de eliminación definitiva de usuarios
- Revisar la carpeta de datos (moodledata) en busca de archivos huérfanos no referenciados en mdl_files
- Verificar el tamaño de la caché de aplicación y limpiarla si supera el 20% del espacio de datos total
IMAGEN 4 — Análisis de base de datos5. Seguridad y cumplimiento LOPD/RGPD
Este bloque es el que más ansiedad genera entre los administradores de plataforma, y el que más se pospone. La razón es que combina aspectos técnicos con aspectos legales, y pocas personas tienen dominio de ambos a la vez. Sin embargo, el RGPD no distingue entre "no sabía" y "no cumplía": la responsabilidad recae sobre quien trata los datos.
Un plataforma e-learning maneja datos personales de manera intensiva: nombres, correos, registros de actividad, calificaciones, vídeos de sesiones, en algunos casos datos laborales vinculados al perfil del empleado. Todo eso tiene implicaciones legales concretas que hay que verificar periódicamente.
Seguridad técnica: lo básico que no puede faltar
- SSL/TLS activo y con certificado válido (no caducado, no autofirmado en producción). Verificar con herramientas como SSL Labs que la configuración TLS no tiene vulnerabilidades conocidas
- Cabeceras HTTP de seguridad configuradas: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- Acceso al panel de administración de Moodle™ restringido por IP o con autenticación de dos factores (2FA)
- Directorio /admin no accesible desde el exterior sin autenticación previa
- Archivos de configuración (config.php) fuera del directorio web o con permisos 600
- Deshabilitado el registro público de usuarios si la plataforma es de uso corporativo cerrado
- Política de sesión: tiempo de expiración de sesión por inactividad configurado (máximo 8 horas para entornos de trabajo)
Cumplimiento LOPD/RGPD en el plataforma formativa
Registro de Actividades de Tratamiento
El sistema de formación online debe estar incluido en el Registro de Actividades de Tratamiento de la organización (obligatorio por RGPD). Verifica que existe, que está actualizado y que recoge la base legal del tratamiento (normalmente, ejecución de contrato laboral para empleados).
Contrato de Encargado de Tratamiento con el proveedor
Si el plataforma de aprendizaje online está alojado por un proveedor externo (hosting, SaaS), debe existir un contrato de encargado de tratamiento (DPA) firmado. Sin este contrato, estás cediendo datos personales a un tercero sin cobertura legal.
Localización del hosting
Verifica físicamente dónde están los servidores. Si el proveedor usa infraestructura cloud, comprueba que los datos de usuarios están en servidores dentro de la UE/EEE. Las transferencias internacionales a EE.UU. sin cláusulas contractuales tipo son un incumplimiento directo.
Política de retención y eliminación de datos
¿Qué pasa con los datos de un empleado cuando causa baja? ¿Se eliminan automáticamente? ¿Con qué plazo? El plataforma LMS debe tener un procedimiento documentado de eliminación de datos que cumpla con el principio de limitación del plazo de conservación del RGPD.
Derecho de acceso, rectificación y supresión
Verifica que existe un procedimiento interno para atender solicitudes de ejercicio de derechos RGPD. En Moodle™, la herramienta de privacidad permite exportar y eliminar todos los datos de un usuario específico. ¿Sabe el responsable de plataforma cómo ejecutarlo?
Moodle™ incluye desde la versión 3.5 una herramienta de gestión de privacidad (Administración → Usuarios → Privacidad y políticas) que permite gestionar solicitudes de acceso y eliminación de datos conforme al RGPD. Si tu instalación no la tiene configurada y operativa, es una carencia prioritaria a corregir.
Checklist de seguridad rápida
| Control | Herramienta de verificación | Prioridad |
|---|---|---|
| SSL/TLS sin vulnerabilidades | ssllabs.com/ssltest | Crítica |
| Cabeceras HTTP de seguridad | securityheaders.com | Crítica |
| Moodle™ Security Overview | Admin → Informes → Descripción general de seguridad | Crítica |
| Contrato DPA con proveedor hosting | Revisión documental | Crítica |
| 2FA en cuentas de administrador | Admin → Plugins → Autenticación | Alta |
| Política de retención documentada | Revisión documental | Alta |
| Herramienta de privacidad activa | Admin → Usuarios → Privacidad | Alta |
| Logs de acceso admin revisados | Admin → Informes → Registros | Media |
IMAGEN 5 — Seguridad y LOPD/RGPDPreguntas frecuentes
¿Qué bloques de esta auditoría puedo revisar yo mismo sin conocimientos avanzados?
Los bloques de configuraciones generales, roles y permisos, y revisión del estado de versiones y plugins son completamente accesibles para cualquier administrador de Moodle™ con formación básica. Solo necesitas acceso al panel de administración y seguir la checklist de cada apartado.
El análisis de base de datos (integridad de tablas, optimización, purga de logs) y la revisión de seguridad avanzada (cabeceras HTTP, configuración TLS, revisión de plugins custom) requieren conocimientos de administración de sistemas. Si no tienes ese perfil en tu equipo, esos bloques específicos son los que tiene más sentido externalizar.
¿Por dónde empiezo si nunca he hecho una auditoría técnica de mi LMS?
El orden recomendado es: primero roles y permisos (es el bloque con más riesgo silencioso y más fácil de revisar), después versión del núcleo y plugins, y luego cron y backups. Deja el análisis de base de datos y el bloque de seguridad para el final o para cuando tengas soporte técnico disponible.
Antes de empezar, documenta el estado actual de cada bloque aunque sea en una hoja de cálculo simple: fecha de revisión, qué encontraste y qué acción tomaste. Una auditoría sin registro escrito no tiene valor en una inspección externa.
¿Qué herramientas nativas incluye Moodle™ para apoyar la auditoría técnica?
Moodle™ incluye varias herramientas de administración útiles para la auditoría: la consola de Notificaciones muestra la versión del núcleo y plugins pendientes de actualizar; el Registro de eventos permite revisar los logs de acceso con filtros por usuario, curso o acción; y Plugins overview genera un inventario completo con estado de actualización de cada plugin instalado.
Para el bloque de RGPD, desde la versión 3.5 existe la herramienta de Privacidad y políticas (Administración → Usuarios → Privacidad y políticas), que permite gestionar solicitudes de acceso, exportación y eliminación de datos de usuarios. Si tu instalación no la tiene configurada, es la primera carencia a corregir en ese bloque.
¿Qué diferencia hay entre la auditoría técnica del LMS y la auditoría de cumplimiento FUNDAE?
Son complementarias pero tienen alcance distinto. La auditoría técnica revisa la salud general del sistema: configuración, seguridad, rendimiento, base de datos y cumplimiento RGPD. La auditoría de cumplimiento FUNDAE se centra exclusivamente en verificar que los registros de acceso, tiempos de conexión, actividades y documentación cumplen los requisitos técnicos del SEPE para que las bonificaciones sean válidas ante una inspección.
La secuencia lógica es hacer primero la auditoría técnica: si el sistema no está bien configurado (zona horaria incorrecta, cron fallando, trazas SCORM corruptas), los propios datos de cumplimiento FUNDAE serán infiables y la auditoría normativa no servirá de nada.
Si detecto incumplimientos durante la auditoría, ¿qué pasos debo seguir?
El primer paso es documentar cada hallazgo con fecha, descripción técnica del problema y el riesgo asociado (seguridad, cumplimiento normativo, integridad de datos). No corrijas sobre la marcha sin registro: necesitas evidencia del estado previo y del cambio realizado.
A continuación, prioriza por impacto: los problemas de seguridad activa (versiones con vulnerabilidades conocidas, accesos sin expirar de ex-empleados) y los incumplimientos RGPD con riesgo de sanción van primero. Las mejoras de rendimiento o configuración no críticas pueden planificarse en un segundo bloque. Si detectas ausencia de contratos DPA con proveedores o transferencias internacionales de datos sin cobertura legal, actúa con urgencia: son los supuestos que la AEPD sanciona con mayor severidad.
¿Moodle™ cumple con el RGPD por defecto?
Moodle™ incluye herramientas para facilitar el cumplimiento del RGPD (exportación de datos, eliminación de usuarios, gestión de consentimientos), pero la plataforma en sí no cumple el RGPD: quien cumple o incumple es la organización que la usa y quien la aloja. La configuración, los contratos con proveedores, las políticas de retención y los procedimientos internos son responsabilidad del responsable del tratamiento, no de Moodle™ HQ.
Dicho de otro modo: instalar Moodle™ no te protege ante la AEPD. Lo que te protege es tener el Registro de Actividades de Tratamiento actualizado, el contrato DPA firmado con tu proveedor de hosting, los datos alojados en servidores dentro de la UE y un procedimiento operativo para atender solicitudes de derechos RGPD cuando llegan.
