Anexo A de ISO 27001: cómo hacer operativos los 93 controles

El anexo A ofrece a los equipos de seguridad un conjunto de referencia útil. Su valor operativo procede de demostrar por qué se aplica un control, cómo se implanta y qué evidencias lo respaldan en su entorno. Un registro con 93 indicadores de estado en verde no basta si nadie puede explicar qué sistemas abarcan esos indicadores.

Para un CTO, el reto práctico consiste en traducir la intención de los controles en trabajo de ingeniería y de operaciones sin convertir el sistema de gestión de la seguridad de la información en una burocracia paralela. Las revisiones de accesos deben basarse en datos reales de permisos. Los planes de recuperación deben reflejar las dependencias de los servicios. Las evaluaciones de proveedores deben abordar los servicios que el negocio realmente consume.

Esta guía explica cómo seleccionar los controles, repartir las responsabilidades, definir las implantaciones y poner a prueba las afirmaciones resultantes. Las frecuencias de revisión y los ejemplos de implantación que siguen son recomendaciones prácticas, no intervalos universales prescritos por la norma.

Entienda qué hace el anexo A y qué no hace

ISO/IEC 27001:2022 contiene 93 controles en el anexo A, agrupados en cuatro temas. Los capítulos 4 a 10 contienen los requisitos del sistema de gestión: contexto de la organización, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora. El anexo A ayuda a seleccionar los controles; no sustituye esos requisitos ni su evaluación de riesgos.

La distinción es importante durante la implantación. Una configuración de copias de seguridad puede respaldar un control seleccionado, pero no demuestra que se haya definido el alcance del SGSI, se hayan evaluado los riesgos, se haya realizado una auditoría interna o se haya completado la revisión por la dirección. Son actividades distintas con evidencias distintas.

La selección de controles se basa en el riesgo. Determine los controles necesarios para tratar sus riesgos y compárelos después con el anexo A para comprobar que no se ha omitido ningún control necesario. Pueden ser necesarios controles adicionales que no figuran en el anexo A. A la inversa, es posible una exclusión justificada; ninguna regla obliga a todas las organizaciones a excluir algo ni a implantar exactamente la misma selección.

ISO/IEC 27002:2022 ofrece orientación para la implantación de los controles. Sus atributos ayudan a organizarlos por tipo de control, propiedad de seguridad de la información, concepto de ciberseguridad, capacidad operativa y dominio de seguridad. Son ayudas útiles para filtrar, no listas de comprobación adicionales para la certificación. Consulte las normas con licencia para conocer la redacción oficial.

Utilice los cuatro temas para encontrar a los responsables adecuados

Los temas proporcionan una estructura de navegación, no cuatro líneas de trabajo independientes. Un proceso de baja, por ejemplo, conecta las responsabilidades laborales, la administración de identidades, la devolución de equipos y el acceso a las aplicaciones.

Controles organizacionales: conecte la gobernanza con las decisiones operativas

Estos controles abarcan las políticas, las responsabilidades, la segregación de funciones, los activos, la clasificación y el tratamiento de la información, la gobernanza de los accesos, los proveedores, los incidentes, la continuidad, las obligaciones legales y las actividades de revisión.

Empiece por identificar dónde se toman las decisiones. ¿Quién aprueba un nuevo servicio en la nube? ¿Quién asigna una clasificación a la información? ¿Quién decide si un evento notificado es un incidente? Una política debe hacer que esas decisiones sean repetibles y asignar la autoridad correspondiente, en lugar de limitarse a expresar apoyo a la seguridad.

La seguridad de los proveedores necesita una cadena de evidencias específica para cada servicio: la finalidad de negocio del servicio, la información que trata, los riesgos evaluados, las responsabilidades contractuales y la revisión continua. El informe de aseguramiento de un proveedor puede respaldar esa evaluación, pero su alcance, su periodo y las responsabilidades que asigna al cliente deben corresponderse con el uso que usted hace del servicio.

La gestión de incidentes también necesita algo más que una lista de contactos de emergencia. Defina las vías de notificación, los criterios de evaluación, la autoridad de respuesta, el tratamiento de las evidencias y las actividades de aprendizaje. Registre los ejercicios o las respuestas reales, incluidas las acciones de seguimiento y sus responsables.

Controles de personas: haga que los eventos laborales sean desencadenantes fiables

Los ocho controles de personas abordan la investigación de antecedentes, las condiciones de empleo, la concienciación y la formación, el proceso disciplinario, las responsabilidades tras un cambio laboral, la confidencialidad, el teletrabajo y la notificación de eventos.

Intégrelos en los flujos de trabajo laborales existentes. Una incorporación necesita las obligaciones, los accesos y las instrucciones adecuados. Un cambio de puesto requiere reevaluar los permisos, no solo añadir otros nuevos. Una baja requiere retirar los accesos, devolver los activos y dejar claras las obligaciones de confidencialidad que siguen vigentes.

La responsabilidad suele abarcar varios equipos. RR. HH. puede iniciar una baja, los administradores de identidades desactivan la cuenta central, los responsables de las aplicaciones retiran los accesos gestionados localmente y un mando confirma que se ha completado. Asignar todo el proceso a seguridad oculta esas dependencias.

Entre las evidencias útiles figuran los registros aprobados del flujo de trabajo, la formación completada y el seguimiento de la pendiente, las condiciones aceptadas y una muestra de cambios laborales. Restrinja el acceso a las evidencias sensibles de RR. HH.; quien revisa un control no necesita automáticamente expedientes de personal completos.

Controles físicos: documente su perímetro y el del proveedor

Los controles físicos abordan las instalaciones, la entrada, la monitorización, las amenazas ambientales, las áreas seguras, los puestos de trabajo y las pantallas, los equipos, los soportes, los suministros, el cableado, el mantenimiento y la eliminación.

Una organización que trabaja principalmente en la nube sigue teniendo que considerar la seguridad física. Parte de la implantación puede correr a cargo de un proveedor de servicios en la nube, mientras que el acceso a la oficina y los dispositivos de los empleados siguen siendo responsabilidad propia. Registre ese reparto en lugar de excluir automáticamente todo el tema.

En sus propias ubicaciones, identifique quién puede entrar, cómo se modifican los accesos, dónde se encuentran los equipos sensibles y cómo se gestionan las visitas. Para los dispositivos remotos, defina medidas de almacenamiento, transporte, reparación y eliminación adecuadas a sus riesgos.

Las evidencias pueden incluir registros de autorización de acceso, procedimientos para visitas, inventarios de equipos y registros de eliminación. Las evidencias del proveedor deben explicar qué instalaciones y servicios cubren; no deben tratarse como prueba de los controles de su oficina o de sus portátiles.

Controles tecnológicos: defina la cobertura antes de elegir herramientas

El tema tecnológico abarca los dispositivos finales, los accesos privilegiados, la autenticación, el acceso al código fuente, la capacidad, el malware, las vulnerabilidades, las configuraciones, el tratamiento de datos, las copias de seguridad, la resiliencia, los registros, la monitorización, las redes, la criptografía, el desarrollo y la gestión de cambios.

Empiece por la cobertura de los sistemas. Una política de identidades está incompleta si los accesos a producción, las cuentas de servicio o una aplicación gestionada por separado quedan fuera de su implantación. Una plataforma de registros está incompleta si los eventos críticos nunca llegan a ella o nadie responde a las alertas.

En el desarrollo de software, conecte los requisitos y las decisiones de diseño con la revisión del código, las pruebas de seguridad, la separación de entornos, el tratamiento de los datos de prueba y la aprobación de las versiones. El modelado de amenazas puede ayudar a identificar requisitos de seguridad antes de la implantación. La profundidad de las pruebas debe ajustarse al riesgo y a las obligaciones; ISO 27001 no impone un calendario universal de pruebas de penetración.

En criptografía, distinga los datos en reposo de los datos en tránsito y documente la responsabilidad sobre las claves, el acceso a ellas, su recuperación, su rotación y su revocación. «Cifrado activado» deja sin respuesta preguntas importantes de implantación.

Qué cambió en 2022 y dónde buscar brechas

La edición de 2013 tenía 114 controles en 14 dominios. La edición de 2022 los reorganizó en 93 controles agrupados en cuatro temas, incluidos 11 controles nuevos. Un número menor no significa menos trabajo de seguridad: la consolidación puede reunir varias responsabilidades operativas bajo una sola referencia.

Al actualizar un registro antiguo, conserve las implantaciones y las evidencias subyacentes en lugar de limitarse a sustituir los identificadores. Compruebe si la nueva agrupación cambia la cobertura, los responsables o las pruebas necesarias para respaldar el estado declarado.

El plazo de transición para las certificaciones acreditadas conforme a ISO/IEC 27001:2013 venció el 31 de octubre de 2025. Esos certificados ya no son válidos; actualizar únicamente un registro de controles no acredita la certificación conforme a la edición de 2022.

A continuación se ofrecen puntos de partida prácticos para los 11 controles nuevos, que no reproducen su texto oficial.

Evite tratarlos como once compras automáticas de productos. Por ejemplo, la inteligencia de amenazas necesita análisis y acción, no solo una suscripción a un feed. La eliminación de datos exige conocer las copias, las copias de seguridad y las obligaciones de conservación, no solo un botón de borrar. La monitorización necesita una vía de respuesta operativa.

Registre por separado la aplicabilidad y la implantación

Su Declaración de Aplicabilidad (SoA, por sus siglas en inglés) debe identificar los controles necesarios, explicar por qué se incluyen, registrar si están implantados y justificar las exclusiones de controles del anexo A. Estos requisitos forman parte de las disposiciones sobre tratamiento de riesgos de ISO/IEC 27001.

Utilizar las 93 referencias como índice de revisión es una forma práctica de hacer que la comparación sea verificable. Incluya también cualquier control adicional necesario. La SoA no es el registro de riesgos, el plan de tratamiento ni el repositorio de evidencias, aunque debe conectarse con cada uno de ellos cuando proceda.

Para cada control aplicable, recoja:

• Los riesgos u obligaciones que justifican su inclusión.
• Los sistemas, ubicaciones, información y procesos pertinentes.
• La implantación real y su responsable.
• Las evidencias que la respaldan y su periodo de revisión.
• Las dependencias, excepciones y trabajos pendientes.
• La próxima fecha de revisión o el evento que la desencadena.

Mantenga la aplicabilidad separada del estado de ejecución. «Aplicable, implantado parcialmente» es un registro honesto y útil. «No aplicable porque no hemos comprado una herramienta» no es una justificación de aplicabilidad.

Una exclusión debe describir los hechos del alcance que hacen innecesario el control y seguir siendo coherente con la evaluación de riesgos. «No desarrollamos software» requiere un examen detenido si un contratista desarrolla su portal de clientes. La externalización cambia la vía de implantación y de evidencias; no elimina automáticamente el riesgo.

En las implantaciones distribuidas, registre el reparto. Un control de protección física puede depender de las instalaciones de alojamiento operadas por un proveedor, del acceso a la oficina gestionado por la empresa y del manejo de los dispositivos por parte de los empleados. Un único responsable puede responder de la afirmación conjunta mientras distintos equipos realizan las actividades.

Una declaración de implantación útil es lo bastante concreta como para poder probarse: «Los administradores de producción reciben un acceso nominativo y aprobado a través del servicio de identidad; el acceso de emergencia se registra y revisa por separado». «Los accesos se gestionan de forma segura» no puede orientar ni a un ingeniero ni a un revisor.

Ponga a prueba la afirmación que hay detrás del estado

Una política describe el comportamiento previsto. Puede demostrar el diseño y la aprobación, pero no puede demostrar por sí sola el funcionamiento. Construya una cadena de evidencias que vaya del requisito al mecanismo implantado y, de ahí, a un resultado observado.

En la gestión de accesos, compare las reglas aprobadas con los permisos reales de los usuarios y con los registros de bajas. Incluya, cuando proceda, las identidades privilegiadas, las cuentas no humanas y las aplicaciones que quedan fuera de la gestión centralizada de identidades. Registre la población, la muestra y las excepciones en lugar de presentar una única captura de pantalla conveniente.

En las copias de seguridad, examine la configuración y un resultado de restauración. Una tarea de copia completada demuestra menos que la recuperación satisfactoria de información utilizable. Compruebe los permisos, las dependencias y los objetivos de recuperación; una base de datos restaurada sin sus claves de cifrado puede no restablecer el servicio.

En la seguridad de los proveedores, vincule la evaluación al servicio concreto y a las responsabilidades contractuales. Revise si las evidencias cubren el servicio que utiliza y si se han implantado las responsabilidades identificadas del lado del cliente.

Un registro de prueba práctico debe contener el resultado esperado, el método, el alcance, la fecha de las evidencias, el revisor, el resultado y la decisión de seguimiento. Distinga entre:

• Diseño: el mecanismo propuesto aborda el riesgo identificado.
• Implantación: el mecanismo existe en todo el alcance declarado.
• Funcionamiento: los registros muestran que funciona durante el periodo pertinente.
• Eficacia: las pruebas indican que logra el resultado previsto.

Las evidencias pueden incluir configuraciones, exportaciones, tickets, contratos, entrevistas y observaciones físicas. Seleccione evidencias que respalden la afirmación real. Una exportación de configuración puede mostrar los ajustes actuales; los tickets históricos pueden mostrar si las excepciones se gestionaron a lo largo del tiempo.

Preserve la procedencia: el sistema de origen, la fecha de obtención, el periodo cubierto y cualquier filtrado aplicado. Proteja las evidencias que contengan secretos o información personal mediante restricciones de acceso y la ocultación adecuada de datos. La recopilación de evidencias no debe crear un nuevo repositorio descontrolado de datos sensibles.

Ejemplo práctico: haga verificable un proceso de baja

Considere, a título ilustrativo, una empresa SaaS con 45 empleados, una oficina, alojamiento en la nube, identidades gestionadas de forma centralizada y dos aplicaciones con cuentas locales. Son supuestos del ejemplo, no resultados de clientes de Secani.

El riesgo es que se mantenga el acceso a información de clientes o de la empresa tras la salida de una persona. Entre los controles pertinentes figuran las responsabilidades ante cambios laborales, la gestión de identidades, los derechos de acceso y la devolución de activos. La autenticación técnica y las restricciones de acceso también respaldan la implantación.

La empresa registra el control como aplicable. RR. HH. es responsable del desencadenante de la baja; TI, de las acciones sobre identidades y dispositivos; cada responsable de aplicación, de la eliminación de las cuentas locales. El mando de la persona confirma el momento exigido para la baja. El responsable de seguridad revisa el proceso y las excepciones sin resolver.

La implantación incluye un ticket de baja autorizado, la desactivación programada de la cuenta central, la revocación de sesiones cuando sea posible, la eliminación de las cuentas locales, la devolución de los activos y la comprobación de las credenciales que controlaba la persona. Los secretos compartidos se cambian cuando es necesario; las cuentas personales no se reasignan sin más a un sucesor.

El paquete de evidencias conecta el procedimiento aprobado, el ticket de baja, los registros de acciones sobre las cuentas, las confirmaciones de las aplicaciones locales y el registro de equipos. Cada elemento respalda una parte definida de la afirmación.

Durante una revisión ilustrativa, el equipo examina cuatro bajas. Las cuentas centrales se desactivaron según lo previsto, pero una aplicación local mantuvo el acceso durante dos días. El control no se declara plenamente eficaz basándose únicamente en las evidencias de la identidad central.

El responsable de la aplicación elimina la cuenta, evalúa si se produjo algún acceso y registra el resultado. El equipo añade la aplicación a la lista de comprobación de bajas y asigna un paso de conciliación. La acción de tratamiento recibe un responsable y una fecha límite; una prueba posterior comprueba que el flujo de trabajo revisado funciona.

Este ejemplo muestra por qué las evidencias deben seguir las dependencias. Que cuatro sistemas indiquen «completado» no acredita que el proceso esté completo si un quinto sistema nunca se incluyó.

Mantenga los controles operativos entre revisiones

Los controles cambian cuando cambian los sistemas, los proveedores, las personas y los requisitos del negocio. Establezca desencadenantes de revisión para las versiones importantes, los nuevos servicios, los cambios de oficina, los incidentes y las obligaciones revisadas, además de las revisiones programadas.

Utilice una frecuencia adecuada a la volatilidad y al riesgo. Las excepciones de acceso privilegiado pueden requerir una revisión inmediata, mientras que una política estable puede seguir un ciclo más largo, complementado con desencadenantes por cambios. Son decisiones de la dirección, no frecuencias universales del anexo A.

Haga el seguimiento de un pequeño número de indicadores útiles: correcciones vencidas, sistemas no cubiertos, excepciones de evidencias sin resolver y pruebas de control fallidas. Sepárelos de los recuentos de documentos. Una gran biblioteca de evidencias puede dejar todavía sin probar un entorno de producción crítico.

La auditoría interna proporciona una evaluación independiente del SGSI; las revisiones rutinarias de los responsables de los controles no la sustituyen. La revisión por la dirección necesita igualmente decisiones de la dirección sobre el desempeño, los cambios, los recursos y la mejora, no solo una hoja de cálculo de controles completada. La certificación la realiza un organismo de certificación independiente, no ISO ni un proveedor de software.

Entre los errores habituales figuran asignarlo todo a seguridad, copiar las exclusiones de otra organización, confiar en los certificados de los proveedores sin comprobar su alcance y cerrar hallazgos cuando cambia una política en lugar de cuando se ha probado el proceso revisado.

Empiece con un servicio y una cadena de evidencias completa

Elija un servicio representativo y trace sus sistemas, proveedores, información y responsables operativos. Seleccione un pequeño conjunto de controles relacionados, como el acceso, la gestión de cambios, los registros y la recuperación, y haga que cada implantación sea verificable antes de ampliar el registro.

Secani respalda este flujo de trabajo modelando los sistemas y sus dependencias, vinculando las evidencias con los requisitos, los controles y las decisiones, y haciendo el seguimiento de las brechas como tareas. Asigne un responsable y un revisor, adjunte los registros existentes y conserve los comentarios y las aprobaciones de la revisión. Trate las correspondencias o los resúmenes asistidos por IA como borradores: valide las fuentes y mantenga explícita la aprobación humana. La preparación estructurada para auditorías explica el modelo de evidencias en que se apoya.

El primer entregable debe ser una cadena coherente que vaya del riesgo al control, la implantación, las evidencias, el resultado de la prueba y la decisión de seguimiento. Esa cadena puede repetirse después en el resto del alcance sin inventar un proceso nuevo para cada referencia del anexo A.

Preguntas prácticas

¿Puede un mismo registro respaldar varios controles?

Sí. Un ticket de baja puede respaldar varios controles relacionados. Explique qué afirmación respalda en cada caso; compartir evidencias no hace que los controles sean idénticos.

¿Debe tener cada control su propia política?

No. Organice las políticas y los procedimientos en torno a procesos operativos comprensibles. Un mismo documento puede abordar varios controles, siempre que las responsabilidades y la implantación sigan estando claras.

¿De dónde debe proceder la lista oficial de controles?

Utilice la norma ISO/IEC 27001 con licencia para la redacción del anexo A e ISO/IEC 27002 para la orientación sobre la implantación. Los resúmenes operativos son ayudas útiles para orientarse, no sustitutos de las normas.