El 21 de octubre, cuando PHP2Shell se hizo público, el equipo de inteligencia de amenazas de Amazon publicó una línea que todo responsable de respuesta a incidentes debería haber leído dos veces: investigar desde al menos el 17 de octubre. Cuatro días antes de la divulgación.
La pregunta para su equipo es la siguiente. ¿Conservan todavía los registros del servidor web del 17 de octubre?
Si rotan cada siete días, la respuesta honesta a "¿nos afectó antes de que nadie lo supiera?" es "nunca lo sabremos".
Ahora pregunten a su DPO cuánto tiempo deben conservar esos registros. La respuesta es distinta. Están llenos de direcciones IP, identificadores de usuario, datos de sesión y a veces cuerpos de solicitud completos. Datos personales, conservados con una finalidad de seguridad que nadie documentó, durante un período que nadie eligió.
Los mismos registros, dos personas, dos temores. Ambos legítimos.
Dos dogmas en la misma mesa
El dogma de seguridad: registrar todo, conservarlo indefinidamente, el almacenamiento es barato y nunca se sabe. Nace de una herida real. Todo responsable de respuesta a incidentes ha llegado al punto muerto en que el rastro se corta porque los registros rotaron la semana anterior.
El dogma de privacidad: registrar lo mínimo posible, durante el menor tiempo posible. También una herida real. Un almacén de registros que lo guarda todo sobre todos de forma indefinida se convierte en una base de datos de vigilancia y en uno de los objetivos más atractivos de la organización. La CNIL nombró ese riesgo exacto en su propia guía: volúmenes de datos de registro suficientemente grandes como para ser atacados o utilizados con finalidades que nadie previó.
Cada parte tiene razón en cuanto a su propio riesgo. Ninguna de las dos funciona como criterio por defecto. "Indefinidamente" no es un período de conservación, y "el menor tiempo posible" tampoco lo es.
Anécdota: En la práctica, rara vez hay una segunda persona en esa mesa. En las auditorías ISO 27001 que realizo, el DPO casi nunca es consultado sobre los registros. Me sorprende cada vez, y es una de las no conformidades menores que señalo con más frecuencia. El equipo de seguridad elige un período de conservación, la herramienta lo aplica, y la persona cuyo trabajo consiste en preguntar "¿por qué conservamos esto?" se entera durante la auditoría. El artículo 38 del GDPR ya exige que el DPO sea consultado, de forma adecuada y en tiempo oportuno, en todas las cuestiones relacionadas con datos personales. Los registros son una de ellas.
Lo que dicen realmente los textos
Aquí está lo que rompe el punto muerto. Ninguna regulación ofrece un número universal. Y todas exigen lo mismo.
El GDPR exige minimización de datos y limitación del plazo de conservación. También requiere seguridad apropiada en virtud del artículo 32, y el Considerando 49 reconoce como interés legítimo el tratamiento estrictamente necesario y proporcionado para la seguridad de las redes y de la información. Por tanto, el registro es lícito. El problema surge cuando se registra sin una finalidad definida.
La recomendación de la CNIL de 2021, una de las guías regulatorias más detalladas sobre el tema, establece de seis meses a un año para los registros de aplicaciones que trazan quién accedió y modificó qué. Un período mayor es posible con justificación, hasta tres años en los casos habituales. Cuando los datos subyacentes se conservan menos de seis meses, los registros no deberían contener esos datos personales en absoluto. Y deja explícitamente fuera de su ámbito los registros perimetrales, procedentes de cortafuegos y equipos de red. Casi todo el que cita "seis meses" pasa por alto esa parte.
El Reglamento de Ejecución NIS2 2024/2690, para los proveedores de infraestructuras y servicios digitales que cubre, exige una lista de activos a registrar basada en el riesgo, revisión periódica, protección frente a manipulaciones y conservación durante un período predefinido. Sin mínimo. La guía de implementación de ENISA añade dos indicaciones: eliminar al finalizar el período de conservación y no mantener en los registros datos cuyo propio plazo de conservación haya expirado.
Léanlo de nuevo. El regulador de seguridad dice lo mismo que el regulador de privacidad.
El AI Act establece un mínimo en lugar de un máximo. Los responsables del despliegue de sistemas de alto riesgo deberán conservar los registros que generen esos sistemas durante al menos seis meses.
PCI DSS exige doce meses de historial, tres de ellos disponibles de inmediato. Un número contractual, no legal.
Cinco fuentes, cinco respuestas, una exigencia común: un período definido, vinculado a una finalidad, documentado por escrito.
Decidir por finalidad
El error habitual es fijar la conservación por herramienta. "El SIEM conserva 90 días" es una decisión de licencia disfrazada de decisión de seguridad.
Fíjenla por finalidad.
La detección necesita datos recientes y consultables. Semanas, en capa caliente.
La investigación necesita suficiente historial para cubrir el tiempo que realistamente se tarda en detectar un compromiso, más la ventana de explotación previa a la divulgación que PHP2Shell acaba de demostrar. Una detección lenta implica una conservación prolongada. Ese es el intercambio honesto.
La rendición de cuentas sobre accesos privilegiados necesita un rastro más largo, porque "quién hizo esto y estaba autorizado?" suele plantearse meses después.
Las obligaciones legales y contractuales fijan su propio mínimo. Se siguen.
Un registro puede servir a varios fines. Su conservación se fija por la finalidad más exigente que se pueda justificar realmente, no por la que se desearía tener.
Tres palancas que disuelven la mayor parte del conflicto
La conservación es un ajuste entre varios. La mayor parte del conflicto desaparece en cuanto se usan los otros dos.
Contenido. Registrar el evento, omitir el dato. Quién, qué acción, cuándo, qué referencia de registro. Omitir el registro en sí, el cuerpo de la solicitud, el campo de formulario en el que alguien escribió una contraseña por error. Los registros detallados y de depuración son donde los datos personales se filtran a lugares que nadie gobierna; asígneles una vida de días.
Capas. Una capa caliente breve para detección. Una capa fría más larga para investigación, cifrada y de acceso restringido. Un archivo acotado para los rastros cuya conservación prolongada se haya justificado. En cada nivel inferior, menos personas pueden consultarlo.
Acceso. El almacén de registros puede ser perfectamente el registro más completo de actividad personal de la organización. Trátelo como tal. Roles nominales, acceso a los propios registros registrado, y administradores que no puedan editar en silencio su propio rastro.
Y una barrera de seguridad. Un registro de seguridad se recopila para fines de seguridad. El día en que se utiliza en un conflicto laboral sin una base jurídica separada y la transparencia adecuada, se ha cambiado su finalidad; y en varios países eso también implica al comité de empresa.
Ejemplo de tabla de conservación
Adáptenla a su evaluación de riesgos y a su legislación nacional. Es un punto de partida y muestra el razonamiento que deberán documentar.
| Tipo de registro | Finalidad | Conservación orientativa | Justificación |
|---|---|---|---|
| Cortafuegos, proxy, DNS, VPN | Detección, investigación | 12 meses, 90 días en capa caliente | Cubre ventanas de detección tardía y explotación previa a la divulgación |
| Autenticación (SSO, directorio, MFA) | Detección, investigación de compromisos | 12 meses | El compromiso de cuentas rara vez se manifiesta el primer día |
| Acciones privilegiadas y de administración | Rendición de cuentas, control interno | Hasta 3 años, acceso restringido | Necesidad de control interno documentada, dentro del límite máximo de la CNIL |
| Acceso de aplicaciones a datos personales | Trazabilidad | 6 a 12 meses | Rango de referencia de la CNIL |
| Aplicaciones con datos de vida corta | Trazabilidad | 6 a 12 meses, sin los datos personales en sí | Los registros no deben sobrevivir a los datos que describen |
| Registros de depuración y detallados de aplicaciones | Resolución de incidencias | Días a semanas | Sin finalidad más allá de corregir el error |
| Entorno de tarjetas de pago | PCI DSS | 12 meses, 3 en línea | Requisito contractual |
Documentar la decisión
Sobre el control A.8.15, el auditor preguntará cuánto tiempo se conservan los registros. Los mejores también preguntan por qué.
La respuesta debe existir antes de que llegue la pregunta. Una política de registro con la tabla de conservación y su justificación. Una evaluación de interés legítimo para el propio registro. El registro incluido en el inventario de actividades de tratamiento, porque es una actividad de tratamiento. La opinión del DPO en el expediente. Un responsable nominado. Una fecha de revisión.
Ese conjunto de documentos es lo que transforma un dogma en una decisión. Seguridad obtiene el rastro que necesita. Privacidad obtiene una finalidad, un límite y una fecha de eliminación. Y cuando alguien cuestiona cualquiera de los dos lados, hay una firma al pie.
Reflexión final
El conflicto entre "conservar todo" y "no conservar nada" suele resolverlo quien argumente más alto, y el período de conservación acaba siendo el que venía configurado en la herramienta.
Ninguno de los dos marcos regulatorios permite salir tan fácilmente. Ambos quieren ver que alguien analizó la finalidad, eligió un número y documentó el motivo.
Lleva una tarde. Evita dos conversaciones: explicar a una empresa de respuesta a incidentes que los registros necesarios se eliminaron por defecto, y explicar a una autoridad de protección de datos por qué se conservaron siete años de todo.
Ambas vertientes de esto se abordan en dos de nuestros cursos. ISO 27001 Lead Implementer cubre el registro y la monitorización como controles que se pueden evidenciar en auditoría. ISO 27701 Lead Implementer cubre el lado de la privacidad: finalidad, conservación y los registros que las justifican.