Qué es evidencia válida en una auditoría de seguridad

Todo el mundo sabe que una auditoría se gana con evidencias. Casi nadie define qué convierte un fichero en evidencia y qué lo deja en simple afirmación. La consecuencia es la carpeta compartida de 400 capturas de pantalla que nadie puede usar cuando llega el momento.

Una evidencia es válida cuando un tercero que no estuvo allí puede responder cuatro preguntas sin preguntarte a ti: de dónde salió, cuándo, si ha cambiado desde entonces y qué parte del sistema cubre. Si falla una sola, deja de ser evidencia.

Origen: qué sistema lo produjo y cómo

«Una captura del panel de control» no tiene origen. Una exportación CSV del panel de control, generada por una cuenta identificada, desde una consulta que se puede volver a ejecutar, sí lo tiene.

La diferencia práctica es que la segunda se puede reproducir. Cuando el auditor duda, el recurso no es discutir: es volver a ejecutar la misma consulta delante de él y comparar. Por eso conviene guardar, junto al resultado, el comando o la consulta que lo generó. Una línea de aws iam list-users --output json vale más que la captura del listado de usuarios, porque cualquiera puede repetirla.

Esto tiene un corolario incómodo: la evidencia generada manualmente por la persona que también es responsable del control es la más débil de todas. No porque se presuma mala fe, sino porque no hay forma de distinguirla de una edición. Cuando puedas, que la evidencia la produzca un sistema distinto del que audita el control.

Fecha: la del hecho, no la del fichero

La fecha de modificación de un PDF no es la fecha del hecho. La fecha del hecho es la que aparece dentro de la evidencia: la marca de tiempo del registro, la fecha de la firma, la hora del acta.

El problema típico aparece en las evidencias de periodicidad. Si tu control dice «revisión trimestral de accesos», el auditor no quiere ver la última revisión: quiere ver las cuatro del año, con sus cuatro fechas, y comprobar que la distancia entre ellas es razonablemente trimestral. Tres revisiones hechas la misma semana de diciembre no evidencian un control trimestral, evidencian un control anual con mala conciencia.

Las evidencias de un hecho puntual —una notificación de incidente, una aprobación del consejo— necesitan además fecha y hora cuando hay un plazo regulatorio detrás. El artículo 23 de la NIS2 cuenta en horas; una evidencia fechada sólo con el día es inútil para demostrar que se cumplió el plazo de 24 horas.

Integridad: que se note si alguien la ha tocado

La integridad no exige criptografía en todos los casos, exige proporcionalidad. Para la mayoría de los controles basta con que el fichero viva en un sistema con registro de accesos y versiones, y que no haya pasado por el escritorio de nadie. Para las evidencias que pueden acabar en un procedimiento —expedientes de incidentes, informes de auditoría, aceptaciones formales de riesgo— conviene subir el listón: hash publicado, firma electrónica, o almacenamiento en un repositorio de sólo escritura.

La regla útil es preguntarse qué pasaría si alguien alegara que la evidencia se fabricó después del hecho. Si la única respuesta posible es «confía en mí», la evidencia es débil.

Alcance: qué parte del sistema cubre, y cuál no

Es el fallo más frecuente y el más caro. Una evidencia perfecta de un control aplicado a un subconjunto del entorno prueba exactamente eso: el subconjunto.

Ejemplo real y repetido: se aporta como evidencia de gestión de parches un informe del servidor de actualizaciones que muestra un 98 % de cumplimiento. El auditor pregunta sobre cuántos equipos se calcula ese porcentaje. Resulta que sobre los equipos que reportan al servidor, y hay ciento veinte que no reportan. El control real no es del 98 %, es del 98 % de una población que no está definida.

Toda evidencia cuantitativa necesita declarar su denominador, y toda evidencia de configuración necesita declarar su inventario de referencia. Si no puedes decir sobre cuántos activos se calculó, no has aportado una métrica: has aportado un número.

Lo que casi nunca vale por sí solo

Hay cuatro clases de artefactos que se presentan constantemente como evidencia y que, solos, no sostienen nada:

• La política. Demuestra intención, no ejecución. Un auditor la usa para saber qué debería estar pasando, y después busca la prueba de que pasa.
• La captura de pantalla sin contexto. Sin URL, sin reloj, sin usuario autenticado, sólo demuestra que existe una pantalla con ese aspecto.
• El correo electrónico. Demuestra que alguien dijo algo. Sirve como evidencia de comunicación o de aprobación si conserva cabeceras y fecha, pero no como evidencia de que la acción se ejecutó.
• El cuestionario del proveedor. Demuestra qué declaró el proveedor. Nada más. Es el punto de partida de la evaluación, no su resultado.

Ninguno es inútil: todos son válidos como una pieza de un conjunto. El error es presentarlos como la pieza única.

Evidencia negativa: demostrar que algo no ocurrió

Algunas obligaciones exigen probar una ausencia, y eso es mucho más difícil. «No se produjo ningún acceso no autorizado» o «ningún incidente alcanzó el umbral de notificación» no se demuestran con la falta de registros.

Se demuestran con el registro de que la comprobación se hizo: la consulta ejecutada, el periodo cubierto, el criterio aplicado y el resultado vacío, todo ello fechado. Y con la prueba de que el sistema de detección estaba operativo durante ese periodo, porque un silencio con el sensor apagado no es un silencio.

Cómo montar el expediente para que se pueda auditar

Tres prácticas evitan la mayoría del dolor:

1. Una evidencia, un control, un periodo. Los ficheros que sirven para varios controles acaban archivados en un sitio y buscados en otro.
2. El nombre del fichero dice control, periodo y sistema de origen. AC-03_2026-Q2_okta-export.csv se encuentra dentro de dos años; evidencias_finales_v3.zip no.
3. Un índice que enfrente obligación, control, evidencia y fecha. Es el documento que el auditor pide primero y el que decide si la revisión dura dos días o dos semanas.

La parte tediosa de todo esto es que la evidencia se degrada sola: caduca, se queda sin denominador, pierde el enlace con el control que justificaba. Por eso merece la pena que el sistema que gestiona los hallazgos sea el mismo que retiene sus evidencias con fecha y alcance —es la decisión de diseño sobre la que construimos Violet Security— en lugar de una carpeta que alguien tendrá que reconstruir la semana antes de la auditoría.