Utilice un plan de proyecto de 12 semanas con estructura 30/60/90 días cuando cuente con patrocinio ejecutivo, un responsable de SGSI dedicado y algunos controles de seguridad básicos ya implantados. Esta estructura le permite alcanzar los artefactos requeridos para la auditoría —acta de constitución del proyecto, análisis de brechas, evaluación de riesgos y Declaración de Aplicabilidad— en el menor tiempo posible. Sin esas condiciones, prevea entre 4 y 12 meses. En cualquier caso, los primeros entregables no cambian: un acta de constitución firmada, un alcance documentado, un análisis de brechas cláusula por cláusula y un registro de riesgos inicial.
Resumen ejecutivo:
- Las organizaciones con un responsable de SGSI dedicado a tiempo completo y un sólido apoyo directivo pueden obtener la certificación ISO 27001 en 12 semanas, siempre que los controles ya estén implantados.
- Para organizaciones que parten de cero o con controles poco maduros, el plazo del proyecto se extiende de cuatro a doce meses, con énfasis en la configuración de bases y la concienciación.
- Los hitos clave incluyen un acta de constitución firmada, un alcance documentado, un análisis de brechas cláusula por cláusula y una política de seguridad de la información aprobada, todos completados en los primeros 30 días.
- La evaluación de riesgos y la Declaración de Aplicabilidad requieren metodologías coherentes y sencillas, clasificación de activos, identificación de amenazas y mapeo detallado de controles, avanzando durante las semanas 31 a 60.
- Acelerar el proceso conlleva el riesgo de brechas de evidencia y expansión del alcance, por lo que el acotamiento estricto de tiempos, el uso de plantillas prediseñadas y la ejecución paralela de tareas son imprescindibles para mantener la preparación para la auditoría sin comprometer la calidad.
Tabla de contenidos
- ¿Cuál es el cronograma adecuado del plan de proyecto ISO 27001 para su organización?
- Requisitos previos y lista de verificación de planificación antes de comenzar
- Días 1 a 30: la fase de fundamentos, semana a semana
- Días 31 a 60: evaluación de riesgos, la Declaración de Aplicabilidad y los procedimientos principales
- Días 61 a 90: implementación, formación y preparación para la certificación
- Un cronograma de 12 semanas que puede copiar en su propio plan
- Cómo son realmente los recursos humanos y el presupuesto
- Cómo acelerar sin arruinar la auditoría
- Lo que he visto romper proyectos ISO 27001 y qué corregir primero
- Planifique su presupuesto y cronograma con cifras reales, no suposiciones
- Fuentes
¿Cuál es el cronograma adecuado del plan de proyecto ISO 27001 para su organización?
La respuesta honesta depende menos del tamaño de la empresa y más de tres factores: el tiempo dedicado que puede comprometer el responsable del SGSI, el respaldo directivo disponible para tomar decisiones rápidas y la madurez de los controles existentes. Las organizaciones con un responsable de SGSI de entre 0,5 y 1,0 FTE, una reunión semanal del comité de dirección y alguien con autoridad para aprobar el tratamiento de riesgos sobre la marcha pueden alcanzar de forma realista un estado de preparación para la certificación en 90 días. Todos los demás deberían planificar un plazo más largo.
Un fast-track de 12 semanas solo funciona si no se parte de cero. Si ya dispone de controles de acceso, un proceso de gestión de parches y algún tipo de inventario de activos, lo que se comprime es el trabajo de documentación y formalización, no la construcción de la seguridad desde cero. Se trata de un proyecto muy diferente al que implica poner en marcha MFA, protección de endpoints y gestión de riesgos de proveedores al mismo tiempo que se redacta una política de seguridad de la información.
La estructura por fases en sí no cambia demasiado entre un sprint de 90 días y una implantación de 9 meses. Se avanza por las mismas tres etapas:
- Fundamentos — definición del alcance, gobernanza y análisis de brechas frente a ISO 27001:2022 y el Anexo A
- Desarrollo — evaluación de riesgos, mapeo de controles y Declaración de Aplicabilidad
- Implementación — despliegue de controles, formación del personal, realización de una auditoría interna y preparación para la certificación
Lo que cambia es cuánto se ejecuta en paralelo frente a en secuencia, y cuánto margen se reserva para la iteración.
El bloqueo más habitual no es técnico, sino organizativo. Los proyectos se estancan cuando nadie es propietario del registro de riesgos, cuando el alcance sigue expandiéndose a mitad del proyecto porque alguien insiste en incluir una nueva unidad de negocio, o cuando los responsables de departamento tratan el SGSI como una iniciativa de TI en lugar de una iniciativa organizativa. Cualquiera de estas situaciones puede convertir un plan ajustado de 90 días en un proceso de 6 meses con la misma cantidad de trabajo real.
Requisitos previos y lista de verificación de planificación antes de comenzar
Antes de redactar un solo procedimiento o ejecutar un análisis de brechas, asegure cuatro aspectos. Omitir esta etapa es la razón más común por la que los proyectos ISO 27001 no cumplen sus plazos.
- Obtenga el patrocinio ejecutivo por escrito. Un acta de constitución del proyecto debe identificar al patrocinador ejecutivo, al responsable del SGSI, la autoridad presupuestaria y una matriz RACI que indique quién es Responsable, Aprobador, Consultado e Informado en cada flujo de trabajo principal. Establezca una cadencia del comité de dirección: semanal para un fast-track, quincenal o mensual para una implantación más larga.
- Defina el alcance y las exclusiones de forma explícita. Documente qué unidades de negocio, ubicaciones, sistemas y terceros están dentro del perímetro del SGSI y, con igual importancia, cuáles no. Una declaración de alcance vaga es el origen de los problemas en las auditorías de certificación meses después.
- Adquiera la norma y configure su repositorio de documentación. Compre ISO 27001:2022 e ISO 27002:2022 directamente, en lugar de depender de resúmenes. Ponga en marcha un repositorio centralizado (SharePoint, Confluence o una herramienta GRC dedicada) antes de empezar a generar documentos, no después.
- Imparta formación de concienciación básica al equipo principal. Todos los que participen en el proyecto —no solo el responsable del SGSI— deben comprender la estructura del Anexo A y qué es realmente una Declaración de Aplicabilidad antes de que comience la semana uno.
La base técnica mínima para un fast-track realista incluye políticas de control de acceso, algún tipo de registro de eventos, una cadencia de aplicación de parches y una lista de activos, aunque esté incompleta. Si nada de eso existe aún, una hoja de ruta de 12 semanas no es realista. Planifique entre 6 y 12 meses y trate las semanas 1 a 4 como el momento en que se construye esa base en lugar de documentarla.
Consejo práctico: Configure el repositorio de documentación y los permisos de acceso antes de la reunión de inicio, no durante la semana uno. Los equipos pierden días enteros en discusiones sobre "quién puede editar esta carpeta" que nunca deberían haberse producido.
Días 1 a 30: la fase de fundamentos, semana a semana
Los primeros 30 días marcan la trayectoria de todo lo que sigue. Si esta fase se ejecuta de forma descuidada, se pasarán las semanas 5 a 12 corrigiendo problemas de alcance y gobernanza en lugar de construir controles.
- Semana 1: inicio y gobernanza. Celebre el inicio formal, finalice el acta de constitución, asigne la matriz RACI, configure el repositorio de documentación e imparta la formación inicial de concienciación sobre ISO 27001 al equipo principal del proyecto.
- Semana 2: contexto y alcance. Documente el contexto organizativo, identifique las partes interesadas (organismos reguladores, clientes, aseguradoras), redacte la declaración de alcance formal e inicie un primer registro de activos que cubra personas, sistemas y datos.
- Semana 3: análisis de brechas. Realice una evaluación cláusula por cláusula frente a los requisitos de gestión de ISO 27001:2022 y todos los controles del Anexo A. Un análisis de brechas estructurado y acotado en el tiempo, con una puntuación sencilla Rojo/Ámbar/Verde, evita que este trabajo se convierta en una auditoría abierta que consume un mes por sí sola.
- Semana 4: política y aprobación ejecutiva. Redacte la política de seguridad de la información, defina roles y responsabilidades para el SGSI, establezca objetivos de seguridad medibles y obtenga la aprobación ejecutiva formal de todo ello.
Al día 30 debería tener: un acta de constitución firmada, una declaración de alcance documentada, un análisis de brechas completado con hallazgos puntuados en RAG y una política de seguridad de la información aprobada en su repositorio. Ese es el criterio de aceptación. Si alguno de esos cuatro elementos falta o sigue en borrador, no avance hacia la evaluación de riesgos todavía. Primero consolide los fundamentos.
Las hojas de ruta basadas en una estructura de 90 días / 12 semanas funcionan para pymes con recursos dedicados y controles básicos existentes, pero las organizaciones más grandes o menos maduras suelen necesitar entre 4 y 12 meses para cubrir el mismo terreno de forma adecuada. No hay nada de malo en ese plazo más largo; apresurar un análisis de brechas para cumplir un objetivo arbitrario de 30 días solo traslada los mismos problemas sin resolver a las semanas 5 a 8, donde son más difíciles de corregir.
Días 31 a 60: evaluación de riesgos, la Declaración de Aplicabilidad y los procedimientos principales
Esta fase es donde se concentra la mayor parte del trabajo intelectual y donde los atajos descuidados se hacen más evidentes durante la auditoría externa.
Comience diseñando una metodología de riesgos lo suficientemente sencilla como para que cualquier miembro del equipo pueda aplicarla de forma coherente. Una matriz de probabilidad/impacto de 5x5 con criterios de puntuación claramente definidos funciona para la mayoría de las organizaciones. Complicar en exceso este paso es una trampa habitual: los auditores se preocupan menos por la sofisticación metodológica y más por si aplicó su propio método de forma coherente.
A partir de ahí:
- Clasifique los activos por sensibilidad e importancia para el negocio usando el registro iniciado en la semana 2.
- Identifique amenazas y vulnerabilidades realistas por categoría de activo —no por activo individual— para mantener el registro manejable.
- Puntúe cada riesgo según su metodología y decida una opción de tratamiento: aceptar, mitigar, transferir o evitar.
- Mapee cada riesgo tratado a un control específico del Anexo A (o a un control personalizado si ninguno encaja) y redacte una justificación de una línea para cada control del Anexo A que excluya.
Ese ejercicio de mapeo produce su Declaración de Aplicabilidad, que funciona como el índice maestro que los auditores utilizan para rastrear cada decisión hasta una justificación documentada. El diseño de una metodología de riesgos documentada y la producción de una Declaración de Aplicabilidad que mapee los riesgos a los controles del Anexo A constituye el núcleo de todo el proceso de certificación, no un añadido que se genera al final.
Una vez redactada la Declaración de Aplicabilidad, priorice los procedimientos para los controles con las puntuaciones de riesgo más altas: el control de acceso, la respuesta a incidentes y la copia de seguridad/recuperación suelen encabezar esa lista. Redacte cada procedimiento con la recopilación de evidencias integrada desde el primer día. Si un procedimiento establece que se realizan revisiones de acceso trimestrales, el procedimiento también debe especificar dónde se almacena la firma de aprobación de la revisión.
Consejo práctico: Redacte los procedimientos y las plantillas de evidencias conjuntamente, no de forma secuencial. Un procedimiento sin una plantilla de evidencias correspondiente es una política que nadie puede demostrar que siguió seis meses después.
Días 61 a 90: implementación, formación y preparación para la certificación
Esta es la fase en la que el SGSI pasa de estar documentado a ser demostrable. Los auditores no certifican documentación, certifican evidencias de que la documentación refleja la realidad.
Comience implantando los controles en el orden priorizado por su plan de tratamiento de riesgos y construya el rastro de evidencias a medida que avance, en lugar de reconstruirlo después:
- Despliegue los controles técnicos y procedimentales del plan de tratamiento, registrando las fechas de finalización y los responsables de cada uno.
- Configure carpetas de evidencias o una herramienta GRC estructurada en torno a su Declaración de Aplicabilidad, de modo que cada control se vincule a una prueba específica.
- Implante formación basada en roles: concienciación general para todos, formación técnica más profunda para administradores y desarrolladores, y conserve registros de asistencia firmados.
- Realice un seguimiento de la finalización de la formación frente a un plazo límite; los registros de formación incompletos son un hallazgo habitual en las auditorías de Etapa 1.
Con los controles en funcionamiento y las evidencias acumulándose, pase a la auditoría interna y la revisión por la dirección:
- Defina el alcance de la auditoría interna cubriendo todos los controles del Anexo A declarados en la Declaración de Aplicabilidad, no una muestra.
- Elabore un plan y un calendario de auditoría, idealmente con alguien ajeno al departamento auditado para preservar la independencia.
- Registre cada no conformidad detectada, asigne un responsable de la acción correctiva y establezca un plazo de resolución.
- Convoque una revisión formal por la dirección con entradas que incluyan los resultados de la auditoría, el estado del registro de riesgos y el rendimiento de los objetivos, y documente las decisiones adoptadas.
- Recopile el paquete completo de documentación —políticas, registro de riesgos, Declaración de Aplicabilidad, procedimientos, registros de formación, informes de auditoría— para la revisión del auditor externo.
La trazabilidad de las evidencias importa más a los auditores que un lenguaje de política impecable. Una política de registro de eventos respaldada por tres meses de firmas reales de revisión de accesos superará siempre a una política brillantemente redactada sin registros de soporte.
Un cronograma de 12 semanas que puede copiar en su propio plan
Así es como las tres fases se desglosan semana a semana, con el entregable que cada semana debe producir.
| Semana | Foco | Entregable clave |
|---|---|---|
| 1 | Inicio, acta de constitución, RACI, configuración del repositorio | Acta de constitución del proyecto firmada |
| 2 | Contexto, partes interesadas, alcance, registro de activos (v1) | Declaración de alcance documentada |
| 3 | Análisis de brechas cláusula por cláusula frente al Anexo A | Informe de análisis de brechas puntuado en RAG |
| 4 | Redacción de la política, roles, objetivos, aprobación ejecutiva | Política de seguridad de la información aprobada |
| 5 | Diseño de la metodología de riesgos y clasificación de activos | Metodología de riesgos documentada |
| 6 | Identificación de amenazas y puntuación de riesgos | Borrador del registro de riesgos |
| 7 | Decisiones de tratamiento de riesgos y mapeo de controles | Borrador de la Declaración de Aplicabilidad |
| 8 | Redacción de procedimientos para los controles de mayor prioridad | Procedimientos de control de acceso y respuesta a incidentes |
| 9 | Implementación de controles y plantillas de evidencias | Marco de recopilación de evidencias operativo |
| 10 | Implantación de la formación (general y por roles) | Registros de finalización de formación firmados |
| 11 | Ejecución de la auditoría interna | Informe de auditoría interna con hallazgos |
| 12 | Revisión por la dirección y paquete de documentación | Paquete de evidencias listo para la certificación |
Las semanas 3, 7 y 11 son los hitos que merece la pena tratar como puntos de decisión de avance o pausa. Si el análisis de brechas, el borrador de la Declaración de Aplicabilidad o los hallazgos de la auditoría interna presentan debilidades en cualquiera de esos puntos, esa es la señal para añadir margen antes de seguir avanzando, no después.
Cómo son realmente los recursos humanos y el presupuesto
La mayoría de los planes de proyecto subestiman el compromiso de tiempo porque tratan ISO 27001 como un ejercicio de redacción de documentos en lugar de un cambio operativo. Es ambas cosas, y la mitad operativa lleva más tiempo.
Para un proyecto fast-track de 12 semanas, un modelo de recursos realista es el siguiente:
- Responsable del SGSI: entre el 50 y el 100 % de su tiempo durante las 12 semanas completas; este rol no puede ser un proyecto secundario.
- Patrocinador ejecutivo: entre 2 y 4 horas a la semana para reuniones del comité de dirección y decisiones rápidas de tratamiento de riesgos.
- Responsable de TI: entre el 25 y el 40 % de su tiempo, con mayor carga durante las semanas 5 a 10 a medida que se implementan los controles.
- Representantes de RRHH e instalaciones: unas pocas horas a la semana para la implantación de la formación y los controles de seguridad física.
- Representantes de departamento: entre 2 y 5 horas a la semana cada uno durante las fases de análisis de brechas y evaluación de riesgos.
Las organizaciones pequeñas (menos de 50 empleados) a menudo pueden ejecutar esto casi en su totalidad con personal interno más un consultor a tiempo parcial para la metodología inicial de riesgos y la auditoría interna. Las organizaciones medianas y grandes suelen combinar la responsabilidad interna con un consultor externo para el análisis de brechas y un auditor jefe certificado para la preparación de la Etapa 1, ya que los auditores internos que revisan los controles de su propio departamento generan un problema de independencia.
Factores de coste a vigilar: las tarifas diarias de consultoría para el análisis de brechas y el apoyo a la auditoría, las tasas de auditoría del organismo de certificación (generalmente distribuidas entre la Etapa 1 y la Etapa 2) y cualquier coste de herramientas para una plataforma GRC. Antes de finalizar las estimaciones de personal, conviene revisar un desglose por roles de las responsabilidades ISO 27001, ya que subestimar el tiempo del responsable de TI es uno de los errores presupuestarios más frecuentes.
Consejo práctico: Presupueste las horas de consultoría por separado de las horas del personal interno en su plan de proyecto. Mezclarlas oculta el coste real del apoyo externo hasta que llega la factura.
Cómo acelerar sin arruinar la auditoría
La compresión es posible, pero solo dentro de ciertos límites, y cada atajo conlleva una compensación que merece nombrarse abiertamente antes de adoptarla.
- Acote el análisis de brechas a una ventana estricta de 2 a 3 semanas y fuerce la priorización en RAG en lugar de documentar exhaustivamente cada hallazgo. Esta es la táctica de compresión de mayor apalancamiento disponible.
- Use plantillas prediseñadas de Declaración de Aplicabilidad y bibliotecas de mapeo de controles en lugar de redactar justificaciones desde cero para los 93 controles del Anexo A.
- Ejecute la evaluación de riesgos y la redacción de procedimientos en paralelo en lugar de secuencialmente, una vez que la metodología de riesgos esté cerrada.
- Use la recopilación de evidencias asistida por herramientas (captura automática de registros, exportaciones de sistemas de tickets) en lugar de la compilación manual de capturas de pantalla.
La compensación es real: comprimir demasiado agresivamente desplaza el riesgo de auditoría hacia adelante; las brechas de evidencias afloran en la Etapa 1 en lugar de detectarse internamente. Una mayor dependencia de consultores externos para cumplir un plazo ajustado también eleva el coste por semana aunque acorte el calendario. Trate la aceleración como algo que se gana gracias a la madurez existente, no como algo que se impone mediante pura gestión de proyecto.
Lo que he visto romper proyectos ISO 27001 y qué corregir primero
Los proyectos que se estancan casi nunca fracasan por razones técnicas. Fracasan porque las evidencias son inconsistentes, el alcance se amplía silenciosamente tres semanas después del inicio, o nadie puede decir quién es realmente el propietario del registro de riesgos una vez que la emoción inicial del arranque se desvanece. He visto equipos redactar políticas impecables y descubrir, dos semanas antes de la Etapa 1, que nadie conservó las hojas de firma de asistencia a la formación que esas políticas prometían que existían.
Si se lleva una sola regla de priorización de todo este plan, que sea esta: construya la trazabilidad de la Declaración de Aplicabilidad y las evidencias de control demostrables antes de pulir cualquier otra cosa. Una política aproximada respaldada por seis meses de registros reales de revisión de accesos superará una auditoría que una política impecable sin rastro de evidencias no superará. Los auditores están entrenados para tirar de hilos, y un hilo suelto en un control les lleva a tirar con más fuerza del siguiente.
Antes de la Etapa 1, asegúrese de poder entregar a un auditor sin apresurarse: una Declaración de Aplicabilidad actualizada con cada exclusión justificada, un registro de riesgos que muestre las decisiones de tratamiento y sus fechas, registros de formación que coincidan con la cadencia declarada en su política, y al menos un ciclo completo de auditoría interna con acciones correctivas cerradas. Todo lo demás en su paquete de documentación importa menos que esos cuatro elementos.
— Martin
Planifique su presupuesto y cronograma con cifras reales, no suposiciones
La mayoría de los planes de proyecto ISO 27001 se desmoronan en la fase de presupuesto, no en la de ejecución, porque la dirección aprobó un cronograma basado en una plantilla genérica en lugar de cifras específicas para el tamaño, el sector y la madurez de seguridad existente de su empresa.
La evaluación de preparación de Ismscalculator genera en minutos una estimación de costes y esfuerzo personalizada, comparada con empresas de su tamaño y sector, para que no tenga que defender un cronograma de 12 semanas ante su director financiero respaldándose únicamente en una entrada de blog. Realice una verificación de madurez en los cuatro temas de control de ISO/IEC 27001:2022, exporte el cronograma resultante como un diagrama de Gantt personalizable que su comité de dirección pueda revisar de verdad, y guarde múltiples escenarios si está evaluando un fast-track frente a una implantación por fases. Si solo necesita una verificación rápida antes de comprometer recursos al proyecto, la verificación de preparación de 2 minutos ofrece a los directivos una señal suficientemente rápida para aprobar un acta de constitución sin esperar a un encargo de consultoría completo. Comience con la evaluación de preparación, guarde su estimación y llévela a su primera reunión del comité de dirección como la línea base de referencia para todos.
Fuentes
La hoja de ruta de implementación de ISO 27001 de GLOCERT International expone la estructura 30/60/90 sobre la que se construye este artículo, incluyendo variaciones de plazos realistas según el tamaño de la organización. La guía de hoja de ruta de implementación de Copla profundiza en el análisis de brechas acotado en el tiempo y la puntuación RAG. El artículo de la revista ISACA sobre planificación e implementación de ISO 27001 sigue siendo una de las explicaciones más claras de cómo la evaluación de riesgos se conecta con la Declaración de Aplicabilidad. Para la preparación de evidencias específicamente, la lista de verificación de evaluación de riesgos de tekRESCUE ofrece un marco práctico de ocho pasos que vale la pena contrastar con su propia metodología. Si desea una visión más amplia de cómo es un cronograma completo de principio a fin, el propio desglose del cronograma de implementación de Ismscalculator y su lista de verificación de certificación de 80 pasos están diseñados para complementar directamente el plan anterior.
- Hoja de ruta de implementación ISO 27001: plan de 30-60-90 días y 12 semanas
- Planificación e implementación de ISO 27001