Cómo se audita el Anexo A de la ISO 27001

La declaración de aplicabilidad llegó al auditor tres días antes de la etapa 2: noventa y tres controles, noventa y uno marcados como aplicables y noventa y uno marcados como implementados. Los dos excluidos eran los de desarrollo seguro, con la justificación de que la empresa no desarrollaba software. El auditor tomó ocho controles al azar y pidió evidencia. Cinco la tenían. En el de gestión de vulnerabilidades técnicas había una herramienta contratada y ningún registro de qué se hizo con los hallazgos; en el de eliminación segura de medios, un procedimiento firmado y cuatro discos de servidores dados de baja apilados en un rack; en el de acuerdos de confidencialidad, la versión que se firmaba desde 2019, anterior a que la empresa empezara a subcontratar soporte. La conclusión del informe no fue sobre esos tres controles: fue que la declaración de aplicabilidad no reflejaba el estado real del sistema.

Qué es el Anexo A y qué no es

El Anexo A de la ISO/IEC 27001 es una lista de referencia de noventa y tres controles agrupados en cuatro temas: organizacionales, de personas, físicos y tecnológicos. Su función es servir de verificación cruzada para que la organización no pase por alto un control necesario, no imponer una lista obligatoria. La norma es explícita en el orden de las cosas: primero se hace la apreciación de riesgos de seguridad de la información, luego el tratamiento determina qué controles hacen falta, y entonces se compara ese conjunto con el Anexo A para comprobar que no se omitió nada relevante. Los controles pueden diseñarse a medida o tomarse de cualquier otra fuente; el Anexo A es el punto de comparación, no el catálogo del que hay que elegir.

Esa distinción cambia por completo cómo se audita. El auditor de certificación evalúa el sistema de gestión contra las cláusulas 4 a 10 —contexto, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora— y llega a los controles del Anexo A a través de la cláusula 6.1.3, que es la que exige producir la declaración de aplicabilidad. No audita el Anexo A por su cuenta: audita si el conjunto de controles declarado es coherente con los riesgos identificados y si lo declarado como implementado existe en la operación.

La declaración de aplicabilidad es el guion de la auditoría

La declaración de aplicabilidad —la SoA, por sus siglas en inglés— tiene que contener cuatro cosas por cada control: si es necesario, la justificación de por qué se incluye, si está implementado o no, y la justificación de la exclusión cuando se deja fuera. Ese documento es información documentada obligatoria y es el índice que el auditor recorre. De ahí sale la muestra que va a pedir, de ahí sale la comparación contra el informe de apreciación de riesgos y de ahí sale, en buena parte, el plan de la auditoría.

Por eso la SoA no se llena al final del proyecto para tener el entregable. Una declaración que marca todo como aplicable e implementado porque parecía más seguro que justificar exclusiones es la forma más rápida de multiplicar la superficie de auditoría: cada control declarado como implementado es una promesa de evidencia que alguien va a tener que cumplir en sitio.

Qué evidencia se pide por cada tipo de control

• —Organizacionales: política aprobada y comunicada, un dueño asignado, la fecha de la última revisión, y el registro de las decisiones cuando la política se aplicó a un caso concreto. Aquí entran clasificación de la información, gestión de proveedores, continuidad y cumplimiento legal y contractual.
• —De personas: acuerdos de confidencialidad vigentes y firmados por quien corresponde, evidencia de concientización con contenido y asistentes, verificación de antecedentes cuando aplique, y el proceso de baja con la retirada de accesos y activos en la fecha de la salida.
• —Físicos: control de acceso a áreas seguras con registro y revisión de permisos, bitácora de visitantes, protección de equipos, escritorio y pantalla despejados verificados en sitio, y la eliminación o reutilización segura de medios con constancia de qué se destruyó y quién lo hizo.
• —Tecnológicos: gestión de accesos privilegiados con altas y bajas trazables, registro y revisión de eventos, gestión de vulnerabilidades técnicas con el ciclo completo de detección, priorización y remediación, respaldos con prueba de restauración documentada, y gestión de cambios con autorización previa.
• —Los atributos del Anexo A —tipo de control, propiedades de seguridad, conceptos de ciberseguridad, capacidades operativas y dominios— sirven para filtrar y presentar los controles por criterio. No son requisito y el auditor no exige que se usen, pero cuando existen ayudan a planificar la muestra.
• —En todos los casos la evidencia útil es la del periodo, no la del día de la auditoría: un control se demuestra con lo que ocurrió en los últimos meses, no con la captura de pantalla que se generó la noche anterior.

Ningún auditor revisa los noventa y tres controles en una auditoría de certificación. Toma una muestra, y la muestra no es aleatoria: se concentra en los controles asociados a los riesgos altos del informe de apreciación, en los que cambiaron desde la última visita, en los que tuvieron incidentes y en los que la auditoría interna reportó como conformes sin evidencia sólida.

Los tres desajustes que producen hallazgos

El primero es el de la SoA optimista: controles declarados como implementados que en la operación existen a medias. Es el hallazgo más frecuente y el más caro, porque no se resuelve con un documento: hay que implementar el control o corregir la declaración, y corregirla obliga a revisar el tratamiento del riesgo que lo justificaba. El segundo es la exclusión incoherente: un control que se deja fuera con una justificación que el propio análisis de riesgos contradice, típicamente los de desarrollo seguro en empresas que sí desarrollan aunque le llamen configuración, o los de teletrabajo en organizaciones con esquema híbrido.

El tercero es el inverso y pasa más de lo que parece: controles que la empresa opera bien y que no aparecen declarados, porque la SoA se congeló cuando terminó la implementación y desde entonces la organización cambió de proveedor de nube, incorporó autenticación multifactor y montó un centro de operaciones de seguridad. Ahí el hallazgo no es de seguridad, es de control de la información documentada, y arrastra a la cláusula 6.1.3 completa.

Cómo se audita internamente antes de la certificación

La auditoría interna del sistema de gestión de seguridad de la información no tiene que cubrir los noventa y tres controles cada año. Lo que la norma pide es un programa que considere la importancia de los procesos y los resultados de auditorías previas, y en la práctica eso se traduce en un programa plurianual: los controles asociados a riesgos altos y a los usos críticos se auditan cada ciclo, el resto se distribuye a lo largo de los tres años del certificado, y cualquier control que haya tenido un incidente o un cambio relevante entra en la siguiente auditoría sin esperar su turno.

Los criterios de esa auditoría tampoco son la norma sola. Son la declaración de aplicabilidad, las políticas internas, los requisitos legales y contractuales aplicables —protección de datos personales, cláusulas de seguridad de los clientes, requisitos sectoriales— y los acuerdos de nivel de servicio con los proveedores de tecnología. Y exige competencia técnica del auditor: un auditor que domina la estructura de la norma pero no distingue un registro de eventos de un respaldo va a declarar conforme cualquier cosa que le muestren.

Dónde se rompe en la operación

El problema rara vez es la falta de controles: es que el programa de auditoría vive en una hoja de cálculo, la declaración de aplicabilidad en otra, los hallazgos de la auditoría interna en un informe de Word y la evidencia de cada control en la carpeta del área que lo opera. Cuando el organismo pide la trazabilidad completa —riesgo, control declarado, auditoría que lo cubrió, hallazgo, acción y verificación— reconstruirla toma más tiempo que la auditoría misma. Un Software para auditorías internas y externas mantiene el programa plurianual, el alcance y los criterios de cada auditoría, la muestra de controles cubierta en cada una y los hallazgos con su seguimiento en el mismo expediente, de forma que la cobertura del Anexo A a lo largo del ciclo se demuestre con un reporte y no con memoria.

En resumen

El Anexo A no se audita como una lista: se audita a través de la declaración de aplicabilidad, que es donde la organización declara qué controles necesita, por qué, cuáles implementó y por qué excluyó los demás. El auditor toma de ahí su muestra, la concentra en los riesgos altos y en lo que cambió, y busca evidencia del periodo, no del día. Los tres hallazgos típicos son la SoA que declara más de lo que existe, la exclusión que el análisis de riesgos contradice y el control que opera sin estar declarado. Mantener esa declaración viva y auditarla por partes a lo largo del ciclo es lo que convierte la auditoría de certificación en una verificación y no en un descubrimiento.