La parte cara de ISO 27001 no es la certificación. Es el segundo año.
El proyecto tiene presupuesto, plazo y atención. Después llega el certificado, el equipo se dispersa y doce meses más tarde alguien cae en la cuenta de que la auditoría de seguimiento es dentro de seis semanas y nadie ha recogido nada desde la anterior. Lo que sigue es una carrera: capturas de pantalla, exportaciones de hojas de cálculo, aprobaciones perseguidas y una semana de tiempo de dirección dedicada a demostrar que cosas que fueron ciertas todo el año efectivamente lo fueron.
Esa carrera no es un problema de disciplina. Es un problema de diseño. El sistema se construyó para auditarse una vez.
El patrón que la provoca
La mayoría de la documentación de un SGSI describe los controles en términos de comportamiento humano. «Los derechos de acceso se revisan trimestralmente.» «Los cambios se aprueban antes del despliegue.» «Las copias de seguridad se prueban anualmente.»
Cada una de esas frases es la promesa de que alguien hará algo y después encontrará la manera de demostrarlo. La prueba se fabrica en el momento de la auditoría a partir de sistemas a los que nunca se les pidió conservarla: la captura de un ticket, un CSV exportado, un hilo de correo. Es auténtica y es enormemente cara por control.
La alternativa consiste en enunciar el control como una comprobación que una máquina realiza y registra.
Reformular los controles como comprobaciones
Tomemos tres habituales.
Revisión de accesos. En lugar de «los derechos de acceso se revisan trimestralmente», ejecute una tarea programada que exporte la pertenencia a grupos y las asignaciones de roles privilegiados, abra un ticket por responsable y registre la respuesta. La prueba es la salida de la tarea y los tickets cerrados, con marca de tiempo, generados se acuerde alguien de la auditoría o no.
Aprobación de cambios. En lugar de un comité de cambios y sus actas, exija la aprobación en la pull request, proteja la rama para que no pueda fusionarse sin ella, y genere desde la cadena un registro de despliegue que enlace commit, aprobador, resultado de las pruebas y hora de despliegue. La muestra de diez cambios que pide el auditor pasa a ser una consulta, no una búsqueda.
Prueba de restauración. En lugar de un ejercicio anual recogido en un documento, programe una restauración automatizada en un entorno aislado, verifique los datos restaurados y publique el tiempo de recuperación medido. Su RTO pasa a ser una cifra observada en vez de una esperanza escrita.
En los tres casos el control no se ha debilitado. Se ha vuelto continuo y ha empezado a producir su propio registro.
Cómo se ve en la práctica
La implantación es menos exótica de lo que sugiere el nombre.
Un mapeo de controles a comprobaciones. Una tabla: referencia del control, qué lo prueba, de dónde sale esa prueba, con qué frecuencia y quién es responsable. Construirla con honestidad es el trabajo de verdad, y suele revelar que un tercio de sus controles ya está evidenciado automáticamente sin que nadie se hubiera dado cuenta.
Políticas como código en la cadena de entrega. La infraestructura que incumple una regla hace fallar la pull request. Cifrado en reposo, exposición de red, registro activado, etiquetado de propiedad: son puntos decidibles, y decidirlos antes del despliegue es a la vez más barato y mejor prueba que detectarlos después.
Vigilancia continua de la postura. Herramientas de postura cloud que reportan frente a su marco de controles y no frente al benchmark por defecto del fabricante. La salida no es «142 hallazgos»; es «el control A.8.9 se cumple en 47 de 48 cuentas, con la excepción documentada y fechada».
Un almacén de pruebas con retención. Un lugar donde los artefactos aterrizan automáticamente, con marca de tiempo, conservados durante el periodo que exige la norma. Basta con almacenamiento de objetos con versionado; no hace falta que sea un producto.
Gestión de excepciones dentro del sistema. Todo entorno real tiene excepciones. Un marco de controles sin proceso de excepción produce o pruebas deshonestas o parálisis. Haga explícitas las excepciones: quién aprobó, por qué, hasta cuándo y qué compensa.
Qué no cubre
Ser honesto sobre los límites importa, porque una automatización sobrevendida es la manera de que esto acabe en decepción.
Entre el sesenta y el setenta por ciento de los controles del anexo A en una organización nativa de la nube puede evidenciarse automáticamente. El resto es humano y seguirá siéndolo: diligencia debida de proveedores, revisión por la dirección, formación de concienciación, seguridad física, verificaciones de personal, lecciones aprendidas tras un incidente. Esos necesitan calendario, responsable y documento.
El objetivo no es eliminar la prueba manual. Es dejar de gastar su escaso esfuerzo manual en el sesenta por ciento que una máquina podría haber registrado, para que quede tiempo para el cuarenta por ciento que realmente exige criterio.
El segundo beneficio: todos los demás marcos
Si empujamos este enfoque más de lo que ISO 27001 por sí sola justificaría, es por la reutilización.
Una empresa con un certificado ISO 27001, un informe SOC 2, obligaciones NIS2 y un registro RGPD responde a cuatro conjuntos de preguntas que se solapan en torno al setenta por ciento. Control de accesos, gestión de cambios, registros, copias de seguridad, gestión de proveedores y respuesta a incidentes aparecen en los cuatro, con palabras distintas.
Si la prueba la produce una comprobación y no una persona, añadir el segundo marco cuesta el mapeo y casi nada más. La misma prueba de restauración evidencia el control A.8.13 del anexo A de ISO 27001, los criterios de disponibilidad de SOC 2, la medida de continuidad de NIS2 y su obligación de pruebas de resiliencia de DORA. Producida una vez, archivada una vez, citada cuatro veces.
Ahí está el efecto acumulativo, y por eso tratamos el marco de controles como un artefacto de ingeniería y no como un documento.
Por dónde empezar si ya tiene el certificado
No intente abordar todo el marco. Tome los diez controles que más tiempo de recogida de pruebas le costaron en la última auditoría —su equipo los nombrará sin dudar— y convierta esos. Mida el tiempo ahorrado. Use la medición para financiar los diez siguientes.
Una primera pasada de dos a tres semanas suele convertir los peores casos y reduce la preparación de auditoría de semanas a días. Es un trabajo lo bastante pequeño como para hacerlo entre auditorías, que es justo cuando tiene que hacerse: nadie reconstruye su cadena de pruebas seis semanas antes de una auditoría de seguimiento.
El certificado en la pared es una afirmación sobre cómo opera usted. El cumplimiento como código es lo que mantiene esa afirmación continuamente cierta, a un coste que puede seguir pagando.