Qué evidencias pide el auditor de la ISO 27001 por cláusula, cómo ordenarlas en un índice y cómo las muestrea, con un ejemplo trabajado.
Por Alex Fernández, Auditor Líder ISO/IEC 27001 e ISO/IEC 42001 · Actualizado el
Una evidencia de auditoría es un registro, una declaración de hechos u otra información que se puede verificar y que demuestra que cumples un requisito. En la ISO 27001 sirve para probar que el sistema y sus controles funcionan, no solo que están escritos. La norma exige información documentada concreta en sus cláusulas 4 a 10, y el resto depende de los controles que declares aplicables. Aquí va qué pide el auditor, cómo ordenarlo en un índice que se recorra en una mañana y cómo muestrea, con un ejemplo trabajado.
El proceso completo está en la guía de certificación ISO 27001; esta va a la pieza que más tiempo se come antes de cada auditoría.
Una política dice lo que vas a hacer. Un registro dice lo que hiciste. La auditoría se juega en lo segundo.
La ISO 19011, la guía para auditar sistemas de gestión, define la evidencia de auditoría (apartado 3.9) por dos rasgos: es pertinente para el requisito que se audita y se puede verificar. Lo que no se puede verificar es una opinión, por razonable que sea.
Las certificadoras acreditadas trabajan con la ISO/IEC 17021-1, que en su apartado 9.4.4 les pide obtener la información por muestreo y verificarla, y cita tres métodos. Conviene preparar los tres:
Una evidencia sólida es la que coincide en las tres. Si la política dice que las revisiones son trimestrales, el registro tiene dos al año y el responsable dice «cuando hay tiempo», el auditor tiene un hallazgo, aunque cada pieza por separado parezca correcta.
La ISO/IEC 27001:2022 exige información documentada en estos puntos de las cláusulas 4 a 10. Es el mínimo: si falta una fila, falta un requisito.
| Cláusula | Qué tiene que existir | Qué suele pedir el auditor |
|---|---|---|
| 4.3 | El alcance del sistema | El documento de alcance, que coincida con el del certificado y con la realidad |
| 5.2 | La política de seguridad | La versión aprobada y la prueba de que se comunicó |
| 6.1.2 | El proceso de evaluación de riesgos | La metodología, con los criterios de aceptación |
| 6.1.3 | El proceso de tratamiento y la declaración de aplicabilidad | La declaración vigente y el plan de tratamiento aprobado |
| 6.2 | Los objetivos de seguridad | Objetivos medibles, con responsable, plazo y seguimiento |
| 7.2 | Las pruebas de competencia | Formación, titulación o experiencia de quien tiene un papel en el sistema |
| 8.1 | Lo necesario para confiar en que los procesos se hicieron como se planificó | Registros de operación: cambios, altas y bajas, copias |
| 8.2 y 8.3 | Los resultados de la evaluación y del tratamiento de riesgos | El registro de riesgos fechado y el estado de las acciones |
| 9.1 | Los resultados del seguimiento y la medición | Los indicadores con sus datos, no solo su definición |
| 9.2.2 | El programa de auditoría interna y sus resultados | El programa, los informes y los hallazgos |
| 9.3.3 | Los resultados de la revisión por la dirección | El acta, con las decisiones tomadas |
| 10.2 | Las no conformidades, las acciones y sus resultados | El registro, con la causa, la acción y la verificación de su eficacia |
A eso, la cláusula 7.5.1 b) suma lo que tú decidas necesario para que el sistema sea eficaz, y la 7.5.3 pide controlarlo todo: versiones, acceso, conservación y eliminación.
El Anexo A no trae una lista fija. Depende de los controles que declares aplicables. Algunos piden un documento de forma expresa, como el inventario de activos (5.9), los requisitos legales identificados (5.31) o los procedimientos de operación (5.37); la mayoría se demuestran con registros de que el control funciona. De un control excluido, el auditor pedirá la justificación; de uno aplicable, la evidencia. Cómo se justifica cada fila está en la guía de la declaración de aplicabilidad.
Por cada control aplicable, el auditor busca tres pruebas: el diseño (qué dice el sistema que se hace), la operación (que se hizo, con registros) y la vigilancia (que alguien lo comprueba y actúa cuando falla). Lo cuento con el ejemplo de los accesos en la guía de la auditoría del ENS. Para el índice importa una consecuencia: la evidencia tiene que cubrir el periodo, no el día.
Si un control es trimestral, en un año tiene que haber cuatro registros, no solo el último. En la práctica, la auditoría inicial mira el tiempo que lleva funcionando el sistema, y las de seguimiento, lo ocurrido desde la anterior. Un registro reciente demuestra que el control funciona hoy; la serie, que funciona siempre.
La forma más simple de llegar con todo localizable es un índice: una tabla con una fila por requisito o control y siete columnas.
Y seis reglas para que siga sirviendo:
Empresa ficticia: software en la nube, unas 40 personas, certificada en ISO 27001 desde noviembre de 2025. Su primera auditoría de seguimiento es a mediados de noviembre de 2026, y el 1 de octubre revisa el índice. Ocho filas, sin las columnas de ubicación y dueño:
| Requisito o control | Evidencia | Frecuencia | Última | Estado |
|---|---|---|---|---|
| 4.3 Alcance | Documento de alcance, versión 2, aprobado por la dirección | Cuando cambia | 2 de marzo de 2026 | Al día |
| 6.1.3 Declaración de aplicabilidad | Declaración, versión 4, y plan de tratamiento aprobados | Con cada evaluación de riesgos | 15 de junio de 2026 | Al día |
| 9.2.2 Auditoría interna | Programa e informe de la auditoría interna | Anual | 6 de octubre de 2025 | Por vencer: programada el 20 de octubre |
| 9.3.3 Revisión por la dirección | Acta con decisiones y acciones | Anual | 21 de octubre de 2025 | Por vencer: convocada el 3 de noviembre |
| A.5.18 Derechos de acceso | Revisión de los accesos a producción, con los permisos retirados | Trimestral | 10 de abril de 2026 | Vencida: falta la de julio |
| A.8.13 Copias de seguridad | Acta de la prueba de restauración | Semestral | 12 de septiembre de 2026 | Al día |
| A.8.8 Vulnerabilidades técnicas | Informe mensual de parches y escaneo | Mensual | 30 de septiembre de 2026 | Al día, con tres críticas fuera de plazo |
| A.6.3 Concienciación | Registro de asistencia a la formación anual | Anual | 18 de junio de 2026 | Al día, con cuatro personas pendientes |
La de accesos es la que cae. La frecuencia declarada es trimestral y falta un trimestre. No se arregla haciendo hoy la revisión y fechándola en julio: eso es falsear un registro, y convierte el fallo de un control en una duda sobre todo el sistema. Se arregla haciendo la revisión ya, abriendo una no conformidad interna con su causa (cláusula 10.2) y enseñando las dos cosas al auditor.
La auditoría interna y la revisión por la dirección van en ese orden. La revisión tiene que tratar los resultados de las auditorías (9.3.2), así que la interna va primero, y las dos antes del seguimiento.
La de vulnerabilidades enseña lo contrario. La evidencia está al día y demuestra un problema: tres vulnerabilidades críticas fuera del plazo que la propia empresa se fijó. El índice no lo esconde, ni debe. El auditor querrá ver que alguien lo detectó y decidió qué hacer, y lo mismo vale para las cuatro personas sin formar.
El auditor no revisa todo: elige. Lo habitual es que pida la lista completa del periodo, como las altas y bajas, los cambios en producción o los incidentes, y escoja él las muestras. Por eso la lista tiene que salir del sistema que la genera, no de una hoja preparada para la ocasión.
El día de la auditoría:
Repasar las evidencias con una auditoría interna, antes de que llegue el auditor externo, es lo que cuento en el caso de la auditoría interna hecha en casa.
El mismo índice sirve para otras auditorías, cambiando las filas. Para el ENS, son las medidas del anexo II que te corresponden por categoría, y el recorrido de esa auditoría está en la guía de la auditoría del ENS. Si te audita un cliente, son las preguntas de su cuestionario: cómo contestarlo con evidencia está en la guía del cuestionario de seguridad.
Si prefieres llevar el índice en una herramienta, en Salvik cada evidencia se vincula a su control, con su fecha de caducidad si la tiene, y te avisa 30 días antes de que venza; entra en la prueba de 7 días, con una norma.
Para la primera foto de qué tienes y qué no puedes demostrar, la Checklist NIS2 (16 dominios, 149 controles) comparte buena parte del terreno con el Anexo A. Y si quieres que alguien recorra tu índice con la vara del auditor antes de que llegue el de verdad, la auditoría interna está en los servicios ISO 27001.
Los que exigen las cláusulas 4 a 10: alcance, política, procesos de evaluación y tratamiento de riesgos, declaración de aplicabilidad, objetivos, pruebas de competencia, registros de operación, resultados de riesgos, resultados del seguimiento, programa y resultados de la auditoría interna, resultados de la revisión por la dirección y no conformidades con sus acciones. A eso se suma lo que pidan los controles del Anexo A que declares aplicables.
La norma no fija una. La evidencia tiene que cubrir el periodo auditado y cuadrar con la frecuencia que declaras: si un control es trimestral, tiene que haber un registro por trimestre. Una evidencia antigua no es un problema; una serie con huecos, sí.
Sí, si se pueden verificar: con fecha, con el sistema reconocible y sabiendo quién la hizo. Mejor aún es enseñar el dato en directo en la herramienta, porque el auditor ve el origen y no una copia.
Si no se puede demostrar un requisito, el auditor puede registrar un hallazgo. Si la evidencia existe y no la localizas, dilo y búscala; si no existe, no la fabriques. Un hallazgo con causa y acción se cierra; una evidencia falsa compromete la confianza en todo el sistema.
La ISO 27001 no fija un plazo: la cláusula 7.5.3 pide que decidas cuánto conservas cada cosa y lo controles. Un criterio práctico es guardarlas, como mínimo, hasta que pase la auditoría que pueda pedirlas, teniendo en cuenta que el ciclo de certificación dura tres años y que una ley o un contrato pueden exigirte más.