Qué registros de actividad te van a pedir en una auditoría del ENS

El Esquema Nacional de Seguridad exige registrar la actividad de los usuarios en la medida op.exp.8 «Registro de la actividad» del Anexo II del Real Decreto 311/2022. En su nivel base obliga a dos cosas: generar un registro de auditoría que incluya, como mínimo, quién (identificador del usuario o entidad), cuándo (fecha y hora), sobre qué información se actúa, qué tipo de evento es y con qué resultado (fallo o éxito), y activar los registros de actividad en los servidores.

A partir de ahí, según sube el nivel de la dimensión de trazabilidad, se añaden cinco refuerzos: revisión periódica de los logs, sincronización del reloj, retención documentada, control de acceso a los propios registros y, en el nivel alto, recolección y correlación automática de eventos. Esta guía desgrana cada requisito con el texto consolidado del BOE delante, porque es una de las medidas que más preguntas concentra en auditoría.

Si estás situando esta pieza dentro del conjunto, conviene tener a mano la guía completa del ENS y el repaso de todas las medidas del Anexo II explicadas: op.exp.8 es una medida del marco operacional, dentro del bloque de explotación. El resto de recursos del vertical está en el hub de cumplimiento ENS.

Qué dice exactamente el ENS: la medida op.exp.8

El apartado 4.3.8 del Anexo II del RD 311/2022 formula así los requisitos base, aplicables ya desde el nivel bajo de trazabilidad:

• [op.exp.8.1] «Se generará un registro de auditoría, que incluirá, al menos, el identificador del usuario o entidad asociado al evento, fecha y hora, sobre qué información se realiza el evento, tipo de evento y el resultado del evento (fallo o éxito), según la política de seguridad y los procedimientos asociados a la misma.»
• [op.exp.8.2] «Se activarán los registros de actividad en los servidores.»

Los cinco campos son un mínimo por evento, no una recomendación. Un log que registra «acceso correcto» sin decir de quién, o que apunta el usuario pero no sobre qué información actuó, no cumple el requisito literal.

Y la remisión a «la política de seguridad y los procedimientos asociados» significa que eres tú quien decide qué eventos se auditan, pero esa decisión tiene que estar escrita y ser defendible; el auditor va a pedir el documento, no una explicación verbal.

Fíjate también en que op.exp.8.2 habla de servidores en plural y sin excepciones: la práctica de activar logs solo en el servidor «importante» y dejar mudos los secundarios es una no conformidad fácil de detectar.

Una medida que se aplica por nivel de trazabilidad, no por categoría

Aquí está el matiz que más confusiones genera. La mayoría de medidas del Anexo II escalan por categoría del sistema (básica, media, alta), pero op.exp.8 escala «por trazabilidad»: lo que manda es el nivel asignado a la dimensión T en la valoración del sistema conforme al Anexo I, donde cada dimensión de seguridad (confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad) recibe nivel bajo, medio o alto según el perjuicio que causaría un incidente. Si aún no tienes clara esa valoración, el artículo sobre las cinco dimensiones de seguridad del ENS y el de categorías básica, media y alta la explican paso a paso.

La aplicación de op.exp.8 queda así según el texto consolidado:

La consecuencia práctica: un sistema de categoría media puede tener la trazabilidad valorada en bajo y quedarse en los requisitos base, y al revés, un sistema modesto con necesidades probatorias fuertes puede arrastrar los cuatro primeros refuerzos. Antes de presupuestar herramientas, revisa qué nivel tiene T en tu declaración de aplicabilidad; el autodiagnóstico ENS te ayuda a situarte si partes de cero.

Los cinco refuerzos, uno a uno

R1 — Revisión de los registros

«Se revisarán informalmente, de forma periódica, los registros de actividad, buscando patrones anormales» [op.exp.8.r1.1]. La palabra «informalmente» rebaja la exigencia técnica, no la de constancia: si no puedes demostrar que alguien mira los logs con una periodicidad definida, el refuerzo no se cumple. Un acta breve o un registro de revisiones basta como evidencia.

R2 — Sincronización del reloj del sistema

El sistema debe disponer de una referencia de tiempo para el registro de eventos; modificar esa referencia «será una función de administración» y, si se sincroniza con otros dispositivos, «deberán utilizarse mecanismos de autenticación e integridad» [op.exp.8.r2.1]. Traducido: NTP contra fuentes fiables, con la configuración protegida. Sin relojes coherentes no hay forma de reconstruir una secuencia de eventos entre máquinas, y esa reconstrucción es justo la finalidad de la dimensión de trazabilidad.

R3 — Retención de registros

«En la documentación de seguridad del sistema se deberán indicar los eventos de seguridad que serán auditados y el tiempo de retención de los registros antes de ser eliminados» [op.exp.8.r3.1]. Nótese lo que no dice: el ENS no fija un plazo. Lo que exige es que el plazo exista, esté escrito y se cumpla. Más abajo entramos en cómo decidirlo.

R4 — Control de acceso

«Los registros de actividad y, en su caso, las copias de seguridad de los mismos, solamente podrán ser accedidos o eliminarse por personal debidamente autorizado» [op.exp.8.r4.1]. Este refuerzo tiene historia: en el ENS de 2010 (Real Decreto 3/2010, hoy derogado) la protección de los registros era una medida independiente, op.exp.10, que solo aplicaba en nivel alto. El RD 311/2022 la integró como refuerzo de op.exp.8 y la adelantó al nivel medio de trazabilidad. Si vienes de una adecuación antigua, este es uno de los puntos que cambió de sitio y de exigencia.

R5 — Revisión automática y correlación de eventos

Solo para nivel alto: herramientas que analicen la actividad y la información de auditoría buscando compromisos «posibles o reales» [op.exp.8.r5.1] y «un sistema automático de recolección de registros, correlación de eventos y respuesta automática ante los mismos» [op.exp.8.r5.2]. En la práctica, esto describe un SIEM con capacidad de respuesta, propio o como servicio.

Qué logs concretos hay que recoger

El texto normativo fija los campos y deja la lista de eventos a tu política de seguridad, así que la pregunta correcta es: ¿qué eventos necesito para poder trazar «de forma indiscutible» una actuación hasta su autor, que es como el propio ENS define la trazabilidad? En una adecuación típica, la política acaba cubriendo al menos:

• Autenticación: inicios y cierres de sesión, y especialmente los intentos fallidos (el campo «resultado: fallo o éxito» de op.exp.8.1 apunta directamente aquí).
• Acceso a la información: consultas, modificaciones y borrados sobre los activos relevantes, con el dato de sobre qué información se actuó.
• Acciones de administración: cambios de configuración, gestión de usuarios y permisos, cambios en la propia referencia de tiempo (que R2 reserva a administradores).
• Eventos de seguridad: alertas de las herramientas de protección, bloqueos de cuenta, cambios en los propios mecanismos de registro.

El ENS refuerza esta lógica desde otra medida: op.acc.1 (identificación) exige que quien tenga varios roles frente al sistema —usuario final, trabajador, administrador— reciba identificadores singulares para cada perfil, «de forma que se recaben siempre los correspondientes registros de actividad». Las cuentas genéricas compartidas rompen la trazabilidad por diseño: si tres personas usan «admin», el log cumple los campos pero no responde a la pregunta de quién fue.

Cuánto tiempo conservar los registros

Es la pregunta más repetida y la respuesta honesta es: el RD 311/2022 no establece un número de meses o años. El refuerzo R3 obliga a definir el plazo en la documentación de seguridad, y hay tres criterios para fijarlo con fundamento:

1. La finalidad probatoria. El plazo debe permitir investigar incidentes que suelen descubrirse tarde. Un plazo que no cubra el tiempo medio de detección de una intrusión deja la medida coja frente a su propio propósito.
2. La coherencia interna del ENS. La propia norma, al regular la gestión de cuentas de usuario, exige retener las cuentas dadas de baja «durante el periodo necesario para atender a las necesidades de trazabilidad de los registros de actividad asociados a las mismas», y bautiza ese tiempo como «periodo de retención». Si borras la cuenta antes que sus logs, pierdes la correspondencia identificador-persona.
3. Otras obligaciones que te apliquen. Normativa sectorial, pliegos de contratación con la Administración o requisitos contractuales pueden imponer mínimos propios; y en dirección contraria, la normativa de protección de datos empuja a no conservar más de lo justificable.

En auditoría, lo defendible no es un número mágico sino la coherencia: plazo escrito, motivado y aplicado de verdad (el auditor puede pedir logs de una fecha dentro del plazo declarado y comprobar que existen).

Cómo proteger los propios logs

Un registro de actividad que cualquiera puede editar no prueba nada. Además del control de acceso de R4 —que alcanza también a las copias de seguridad de los logs—, conviene tener presente el problema del administrador: la persona con más capacidad de hacer daño es también la que suele poder borrar sus huellas. Separar la plataforma de registro de los sistemas registrados (envío en tiempo casi real a un repositorio centralizado donde ni los administradores de origen puedan escribir) es la forma habitual de cerrar ese círculo.

Para los sistemas con trazabilidad de nivel alto, el ENS añade otra pieza en el marco de protección: la medida mp.info.4 (sellos de tiempo), que también se aplica «por trazabilidad» y solo en nivel alto, exige aplicar sellos de tiempo a la información susceptible de usarse como evidencia electrónica, empleando sellos cualificados conforme al Reglamento (UE) n.º 910/2014. Es decir: en nivel alto no basta con que el log tenga fecha y hora; la información con valor probatorio necesita fechado cualificado.

Registro de actividad y protección de datos: el equilibrio con el RGPD

Los registros de actividad contienen identificadores de personas —casi siempre empleados públicos o usuarios— y son, por tanto, un tratamiento de datos personales. Eso no genera ningún conflicto con el ENS, pero sí tres deberes que conviene atar a la vez que la medida:

• Registrar el tratamiento e informar a los afectados de que su actividad en los sistemas queda registrada y con qué finalidad.
• Aplicar minimización: auditar los eventos definidos en la política de seguridad, no capturar indiscriminadamente.
• Alinear el plazo de retención de R3 con el principio de limitación de la conservación, de modo que un mismo plazo quede justificado ante las dos normas.

La relación general entre ambos marcos la trato en cómo encajan ENS y RGPD.

Cómo montarlo en la práctica sin volverse loco

Una implantación razonable, ordenada de menor a mayor nivel:

1. Nivel bajo: activar y homogeneizar los logs nativos (sistemas operativos, aplicaciones, bases de datos) verificando que cada evento recoge los cinco campos de op.exp.8.1; centralizarlos aunque la norma aún no lo exija, porque simplifica todo lo que viene después.
2. Nivel medio: NTP protegido en toda la plataforma (R2); repositorio centralizado con permisos restrictivos y copia de seguridad (R4); calendario de revisiones con evidencia de cada una (R1); y el apartado de eventos auditados y retención redactado en la documentación de seguridad (R3).
3. Nivel alto: SIEM con recolección automática, reglas de correlación y respuesta automática (R5), enlazado con la gestión de incidentes de op.exp.7, porque un evento correlacionado que no desemboca en el procedimiento de incidentes se queda en adorno. La medida hermana op.exp.9 exige además registrar la propia gestión de esos incidentes, y op.mon.1 (detección de intrusión) aporta la otra fuente de alertas que el SIEM debe integrar.

Si el sistema está en manos de un proveedor —nube incluida—, estos requisitos no desaparecen: se trasladan al contrato, y te tocará poder demostrar que el proveedor los cumple para tu sistema.

Errores que se repiten en auditoría

• Logs activados que nadie mira. El refuerzo R1 pide revisión periódica con evidencia; «los tenemos por si acaso» no es cumplimiento.
• Relojes desincronizados entre máquinas, que hacen imposible reconstruir secuencias de eventos y delatan que R2 nunca se implantó.
• Plazo de retención sin documentar o documentado pero incumplido: la doble comprobación (papel y logs reales) es de las primeras que hace un auditor con op.exp.8.
• Administradores que pueden borrar sus propios registros, en contra de R4: la autorización de acceso a los logs debe ser explícita y no coincidir con «todo el que administra».
• Cuentas genéricas compartidas que cumplen los campos del log pero impiden atribuir la acción a una persona, contraviniendo la lógica de op.acc.1.
• Cuentas eliminadas antes que sus logs, rompiendo el «periodo de retención» que la propia norma define para poder resolver un identificador a su titular.

Preguntas frecuentes

Fuentes

• Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Texto consolidado, BOE-A-2022-7191 (Anexo II, apartados 4.3.8 [op.exp.8], 4.3.9 [op.exp.9], 4.2.1 [op.acc.1], 4.7 [op.mon] y 5.7.4 [mp.info.4]; Anexo I, categorías y dimensiones). Consultado el 31 de julio de 2026.
• Real Decreto 3/2010, de 8 de enero (derogado), BOE-A-2010-1330: antigua medida op.exp.10 «Protección de los registros de actividad», hoy integrada como refuerzo R4 de op.exp.8.
• Reglamento (UE) n.º 910/2014 (eIDAS), citado por la medida mp.info.4 del RD 311/2022 para los sellos cualificados de tiempo electrónicos.