Las evidencias son lo que convierte tu sistema de gestión de seguridad en algo que un auditor puede verificar. Sin ellas, una política aprobada o un control bien diseñado no cuentan para la certificación.
El problema es que suelen estar repartidas entre herramientas, carpetas y correos, y reunirlas a última hora es una de las tareas que más tiempo consume en cualquier auditoría ISO 27001.
En este artículo encontrarás qué evidencias pide el auditor, cómo distingue entre una evidencia válida y una que no lo es, la lista por cláusula y por control del Anexo A y los pasos para tenerlas preparadas.
¿Qué son las evidencias en ISO 27001?
Una evidencia es cualquier información verificable que demuestra que tu sistema de gestión de seguridad de la información (SGSI) funciona tal y como lo has descrito. Si tu política dice que los portátiles van cifrados, la evidencia es el informe que muestra qué equipos están cifrados y desde cuándo.
La norma habla de información documentada y distingue dos tipos.
- Información que se mantiene: son los documentos que describen cómo funciona el sistema, como la política de seguridad, el alcance o los procedimientos. Se actualizan cuando algo cambia.
- Información que se conserva: son los registros que prueban lo que ha pasado, como un informe de auditoría interna, un ticket de baja o un log de accesos. No se modifican, se guardan.
Con los documentos demuestras que has diseñado el sistema. Con los registros demuestras que lo aplicas. El auditor necesita las dos cosas, y es en los registros donde suelen aparecer los huecos.
Si has llegado buscando el control 5.28 del Anexo A, conviene aclarar la diferencia. Ese control se llama «Recopilación de evidencias» y trata algo más concreto. Exige un procedimiento para identificar, recoger y preservar pruebas tras un incidente de seguridad, de forma que tengan validez en un proceso disciplinario o judicial. Es un requisito dentro de la gestión de incidentes, distinto de las evidencias que revisa el auditor para certificarte.
¿Qué tipos de evidencias revisa el auditor?
La auditoría de certificación tiene dos fases. En la fase 1 el auditor revisa la documentación del SGSI y comprueba que estás preparado. En la fase 2 verifica que lo documentado se aplica en el día a día. Para hacerlo combina cuatro tipos de evidencia.
| Tipo de evidencia | En qué consiste | Ejemplo |
|---|---|---|
| Documental | Políticas, procedimientos, actas y planes aprobados | Política de control de accesos firmada por la dirección |
| Registros técnicos | Exportaciones, logs e informes generados por los sistemas | Informe de parches pendientes por dispositivo |
| Entrevistas | Preguntas a las personas responsables de cada proceso | Preguntar al equipo de IT qué hace cuando alguien deja la empresa |
| Observación | Comprobación directa de cómo se ejecuta un control | Pedir que muestren en pantalla la configuración de bloqueo de un equipo |
El auditor no revisa todo, sino que trabaja con muestras. Elige tres bajas del último trimestre, cinco portátiles al azar o un incidente concreto, y sigue el rastro de principio a fin. Si una sola muestra no cuadra con lo que dice la política, tienes un hallazgo.
Por eso no basta con que la evidencia exista. Para que el auditor la dé por buena tiene que cumplir varias condiciones.
- Fechada: una captura sin fecha no demuestra que el control funcionara durante el periodo auditado.
- Dentro del alcance: tiene que corresponder a los sistemas, sedes y procesos incluidos en el SGSI.
- Trazable: debe quedar claro quién la generó, quién aprobó la acción y a qué control responde.
- Coherente con la política: si la política dice que las revisiones de accesos son trimestrales, el auditor esperará cuatro revisiones al año.
- Auténtica: generada en su momento y sin modificar. Un registro creado a posteriori es peor que no tenerlo.
Lista de evidencias ISO 27001
La lista se divide en dos bloques. Las evidencias del SGSI responden a las cláusulas 4 a 10 y son obligatorias para cualquier empresa. Las evidencias de los controles del Anexo A dependen de los controles que hayas declarado aplicables en tu declaración de aplicabilidad.
1. Evidencias del SGSI
Son las que demuestran que el sistema de gestión existe, tiene dueño y se revisa. Ninguna herramienta técnica las genera por ti, así que conviene tenerlas localizadas desde el principio.
| Cláusula | Qué demuestra | Evidencia habitual |
|---|---|---|
| 4.3 Alcance | Qué cubre el SGSI y qué queda fuera | Documento de alcance aprobado, con sedes, procesos, sistemas e interfaces |
| 5.2 Política | El compromiso de la dirección | Política de seguridad de la información firmada y comunicada a la plantilla |
| 5.3 Roles | Quién es responsable de qué | Organigrama de seguridad o matriz de responsabilidades |
| 6.1.2 Evaluación de riesgos | Cómo identificas y valoras los riesgos | Metodología documentada y resultados del último análisis de riesgos |
| 6.1.3 Tratamiento de riesgos | Qué decides hacer con cada riesgo | Plan de tratamiento, declaración de aplicabilidad y aceptación del riesgo residual por sus propietarios |
| 6.2 Objetivos | Qué quieres conseguir y cómo lo mides | Objetivos de seguridad con responsable, plazo e indicador |
| 7.2 Competencia | Que las personas clave están preparadas | Certificados, registros de formación y descripciones de puesto |
| 7.3 Concienciación | Que la plantilla conoce la política | Registros de asistencia y resultados de las formaciones |
| 8.1 Control operacional | Que los procesos se ejecutan como se planificaron | Registros de cambios, tickets y planes de acción |
| 9.1 Seguimiento y medición | Que mides el rendimiento del SGSI | Cuadro de indicadores con resultados por periodo |
| 9.2 Auditoría interna | Que revisas el sistema antes que nadie | Programa de auditoría, informe de la última auditoría interna y hallazgos |
| 9.3 Revisión por la dirección | Que la dirección supervisa el sistema | Acta de la última revisión con decisiones y acciones acordadas |
| 10.2 No conformidades | Que corriges lo que falla | Registro de no conformidades con análisis de causa, acción correctiva y verificación de eficacia |
La revisión por la dirección y la auditoría interna son las dos evidencias que más se olvidan en una primera certificación. Las dos tienen que haberse hecho antes de la fase 2, con tiempo suficiente para cerrar los hallazgos.
2. Evidencias de los controles del Anexo A
El Anexo A de la ISO/IEC 27001:2022 recoge 93 controles repartidos en cuatro bloques. No todos aplican a todas las empresas, pero cada control que declares aplicable necesita al menos una evidencia de que funciona. Estas son las más habituales en una auditoría.
Controles organizativos
| Control | Evidencia que suele pedir el auditor |
|---|---|
| 5.9 Inventario de activos | Inventario actualizado con propietario asignado a cada activo y fecha de la última revisión |
| 5.10 Uso aceptable | Normas de uso aceptable y registro de su aceptación por la plantilla |
| 5.11 Devolución de activos | Registro de devolución de equipos de las últimas bajas |
| 5.15 a 5.18 Control de accesos | Política de accesos, solicitudes aprobadas, revisiones periódicas de permisos y retirada de accesos en las bajas |
| 5.19 a 5.22 Proveedores | Registro de proveedores críticos, cláusulas de seguridad en contratos y evaluaciones periódicas |
| 5.23 Servicios en la nube | Listado de servicios cloud en uso, responsable de cada uno y criterios de selección |
| 5.24 a 5.27 Incidentes | Procedimiento de gestión de incidentes, registro de incidentes con cronología y lecciones aprendidas |
| 5.29 y 5.30 Continuidad | Plan de continuidad y registro de la última prueba realizada |
Controles de personas
| Control | Evidencia que suele pedir el auditor |
|---|---|
| 6.1 Comprobación de antecedentes | Procedimiento de verificación en la contratación y registros de su aplicación |
| 6.2 Condiciones de contratación | Contratos o anexos con obligaciones de seguridad y confidencialidad firmados |
| 6.3 Formación y concienciación | Plan de formación, asistencia y resultados por empleado |
| 6.5 Responsabilidades tras la baja | Checklist de offboarding completado en las bajas recientes |
| 6.7 Teletrabajo | Política de teletrabajo y configuración de seguridad de los equipos remotos |
Controles físicos
| Control | Evidencia que suele pedir el auditor |
|---|---|
| 7.1 y 7.2 Perímetro y acceso físico | Registro de accesos a oficinas o zonas restringidas |
| 7.9 Activos fuera de las instalaciones | Listado de equipos asignados fuera de la oficina y medidas aplicadas, como el cifrado o el bloqueo remoto |
| 7.10 Soportes de almacenamiento | Política de uso de soportes extraíbles y su aplicación técnica |
| 7.14 Eliminación o reutilización de equipos | Registro de borrado seguro o certificado de destrucción de los equipos retirados |
Controles tecnológicos
| Control | Evidencia que suele pedir el auditor |
|---|---|
| 8.1 Dispositivos de usuario final | Estado de cumplimiento de cada dispositivo con las políticas de seguridad, como bloqueo de pantalla, contraseña o versión del sistema operativo |
| 8.2 Accesos privilegiados | Listado de cuentas con privilegios de administrador y su justificación |
| 8.5 Autenticación segura | Configuración de la autenticación multifactor y sistemas donde se aplica |
| 8.7 Protección contra malware | Cobertura de la solución antimalware o EDR por dispositivo y registro de alertas |
| 8.8 Vulnerabilidades técnicas | Informe de parches aplicados y pendientes, con fechas |
| 8.9 Gestión de la configuración | Configuraciones base aprobadas y comprobación de que los equipos las cumplen |
| 8.10 Eliminación de información | Registros de borrado de datos en equipos retirados o reasignados |
| 8.13 Copias de seguridad | Política de copias, registro de ejecución y prueba de restauración |
| 8.15 Registro de eventos | Logs de los sistemas críticos y periodo de retención |
| 8.24 Uso de criptografía | Estado de cifrado de discos por dispositivo y gestión de las claves de recuperación |
| 8.32 Gestión de cambios | Registro de cambios con evaluación, aprobación y pruebas |
Si quieres repasar el contenido de cada bloque antes de construir tu propia lista, en el artículo sobre los dominios de la ISO 27001 tienes el detalle de cada uno.
¿Cómo recopilar las evidencias para la auditoría?
Las empresas que pasan la auditoría sin sobresaltos tienen algo en común. Deciden qué evidencia corresponde a cada control mucho antes de que el auditor la pida. Estos son los pasos para conseguirlo.
1. Parte de la declaración de aplicabilidad
La declaración de aplicabilidad (SoA) recoge los controles del Anexo A que has decidido aplicar y el motivo de cada decisión. Es el mejor punto de partida porque te dice exactamente qué tendrás que demostrar.
Recorre la SoA control por control y anota al lado qué evidencia prueba que funciona. Si un control aplicable no tiene ninguna evidencia asociada, ya sabes dónde está tu primer hueco. Y si declaras un control como implantado pero no puedes enseñar nada que lo respalde, el auditor lo detectará en la fase 2.
2. Asigna un responsable y una frecuencia a cada evidencia
Una evidencia sin dueño acaba sin actualizar. Cada evidencia necesita una persona que la genere y otra que la revise, y una frecuencia acorde con lo que dice tu política.
Algunas evidencias se producen una vez al año, como la revisión por la dirección. Otras cambian cada semana, como el estado de los parches. Reunir toda esta información en un mapa de evidencias te da una visión rápida de qué está cubierto y qué no. Puede ser tan sencillo como algo similar a esto:
| Control | Evidencia | Fuente | Responsable | Frecuencia |
|---|---|---|---|---|
| 5.9 | Inventario de activos con propietario | Herramienta de gestión de activos | Responsable de IT | Continua, revisión trimestral |
| 5.18 | Revisión de permisos | Directorio y aplicaciones SaaS | Responsables de área | Trimestral |
| 8.8 | Informe de parches | MDM | Responsable de IT | Mensual |
| 9.3 | Acta de revisión por la dirección | Documento interno | Responsable de seguridad | Anual |
3. Centraliza y automatiza las evidencias
Cuando las evidencias están repartidas entre el correo, carpetas personales y varias herramientas, encontrarlas lleva horas. Y si la persona que sabe dónde está todo no está disponible el día de la auditoría, el problema se complica.
Guárdalas en un único repositorio, con una carpeta por cláusula o por control y la fecha en el nombre de cada archivo. Limita el acceso a quien lo necesite, porque muchas contienen información sensible.
Para las evidencias técnicas, como el inventario de activos, el cifrado de los equipos o los parches, lo mejor es que salgan directamente de tus herramientas de gestión de dispositivos. Una exportación manual se queda desactualizada en pocas semanas, mientras que un informe automático siempre refleja la situación real y lleva su fecha.
4. Haz un simulacro con casos reales
Antes de la fase 2, ponte en el lugar del auditor. Elige una incorporación reciente, una baja del último trimestre y un portátil al azar, y comprueba que puedes reconstruir toda la cadena de cada caso.
En una baja, por ejemplo, tendrías que poder enseñar la comunicación de RRHH, la retirada de los accesos, la devolución del equipo y el borrado de los datos, todo con sus fechas. Si alguno de esos pasos falta o no cuadra con lo que dice la política, mejor descubrirlo ahora. Lo que no encuentres tú tampoco lo encontrará el auditor.
5. Mantén las evidencias entre auditorías
La certificación tiene una validez de tres años, con una auditoría de seguimiento cada año y una recertificación al final del ciclo. El auditor revisará evidencias del periodo transcurrido desde la última visita, no solo del mes anterior.
Si las evidencias solo se generan cuando se acerca la auditoría, cada seguimiento vuelve a ser una carrera. Las que se producen de forma continua, con responsables y frecuencias claras, eliminan ese problema y hacen que el sistema funcione también el resto del año.
Errores habituales con las evidencias
La mayoría de las no conformidades que aparecen en una auditoría tienen poco que ver con controles que no existen. Suelen deberse a controles que existen pero no se pueden demostrar. Estos son los errores más frecuentes:
- Capturas de pantalla sin contexto: una imagen que muestra «cifrado activado» no dice en qué equipo, en qué fecha ni si se aplica al resto de la flota. Las capturas pueden complementar, pero rara vez bastan por sí solas.
- Evidencias creadas a última hora: un acta de revisión redactada la semana antes de la auditoría o un registro rellenado con fechas pasadas se detectan con facilidad. Además, comprometen la credibilidad del resto del sistema.
- La política dice una cosa y la práctica otra: si la política fija revisiones de accesos trimestrales y solo hay una al año, el auditor levantará una no conformidad aunque la revisión esté bien hecha. Es mejor ajustar la política a una frecuencia realista que incumplirla.
- Evidencias dispersas: aprobaciones en el correo, exportaciones en el portátil de una persona y tickets en tres herramientas distintas. Cuando la persona que sabía dónde estaba todo se va de vacaciones o de la empresa, la evidencia desaparece con ella.
- Activos que no están en el inventario: un portátil que nadie registró o una aplicación SaaS contratada por un departamento sin pasar por IT. Si el activo no está en el inventario, ningún control se le aplica, y el auditor suele encontrarlo al cruzar datos.
- Bajas sin cerrar del todo: la cuenta principal se desactiva, pero el acceso a una herramienta SaaS sigue activo o el portátil no se ha devuelto. Las bajas son de las primeras muestras que pide el auditor porque revelan rápido si los procesos de RRHH e IT están conectados.
¿Cómo Factorial IT te ayuda con las evidencias ISO 27001?
Buena parte de las evidencias del Anexo A son técnicas. Describen el estado de los dispositivos, los accesos y los activos de la empresa en un momento concreto. Recopilarlas a mano obliga a exportar datos de varias herramientas, cruzarlos y repetir el proceso antes de cada auditoría.
Factorial IT genera esas evidencias de forma continua a partir de la gestión diaria de la flota, y cada informe lleva su fecha.
- Inventario de activos siempre actualizado (5.9). Los dispositivos se registran automáticamente con su propietario asignado, para flotas mixtas de macOS, Windows, Linux, iOS y Android. El inventario se puede descargar con fecha y porcentaje de cobertura.
- Estado de seguridad de cada dispositivo (8.1, 8.9 y 8.24). Las políticas de seguridad se aplican desde el MDM y el estado de cumplimiento de cada equipo, incluido el cifrado de disco, queda registrado.
- Parches y vulnerabilidades (8.8). Visibilidad de las actualizaciones aplicadas y pendientes por dispositivo, con su historial.
- Protección contra malware (8.7). El EDR integrado muestra la cobertura por equipo y el registro de alertas y respuestas.
- Bajas conectadas con RRHH (5.11, 6.5 y 7.14). Como Factorial IT está sincronizado con las altas y bajas de Factorial, cada salida activa la retirada de accesos, la devolución del equipo y el borrado remoto. Queda registrado el tiempo entre la baja en RRHH y el corte del último acceso, que es justo la muestra que suele pedir el auditor.
- Aplicaciones SaaS y accesos (5.15 y 5.23). Visibilidad de las aplicaciones en uso, quién tiene acceso a cada una y detección de herramientas que se usan sin pasar por IT.
- Módulo de Compliance. Reúne el estado de estos controles en un solo lugar, para que la preparación de la auditoría consista en revisar y descargar en vez de buscar.
Conviene ser claro sobre el límite. Factorial IT trabaja en la capa técnica del cumplimiento. Las evidencias del SGSI, como el análisis de riesgos, la declaración de aplicabilidad, la auditoría interna o la revisión por la dirección, dependen de tu equipo y de tu proceso de gestión. Ninguna herramienta las sustituye.
Para cubrir esa parte, Factorial ofrece un servicio de certificación ISO 27001 de principio a fin junto a partners especializados, que acompaña a la empresa desde el diagnóstico hasta la auditoría. Y si quieres ver control por control qué evidencia genera la plataforma, lo tienes en detalle en cómo Factorial IT ayuda a cumplir con la ISO 27001.
