Conocimiento que genera valor

Declaración de aplicabilidad ISO 27001: qué debe contener y errores frecuentes

La declaración de aplicabilidad conecta los riesgos con los controles del SGSI. Vea qué debe incluir, cómo se construye y qué añade el MSPI en entidades.

Persona revisando una matriz impresa con columnas y marcas junto a un portátil en una oficina

De todos los documentos de un sistema de gestión de seguridad de la información (SGSI), la declaración de aplicabilidad es uno de los que más atención recibe en una auditoría y uno de los que con más frecuencia se elabora de forma mecánica. A menudo se arma al final, copiando la lista del Anexo A de ISO/IEC 27001 y marcando «aplica» en casi todo. Así deja de cumplir su función: mostrar, control por control, que las decisiones de seguridad responden a los riesgos de la organización. Esta guía explica qué debe contener, cómo construirla y qué cambia en las entidades públicas que aplican el Modelo de Seguridad y Privacidad de la Información (MSPI).

Para qué sirve

La declaración de aplicabilidad es el puente entre la gestión de riesgos y los controles. La norma la ubica en la planificación del tratamiento de riesgos (numeral 6.1.3 de ISO/IEC 27001:2022): después de evaluar los riesgos (numeral 6.1.2), la organización elige cómo tratarlos, determina los controles necesarios y los compara con el Anexo A para verificar que no ha omitido ninguno. La declaración deja constancia de ese resultado.

Por eso es útil más allá de la certificación. Para la dirección, resume en un solo documento qué protege la organización y por qué. Para un auditor, es el punto de partida para elegir qué verificar. Y para el equipo de seguridad, es la referencia para saber qué controles mantener, medir y mejorar. También es una base práctica para planear la auditoría interna, porque muestra qué controles existen y en qué estado están.

Qué debe contener

ISO/IEC 27001:2022 pide, como mínimo, cuatro elementos:

  • Los controles necesarios para tratar los riesgos, determinados en el plan de tratamiento.
  • La justificación de por qué se incluye cada uno.
  • Si cada control está implementado o no.
  • La justificación de cada control del Anexo A que se excluye.

La norma no fija un formato: puede ser una tabla, una hoja de cálculo o un registro en una herramienta de gestión. Lo importante es que refleje las decisiones vigentes del tratamiento de riesgos.

Cómo construirla paso a paso

  1. Defina el alcance del SGSI. La declaración vale para ese alcance; si cubre solo algunos procesos o sedes, debe decirlo.
  2. Evalúe los riesgos con criterios definidos. Sin una evaluación previa, las justificaciones serán genéricas.
  3. Decida el tratamiento de cada riesgo que no sea aceptable y determine los controles necesarios.
  4. Compare con el Anexo A. Recorra los 93 controles y pregúntese si alguno es necesario y no fue considerado.
  5. Justifique cada inclusión y cada exclusión. Lo ideal es que la justificación remita a los riesgos que trata el control o a la razón concreta por la que no aplica.
  6. Registre el estado de implementación. La norma pide indicar si cada control está implementado; distinguir entre implementado, en implementación y pendiente ayuda a planificar.
  7. Vincule la declaración con el plan de tratamiento. En ISO/IEC 27001, los propietarios del riesgo aprueban el plan de tratamiento y aceptan los riesgos residuales. Conviene que los controles pendientes aparezcan en el plan con responsables y fechas; en el MSPI es obligatorio.
  8. Mantenga el documento vivo. Cada cambio en los riesgos, en el alcance o en la operación puede obligar a revisarlo.

La guía ISO/IEC 27005:2022 orienta la gestión de riesgos de seguridad de la información y puede apoyar los pasos 2 y 3.

Un ejemplo de justificación útil

La diferencia entre una declaración que sirve y una que solo cumple está en las justificaciones. Tomemos tres controles de una organización que presta servicios en línea, con personal en trabajo remoto, que usa correo y almacenamiento en la nube y no desarrolla ni contrata desarrollo de software:

  • Trabajo remoto. Justificación débil: «Aplica por buenas prácticas». Justificación útil: «Aplica. Trata el riesgo de acceso indebido a información de clientes desde equipos fuera de la oficina, identificado en la evaluación de riesgos. Implementado: política de trabajo remoto y conexión cifrada obligatoria».
  • Uso de servicios en la nube. Justificación útil: «Aplica. Trata el riesgo de pérdida o exposición de información almacenada en el proveedor de correo y almacenamiento. En implementación: revisión de las condiciones de seguridad del contrato y de la configuración de accesos, con fecha en el plan de tratamiento».
  • Desarrollo tercerizado. Justificación débil: «No aplica». Justificación útil: «Excluido. La organización no desarrolla ni contrata desarrollo de software; usa software comercial y servicios en la nube, cuyos riesgos se tratan con los controles aplicables a servicios en la nube y proveedores. Se revisará si se contrata un desarrollo».

En los tres casos, quien lee la declaración entiende la decisión sin tener que preguntar, y un auditor sabe qué evidencia pedir. El ejemplo es ilustrativo: cada organización redacta sus justificaciones a partir de su propia evaluación de riesgos.

Cómo la usa un auditor

En una auditoría interna o de certificación, la declaración de aplicabilidad suele ser uno de los primeros documentos que se revisan. El auditor contrasta las exclusiones con los riesgos y el contexto, para ver si alguna deja un riesgo sin tratar. También elige una muestra de controles declarados como implementados y busca la evidencia de que funcionan, y comprueba que los controles pendientes estén en el plan de tratamiento. Una declaración coherente con la evaluación de riesgos facilita ese trabajo. Una declaración genérica suele terminar en hallazgos.

Qué añade el MSPI en las entidades públicas

El Documento Maestro del MSPI, anexo actualizado por la Resolución 2277 de 2025 de MinTIC, retoma la declaración de aplicabilidad en la planificación del tratamiento de riesgos y le agrega condiciones propias:

  • Contenido. Debe incluir los controles adoptados por la entidad, su estado de implementación y la justificación de las posibles exclusiones, de acuerdo con los riesgos identificados y con las capacidades técnicas y humanas de la entidad.
  • Inclusiones y exclusiones. La estructura que el modelo propone para la tabla de controles prevé justificar cada control, tanto si se implementa como si se excluye.
  • Aprobación. La declaración de aplicabilidad se aprueba en el Comité Institucional de Gestión y Desempeño.
  • Plan de tratamiento. Además de lo que pide la norma, el MSPI exige que incluya acciones, fechas y responsables; que los dueños de los riesgos sean los dueños de los procesos afectados o las personas que ellos designen; y que su aprobación se lleve a la revisión por la dirección en el comité, o en la instancia que haga sus veces. El plan se integra al Plan de Acción y se publica a más tardar el 31 de enero de cada año, según el Decreto 612 de 2018, para las entidades dentro del ámbito de aplicación de MIPG.

Para una entidad con un SGSI ya certificado, esto significa que su declaración puede servir de base para el MSPI, pero debe pasar por la aprobación del comité y reflejar el alcance que la entidad definió para el modelo.

Errores frecuentes

  • Copiar el Anexo A y marcar «aplica» en todos los controles, sin justificación.
  • Justificar con frases genéricas, como «aplica por buenas prácticas», que no remiten a ningún riesgo.
  • Excluir controles por comodidad, por ejemplo los físicos en una organización con trabajo remoto, sin analizar dónde está la información.
  • Olvidar controles que el tratamiento de riesgos requiere y que no figuran tal cual en el Anexo A.
  • Declarar como implementado un control que solo existe en una política.
  • No actualizar la declaración después de cambios en el alcance, la tecnología o los proveedores.
  • En una entidad pública, dejar la declaración solo en el área de tecnología, sin la aprobación del comité que pide el MSPI.

Puede ver un resumen de cómo se eligen los controles en la página de ISO/IEC 27001 y MSPI. Undernet no certifica: preparamos a su organización para la auditoría del organismo de certificación que usted elija.

Preguntas frecuentes

¿Se puede excluir un control del Anexo A?

Sí. La norma permite excluir controles del Anexo A cuando el tratamiento de riesgos no los requiere, siempre que la exclusión se justifique. Si la organización declara conformidad con la norma, no puede excluir ninguno de los requisitos de las cláusulas 4 a 10.

¿Cada cuánto se actualiza?

La norma pide repetir la evaluación de riesgos a intervalos planificados; la declaración debe actualizarse cuando esa evaluación, el alcance o la operación cambien.

¿Quién la aprueba?

ISO/IEC 27001 no indica quién aprueba la declaración de aplicabilidad. Sí pide que los propietarios del riesgo aprueben el plan de tratamiento y acepten los riesgos residuales. En el MSPI, la declaración de aplicabilidad se aprueba en el Comité Institucional de Gestión y Desempeño.

Consulte el acompañamiento en la implementación

Fuentes

  1. ISO/IEC 27001:2022 · ISO
  2. ISO/IEC 27005:2022 · ISO
  3. Documento Maestro de los Lineamientos del Modelo de Seguridad y Privacidad de la Información · Ministerio de Tecnologías de la Información y las Comunicaciones · 21 de abril de 2025
  4. Resolución 2277 de 2025 · Ministerio de Tecnologías de la Información y las Comunicaciones · 3 de junio de 2025
  5. Decreto 612 de 2018 · Presidencia de la República · 4 de abril de 2018

Convierta el conocimiento en resultados

¿Necesita acompañamiento especializado?

Conozca nuestros servicios o consúltenos sobre este tema.

Conozca nuestros servicios Contactar a Undernet