La ISO/IEC 27001 es la norma internacional que especifica los requisitos de un SGSI — Sistema de Gestión de Seguridad de la Información. Es la única norma de la familia 27000 que permite certificación, y por eso su nombre aparece en contratos, licitaciones y procesos de due diligence.
La confusión más común empieza aquí. Mucha gente busca la ISO 27001 esperando encontrar configuraciones de cortafuegos, reglas de contraseñas y requisitos de cifrado. No es eso. La norma trata de gestión: cómo la organización decide qué proteger, con qué fundamento, quién responde por ello y cómo demuestra que el sistema sigue funcionando con el tiempo.
Qué exige la norma en realidad
El cuerpo obligatorio de la ISO 27001 está en las cláusulas 4 a 10. Son las que verifica el auditor y ninguna puede omitirse:
- 4 — Contexto de la organización. Definir el alcance del SGSI e identificar las partes interesadas y sus requisitos.
- 5 — Liderazgo. La alta dirección debe asumir la política de seguridad y asignar roles formalmente. No es delegable a TI.
- 6 — Planificación. Evaluación y tratamiento de riesgos, objetivos de seguridad medibles.
- 7 — Apoyo. Competencia, concienciación, comunicación y control de la información documentada.
- 8 — Operación. Ejecutar lo planificado y dejar registro de ello.
- 9 — Evaluación del desempeño. Seguimiento, auditoría interna y revisión por la dirección.
- 10 — Mejora. Tratamiento de no conformidades y mejora continua.
El Anexo A, donde están los controles de seguridad propiamente dichos, funciona como referencia de verificación: hay que justificar, en la Declaración de Aplicabilidad, por qué cada control aplica o no a tu alcance.
Qué cambió en la versión 2022
La revisión de 2022 reorganizó por completo el Anexo A. Los 114 controles distribuidos en 14 secciones de la versión 2013 dieron paso a 93 controles agrupados en cuatro temas: organizativos, de personas, físicos y tecnológicos.
La reducción no significa que la norma se haya aligerado. Buena parte proviene de fusionar controles que se solapaban, y once controles son enteramente nuevos — entre ellos inteligencia de amenazas, seguridad en el uso de servicios en la nube, enmascaramiento de datos, prevención de fugas y codificación segura. Son temas que apenas existían en el vocabulario de 2013.
Atención al plazo. El período de transición para las organizaciones certificadas en la versión 2013 terminó el 31 de octubre de 2025. Los certificados emitidos bajo la versión antigua ya no tienen validez. Si tu organización no completó la migración, el certificado debe obtenerse de nuevo en la versión 2022.
Para qué sirve, en la práctica
Conviene separar los motivos reales de los declarados. En la mayoría de los proyectos que nos llegan, el detonante es uno de estos:
- Exigencia comercial. Un cliente grande — o un proceso de compra internacional — puso la certificación como condición. Es, con diferencia, el motivo más frecuente.
- Exigencia regulatoria indirecta. El regulador no pide la ISO 27001 por su nombre, pero exige un conjunto de prácticas que la norma organiza bien.
- Reducción real del riesgo. La organización ya tuvo un incidente, o se dio cuenta de que no sabe responder a la pregunta "¿qué protegemos exactamente?".
Los tres son legítimos. Pero llevan a proyectos distintos: el primero tiende a producir un alcance estrecho y rápido; el tercero exige un alcance más amplio y un cronograma más largo. Definir cuál es el tuyo antes de empezar evita la frustración de un proyecto que entrega el certificado sin reducir exposición — o que reduce exposición pero retrasa el contrato.
Cuánto tiempo lleva
Para una organización de tamaño medio, sin SGSI previo, el intervalo típico entre el inicio del proyecto y la auditoría de certificación está entre 6 y 12 meses. Lo que estira ese plazo casi nunca es la parte técnica: es la necesidad de acumular evidencia. La auditoría de etapa 2 exige que el sistema esté operando, con registros de seguimiento, al menos un ciclo de auditoría interna y una revisión por la dirección ya realizada.
El error que más caro cuesta
Tratar la ISO 27001 como un proyecto de TI. Cuando el SGSI queda bajo responsabilidad exclusiva de infraestructura suelen pasar tres cosas: el alcance se define por sistema en lugar de por proceso de negocio, la evaluación de riesgos se convierte en un inventario de vulnerabilidades técnicas, y la cláusula 5 — liderazgo — no puede evidenciarse, porque la dirección nunca estuvo involucrada.
El auditor no pide capturas de consola. Pide actas de reunión, decisiones registradas y criterios de aceptación de riesgo firmados por quien tiene autoridad para aceptar riesgo.
Por dónde empezar
Antes de contratar consultoría o comprar herramientas, haz un diagnóstico de brecha: cuáles de los requisitos de las cláusulas 4 a 10 ya cumples de alguna forma, aunque sea informalmente, y cuáles no existen. Las organizaciones que ya tienen gestión de cambios, control de acceso documentado y algún proceso de respuesta a incidentes suelen estar más cerca de lo que creen — lo que falta es formalización y evidencia, no capacidad.