ISO 27001: Leí la norma cinco veces. Luego intenté implementarla.

Historia real.

Un profesional al que formé el otoño pasado era responsable de seguridad en una empresa mediana de los Países Bajos. Inteligente. Meticuloso. Tenía la certificación Foundation. Había leído ISO 27001 de principio a fin. Varias veces. Sabía explicar qué exige la Cláusula 6. Podía enumerar de memoria las cuatro categorías de controles del Anexo A. Podía dibujar el ciclo Plan-Do-Check-Act en una pizarra con los ojos cerrados.

Su empresa decidió certificarse. Su responsable le dijo: "Conoces la norma. Lidera el proyecto."

Y entonces se sentó en su mesa un lunes por la mañana y se dio cuenta de que no tenía ni idea de por dónde empezar.

No porque fuera incompetente. Porque la norma nunca se lo había dicho. Le indicaba qué debía existir. Nunca le decía cómo construirlo.

A los tres meses, todavía no estaba seguro de haber definido bien el alcance. La metodología de evaluación de riesgos se había reescrito dos veces porque nadie se ponía de acuerdo en qué significaba "probable". La SoA estaba a medias y no se fiaba de nada de lo que contenía. Había avanzado, pero era ese tipo de avance en el que te mueves sin saber si lo haces en la dirección correcta.

Cuando llegó a mi curso, llevaba casi un año en ello. No porque el trabajo fuera demasiado difícil. Porque lo había estado haciendo sin metodología.

Si algo de esto le suena familiar, este artículo es para usted.

La norma no es un manual de instrucciones. Nunca fue concebida como tal.

Esto es lo que nadie dice en voz alta: ISO 27001 está deliberadamente incompleta.

No es una crítica. Es el diseño. La norma tiene que funcionar para una startup de cinco personas y para un banco de cincuenta mil empleados. Tiene que funcionar en todos los sectores, todas las jurisdicciones, todas las arquitecturas tecnológicas. La única manera de lograrlo es especificar qué debe existir sin especificar cómo construirlo. Esa generalidad es lo que la hace potente. También es lo que la hace inútil como guía paso a paso.

"La organización deberá determinar las cuestiones externas e internas relevantes para su propósito." ¿Cómo? ¿Taller? ¿PESTLE? ¿Entrevistas? ¿Un esquema garabateado en una servilleta? La norma no lo dice, porque la respuesta depende de si se trata de un hospital, una empresa SaaS o un despacho de abogados.

"La organización deberá definir y aplicar un proceso de evaluación de riesgos de seguridad de la información." Correcto. Pero ¿cómo es ese proceso? ¿Qué metodología? ¿Qué escalas? ¿Cómo se calibran para que la palabra "alto" signifique lo mismo para el departamento jurídico y para el equipo del SOC? La norma no lo dice.

"La organización deberá elaborar una Declaración de Aplicabilidad." De acuerdo. Pero ¿qué hace que una SoA sea buena? ¿Con qué nivel de detalle deben redactarse las justificaciones? ¿Qué cuenta como evidencia de implementación? ¿Es suficiente una política, o el auditor quiere registros? La norma no lo dice en absoluto.

Las personas que entienden la norma pero no pueden implementarla no tienen falta de inteligencia. Les falta metodología. Y eso no es un fallo de la persona. Es una laguna que la norma nunca fue diseñada para cubrir.

Cinco decisiones que la norma deja completamente en sus manos

He implementado ISO 27001 en más de cien organizaciones. Estas cinco decisiones son donde toda implementación encuentra su base o pierde meses.

Cómo definir el alcance. La mayoría de las personas cree que definir el alcance es sencillo. Se define qué entra, qué queda fuera y se avanza. Luego pasan tres meses discutiéndolo. ¿Debe incluirse el entorno de desarrollo? ¿Y esa filial que comparte el mismo Active Directory? ¿Y el equipo de soporte externo que accede a datos de producción? Cada decisión sobre el alcance tiene consecuencias en cascada para los riesgos, los controles y la auditoría. La norma dice "determinar el alcance". No explica cómo gestionar estos compromisos, ni cómo redactar una declaración de alcance que un auditor acepte en treinta segundos en lugar de pasarse dos horas desmontándola.

Cómo evaluar los riesgos. Aquí es donde más tiempo se pierde. No en realizar la evaluación, sino en diseñar la metodología. He revisado registros de riesgos donde toda la columna de probabilidad dice "medio". Donde la columna de impacto tiene cinco niveles pero nadie sabe explicar la diferencia entre un tres y un cuatro. Donde el mismo riesgo recibe puntuaciones distintas de dos equipos sentados en salas contiguas porque nadie calibró las escalas. La norma dice "aplicar un proceso de evaluación de riesgos". No explica cómo construir una metodología repetible, defendible y que no se derrumbe en el momento en que el auditor pregunta: "¿Por qué esto es un tres y no un cuatro?"

Cómo redactar la SoA. La Declaración de Aplicabilidad es el documento más importante de su SGSI y el que se hace peor con más frecuencia. He revisado SoAs donde todos los controles están marcados como "implementados" sin ninguna evidencia. Donde la columna de justificación dice "ver política" en noventa y tres filas. Donde las propiedades del documento muestran que la última edición la hizo alguien de una empresa completamente diferente, porque se descargó de internet y nunca se cambiaron los nombres. El auditor lee su SoA primero. Si se deshace, nada más le salva.

Cómo conseguir el compromiso de la dirección. La Cláusula 5 establece que la alta dirección debe demostrar liderazgo y compromiso. En la práctica, esto significa conseguir que el consejo asigne presupuesto, asista a las revisiones de dirección y apruebe las decisiones de aceptación de riesgos. La norma dice "la dirección deberá". No explica cómo entrar en una reunión del consejo y justificar por qué la empresa necesita gastar dinero en algo que no tiene ROI visible hasta el día en que algo falla. Es un problema de comunicación, no de seguridad, y la mayoría de las implementaciones fracasan aquí, no en la capa técnica.

Cómo preparar la auditoría. La Fase 1 es la revisión documental. La Fase 2 es la evidencia operativa. La mayoría de las personas se prepara para una y entra en pánico con la otra. Construyen documentos impecables y luego no pueden demostrar que los controles están realmente en funcionamiento. O tienen controles operativos y no pueden presentar el rastro de evidencias. La norma dice "prepararse para la auditoría de certificación". No explica qué abre primero el auditor, qué preguntas llegan en la primera hora, ni qué falla sistemáticamente en cada caso. Yo lo sé, porque he estado a ambos lados de esa mesa.

Qué significa realmente tener metodología

Cuando digo que este curso enseña la metodología, no me refiero a que se recibe una lista de verificación. Me refiero a que se aprende el sistema operativo que sustenta la norma.

Una metodología indica qué hacer primero y por qué. Explica cómo conducir el taller de alcance para que dure un día, no un trimestre. Proporciona un marco de evaluación de riesgos que se puede defender, no solo rellenar. Muestra cómo es una buena SoA y qué hace que una mala resulte evidente. Enseña a presentar la seguridad ante un consejo que no quiere oír hablar de seguridad, en un lenguaje que consigue que les importe. Y explica qué va a hacer el auditor, en qué orden, para que uno pueda prepararse en lugar de sobrevivir.

Esa es la diferencia entre conocer la norma y ser capaz de implementarla. Y es la diferencia entre un proyecto de seis meses que tiene éxito y uno de doce meses que produce un archivador lleno de documentos que nadie usa.

Para eso son los 5 días

Del 17 al 21 de agosto. De lunes a viernes. En directo online, en inglés. Un grupo limitado a seis personas, porque con siete la conversación muere y los ejercicios se vuelven una formalidad.

Cada línea de esa tabla empieza con "cómo". Es deliberado. El "qué" está en la norma. Puede leerla gratuitamente. El "cómo" es por lo que se paga.

Quién imparte este curso

Yo. Christophe. CISO en activo, fundador de Cyber Academy, PECB Gold Trainer.

No enseño implementación desde un libro de texto. Lo enseño desde el trabajo real. Cuando explico la metodología de evaluación de riesgos, es porque he construido marcos de riesgo y luego me he sentado frente a un auditor que intentaba desmontarlos. Cuando explico cómo conseguir el compromiso de la dirección, es porque me he plantado ante consejos que no querían escuchar y he encontrado la manera de hacer que escucharan. Cuando alguien en el curso dice "mi SoA es un desastre", no le doy la respuesta del examen. Le digo qué haría yo si estuviera sentado en su mesa el lunes, porque yo he estado sentado en esa mesa.

Doscientas auditorías. Cien implementaciones. Las historias de guerra de este curso son mías. Eso importa, porque la brecha entre la norma y la realidad no es teórica. Es operativa. Y se aprende a cerrarla de alguien que lo hace profesionalmente.

La garantía

Complete el curso. Preséntese al examen. Si no supera, le devolvemos la tarifa de formación.

Sin letra pequeña más allá de completar el programa y presentarse al examen. Lo llamamos Certified or Refunded, y lo decimos en serio. La metodología funciona. La tasa de aprobados lo demuestra. Y si invierte una semana de su tiempo y el dinero de su empresa, merece un proveedor que apueste por el mismo resultado que usted.

Los detalles

• Curso: ISO/IEC 27001:2022 Lead Implementer, PECB Certified
• Fechas: 17–21 de agosto de 2026
• Formato: En directo online. Interactivo. Sin grabación.
• Idioma: Inglés
• Tamaño del grupo: 3 a 6 participantes
• Examen: Examen PECB de 3 horas el Día 5, con libro abierto
• Materiales: Más de 450 páginas incluidas
• CPD: 31 créditos
• Repetición gratuita: Dentro de los 12 meses
• Precio: 2.499 €
• Garantía: Certified or Refunded

Su turno

Si ha leído la norma y todavía no sabe qué hacer el lunes por la mañana, este es el curso que cierra esa brecha.

Si le han asignado un proyecto de implementación y busca a medianoche "plantilla evaluación de riesgos ISO 27001", aquí obtiene la metodología para no tener que buscarlo nunca más.

Si es consultor y sus clientes esperan que lidere esto de principio a fin, aquí deja de improvisar y empieza a saber.

Si lleva ocho meses en un proyecto que debería haber durado cuatro, estos son sus cinco días de reinicio.

Reserve su plaza a continuación.

¿Preguntas? Escríbame directamente. Sin equipo de ventas. Sin chatbot. Solo yo.

Christophe Fundador y formador, Cyber Academy | Become the Code Father cyberacademy.net