Saber qué dice ISO/IEC 27001:2022 cláusula a cláusula —lo viste en el Módulo 5— y conocer los 93 controles del Anexo A —Módulo 6— no implanta un SGSI. Entre la teoría y el certificado hay un proyecto real, con presupuesto, calendario, resistencias internas y un montón de documentos que alguien tiene que escribir, aprobar, distribuir y, sobre todo, usar. Este módulo es la hoja de ruta de ese proyecto: los pasos en el orden en que ocurren de verdad, con los errores que hunden más implantaciones que cualquier carencia técnica.
El enfoque es deliberadamente de gestión de proyectos, no de teoría normativa. Verás qué hace exactamente un responsable de SGSI en cada fase, cómo se define un alcance que no te explote en la cara en la auditoría de certificación, cómo se construye un gap analysis que sirva para algo más que rellenar una plantilla, qué documentación exige la norma —con su cláusula exacta, sin listas inventadas— y cuánto tiempo real se tarda en tener evidencias suficientes para presentarse a auditoría. Si vas a liderar o participar en una implantación de ISO 27001, este es el módulo que conecta todo lo demás con la realidad de un proyecto.
Qué aprenderás
- Cómo se estructura un proyecto de implantación de SGSI: patrocinio, equipo, hitos y factores de éxito.
- Cómo definir el alcance del SGSI sin caer en los dos errores que más certificaciones invalidan o encarecen.
- Cómo hacer un gap analysis real, con una tabla de requisito → estado actual → brecha → acción.
- Dónde encaja el análisis de riesgos y la Declaración de Aplicabilidad dentro del calendario del proyecto.
- La lista exacta —cláusula por cláusula— de la información documentada que exige ISO/IEC 27001:2022.
- Cómo gestionar esa documentación: versiones, aprobación, distribución y protección.
- Por qué la formación y la concienciación no son un trámite sino un requisito de certificación.
- Qué métricas mínimas necesita un SGSI para poder demostrar que funciona, no solo que existe.
- Cuánto tiempo real hace falta operando el SGSI antes de poder auditar y certificar.
- Un cronograma tipo de proyecto y un caso práctico completo con las primeras filas de un gap analysis real.
El SGSI como proyecto: patrocinio, equipo y factores de éxito
La causa número uno de fracaso en implantaciones de ISO 27001 no es técnica: es de gobernanza de proyecto. Un SGSI que nace como iniciativa aislada del departamento de IT, sin patrocinio real de la dirección, se queda en documentación de cajón. La cláusula 5.1 de ISO 27001:2022 exige que la alta dirección demuestre liderazgo y compromiso «asegurando que los recursos necesarios para el SGSI estén disponibles» y «promoviendo la mejora continua». Esto no es una formalidad que se resuelve con una firma: es la diferencia entre un proyecto con presupuesto y prioridad, y uno que compite por atención con todo lo demás y pierde.
El rol del responsable del SGSI
Toda implantación necesita una persona con nombre y apellidos responsable del sistema, habitualmente llamada Responsable de Seguridad de la Información, SGSI Manager o, en organizaciones más grandes, reportando al CISO. Sus funciones típicas durante el proyecto:
- Interlocutor único con la dirección: traduce el estado del proyecto a lenguaje de negocio (riesgo, coste, plazo) y consigue las decisiones que solo la dirección puede tomar (alcance, apetito de riesgo, presupuesto).
- Coordinador del equipo de proyecto: no implanta el SGSI en solitario. Necesita representantes de IT, RRHH, legal/compliance, instalaciones y las áreas de negocio dentro del alcance.
- Propietario de la metodología: define cómo se va a hacer el análisis de riesgos, cómo se gestiona la documentación, cómo se mide el sistema.
- Responsable de la Declaración de Aplicabilidad: aunque la decisión final de aceptar riesgos es de la dirección, el responsable del SGSI prepara la justificación de cada control aplicado o excluido.
- Enlace con la entidad de certificación cuando llega el momento de auditar.
En una pyme, esta persona puede compaginar el rol con otras funciones (responsable de IT, por ejemplo) o puede ser un consultor externo con un ISO 27001 Lead Implementer que lidera el proyecto y forma a una persona interna para que asuma la continuidad tras la certificación. Lo que no funciona es que el rol quede difuso entre varias personas sin ninguna con autoridad y tiempo dedicado real.
Equipo de proyecto y comité de seguridad
Un equipo de proyecto mínimo viable incluye: el responsable del SGSI (líder), un patrocinador ejecutivo (dirección general o un miembro del comité de dirección), un representante técnico de IT/infraestructura, y un representante de cada área de negocio significativa dentro del alcance. Para organizaciones medianas y grandes, este equipo evoluciona tras la certificación en el comité de seguridad que revisa periódicamente el sistema —lo tratamos con detalle en el Módulo 2 de este curso.
Factores de éxito del proyecto
| Factor | Por qué es determinante |
|---|---|
| Patrocinio ejecutivo real | Sin presupuesto y autoridad para exigir colaboración a otras áreas, el proyecto se estanca en la fase de recogida de información. |
| Alcance realista | Un alcance mal calibrado (Paso 2) condiciona todo lo que viene después: cuanto antes se corrija, menos coste hundido. |
| Dedicación de tiempo, no solo presupuesto | El SGSI consume horas de personas que ya tienen su trabajo diario. Si no se planifica esa dedicación, el proyecto se retrasa de forma crónica. |
| Empezar a operar pronto | Cuanto antes se implanten controles y se generen evidencias, antes arranca el «reloj» de los meses de operación necesarios antes de poder auditar (Paso 11). |
| Comunicación y formación desde el inicio | Un SGSI que el personal no conoce ni entiende no genera evidencias de funcionamiento real, por muy bien documentado que esté. |
Paso 1 — Compromiso de la dirección y equipo del proyecto
Antes de escribir un solo documento, el proyecto necesita tres decisiones formales de la dirección: (1) aprobar el inicio del proyecto y su presupuesto, (2) nombrar al responsable del SGSI con autoridad explícita, y (3) fijar el objetivo de negocio del proyecto —¿por qué se implanta el SGSI? ¿exigencia de un cliente, requisito de un pliego público, diferenciación comercial, gestión de riesgo real tras un incidente?—. Este objetivo condiciona decisiones posteriores, empezando por el alcance.
La política de seguridad de la información de alto nivel (cláusula 5.2) se redacta y aprueba en esta fase inicial: es el documento que fija el compromiso de la organización y sirve de paraguas para toda la documentación posterior. No hace falta que sea extensa —una o dos páginas son suficientes en la mayoría de pymes— pero debe estar aprobada por la dirección y comunicada desde el primer día.
Paso 2 — Definir el alcance del SGSI
El alcance (cláusula 4.3 de ISO 27001:2022) es la decisión más importante del proyecto y la que más veces se hace mal. Define qué procesos, ubicaciones, servicios, activos y personas del alcance quedan cubiertos por el SGSI —y, por omisión, cuáles quedan fuera—.
Qué debe determinar el alcance
La cláusula 4.3 exige que, al establecer el alcance, la organización considere:
- Las cuestiones internas y externas relevantes (cláusula 4.1): cultura organizativa, marco regulatorio, mercado, dependencias tecnológicas.
- Los requisitos de las partes interesadas (cláusula 4.2): clientes, reguladores, accionistas, empleados.
- Las interfaces y dependencias entre lo que hace la propia organización y lo que realizan terceros o proveedores externos. Este punto es el que más se olvida: si un servicio dentro del alcance depende de un proveedor cloud, un partner de desarrollo o un centro de datos externo, esa dependencia debe quedar identificada y gestionada (aunque el proveedor en sí no esté «dentro» del SGSI).
El resultado debe documentarse como información disponible (es uno de los documentos obligatorios que veremos en el Paso 6) y debe ser lo suficientemente concreto para que un auditor —y cualquier empleado— pueda saber sin ambigüedad qué entra y qué no.
El error de un alcance mal definido
Hay dos formas de equivocarse, y ambas son frecuentes:
- Alcance demasiado amplio: incluir toda la organización, todas las ubicaciones y todos los sistemas «para no dejar nada fuera» multiplica el trabajo de análisis de riesgos, de documentación y de recogida de evidencias. En pymes con recursos limitados, esto suele traducirse en plazos que se disparan o en documentación superficial que no resiste una auditoría real.
- Alcance recortado «para aprobar fácil»: el error contrario, y comercialmente más peligroso. Excluir del alcance el servicio, el producto o la ubicación que precisamente le interesa a tu cliente o regulador deja un certificado que no sirve para lo que se necesitaba. Es habitual ver certificados ISO 27001 con un alcance tan estrecho («el desarrollo del producto X en la oficina de Madrid») que no cubre ni el dato que el cliente quería proteger ni la infraestructura que realmente lo procesa. Cuando esto se descubre en un proceso de due diligence de un cliente grande, el certificado pierde todo su valor comercial de un plumazo.
La regla práctica: el alcance debe cubrir exactamente los procesos, activos y ubicaciones que generan el riesgo que se quiere gestionar y que las partes interesadas esperan ver protegido —ni más, ni menos—. Es preferible un alcance ajustado y ampliable en una futura revisión, que uno sobredimensionado desde el primer día o uno recortado que no convence a nadie.
Paso 3 — Gap analysis: análisis de brechas
Con el alcance fijado, el siguiente paso es comparar el estado actual de la organización con los requisitos de las cláusulas 4 a 10 de ISO 27001:2022 y con los controles de ISO 27002:2022 aplicables al alcance. El objetivo no es un ejercicio académico: es el documento que va a alimentar el plan de proyecto, priorizar recursos y estimar el esfuerzo real que queda por delante.
Cómo se estructura
Un gap analysis eficaz recorre metódicamente las cláusulas 4-10 y, para el alcance definido, también revisa los 93 controles del Anexo A uno a uno (aunque en esta fase todavía no se decide formalmente cuáles se excluyen —eso llega con la Declaración de Aplicabilidad en el Paso 5—). Para cada requisito o control se documenta:
- Requisito: la cláusula o el control concreto de la norma.
- Estado actual: qué existe hoy en la organización, aunque sea informal o parcial (no vale con «no existe» sin más: hay que verificarlo con evidencia, no dar por hecho lo que alguien dice de memoria).
- Brecha: la diferencia concreta entre lo que exige la norma y lo que hay.
- Acción: qué hay que hacer para cerrar la brecha, con una estimación de esfuerzo y, si es posible, un responsable propuesto.
Ejemplo de tabla de gap analysis
| Requisito (cláusula/control) | Estado actual | Brecha | Acción |
|---|---|---|---|
| 4.3 — Alcance del SGSI | No existe documento formal de alcance | Falta definición documentada y aprobada | Redactar y aprobar el documento de alcance con la dirección |
| 5.2 — Política de seguridad | Existe un documento interno de 2021 sin revisar ni aprobar formalmente | Política desactualizada y sin aprobación formal vigente | Revisar, actualizar y hacer aprobar por la dirección; comunicar a toda la plantilla |
| 6.1.2 — Metodología de apreciación de riesgos | Análisis de riesgos ad hoc, sin metodología escrita ni criterios de aceptación | Falta metodología documentada y repetible | Definir metodología (escalas de probabilidad/impacto, criterios de aceptación) y aplicarla al alcance |
| A.5.15 — Control de acceso | Existen contraseñas individuales pero sin política de complejidad ni revisión periódica de permisos | Falta política formal y revisión periódica de accesos | Redactar política de control de acceso; implantar revisión trimestral de permisos |
| A.8.13 — Copias de seguridad | Backups automáticos diarios sin pruebas de restauración documentadas | No hay evidencia de que las copias sean recuperables | Definir calendario de pruebas de restauración y registrar resultados |
Este mismo formato de tabla —requisito, estado actual, brecha, acción— es el que retomamos en el caso práctico completo más abajo, aplicado a una pyme tecnológica real.
Paso 4 — Análisis y evaluación de riesgos
El núcleo del SGSI es el proceso de análisis de riesgos que se trató en detalle en los módulos de gestión de riesgos (M3 y M4) de este curso: identificación de activos, amenazas y vulnerabilidades, cálculo de probabilidad e impacto, y evaluación frente a los criterios de aceptación de riesgo definidos por la dirección. En el contexto del proyecto de implantación, esta fase tiene tres particularidades a tener en cuenta:
- Se ejecuta sobre el alcance ya definido en el Paso 2: analizar riesgos antes de fijar el alcance, o sobre un alcance distinto al que finalmente se certificará, obliga a repetir trabajo.
- La metodología debe quedar documentada antes de aplicarla (es uno de los documentos obligatorios de la cláusula 6.1.2): escalas de probabilidad e impacto, umbrales de aceptación, quién aprueba el riesgo residual.
- El resultado —el informe de apreciación de riesgos— alimenta directamente el Paso 5: cada riesgo por encima del umbral de aceptación necesita una decisión de tratamiento, y esa decisión determina qué controles del Anexo A se seleccionan.
Es habitual que el gap analysis del Paso 3 y el análisis de riesgos de este paso se solapen en el tiempo: el gap analysis identifica carencias de proceso y documentación, mientras que el análisis de riesgos identifica y prioriza los riesgos concretos sobre los activos del alcance. Ambos convergen en el plan de tratamiento del riesgo.
Paso 5 — Declaración de Aplicabilidad y plan de tratamiento del riesgo
Con los riesgos evaluados, dos documentos cierran la fase de planificación:
- Declaración de Aplicabilidad (SoA, Statement of Applicability): para cada uno de los 93 controles de ISO 27002:2022, la organización decide si aplica o no, y justifica por qué. Los criterios de inclusión no son solo «este control mitiga un riesgo identificado»: también pueden aplicar por requisito legal, contractual o regulatorio, aunque el análisis de riesgos por sí solo no lo hubiera señalado como prioritario. La exclusión de un control también debe justificarse explícitamente —«no aplica porque no hay tratamiento de datos en la nube dentro del alcance», por ejemplo— y no puede usarse para eludir un control incómodo sin fundamento.
- Plan de tratamiento del riesgo: traduce cada decisión de tratamiento (mitigar, transferir, aceptar, evitar) en acciones concretas, con responsable, plazo y recursos. Es el documento que conecta el análisis de riesgos con la ejecución real: sin él, la SoA queda en una lista de intenciones.
Ambos documentos requieren aprobación explícita de la dirección, incluida la aceptación formal del riesgo residual —lo que quede sin mitigar tras aplicar los controles seleccionados—. Esta aprobación es uno de los puntos que un auditor de certificación revisa con más atención: si el riesgo residual no está aceptado por alguien con autoridad real para hacerlo, el SGSI tiene una brecha de gobernanza, no solo documental.
Paso 6 — Documentación obligatoria del SGSI
La cláusula 7.5 de ISO/IEC 27001:2022 («Información documentada») no da una lista cerrada y única: exige que el SGSI incluya la información documentada requerida explícitamente por la propia norma en sus distintas cláusulas, más la que la organización determine necesaria para la eficacia del sistema. En la práctica, esto significa dos cosas: hay un núcleo de documentos y registros que la norma exige de forma inequívoca —porque cada cláusula dice literalmente «la organización debe mantener/conservar información documentada sobre…»— y, además, cada organización debe añadir lo que considere necesario según su tamaño, complejidad de procesos y competencia del personal (así lo indica expresamente la propia cláusula 7.5.1).
Documentos frente a registros
Antes de la lista, conviene fijar una distinción que la propia norma no nombra con esos términos exactos pero que es estándar en el sector y muy útil en la práctica:
- Documentos: describen cómo se hace algo o qué se ha decidido. Son relativamente estables, se revisan y versionan (una política, una metodología, un procedimiento).
- Registros: evidencian que algo se ha hecho. No se «versionan» en el mismo sentido —cada registro es un hecho puntual— y su gestión se centra en la conservación, la trazabilidad y la protección frente a alteración (un acta de revisión por la dirección, un registro de incidentes, una evidencia de formación completada).
Tabla de información documentada exigida por ISO/IEC 27001:2022
| Información documentada | Cláusula | Tipo |
|---|---|---|
| Alcance del SGSI | 4.3 | Documento |
| Política de seguridad de la información | 5.2 | Documento |
| Metodología de apreciación (análisis) de riesgos y criterios de aceptación | 6.1.2 | Documento |
| Informe de apreciación de riesgos | 8.2 | Registro |
| Plan de tratamiento de riesgos | 6.1.3 / 8.3 | Documento |
| Declaración de Aplicabilidad (SoA) | 6.1.3 d) | Documento |
| Objetivos de seguridad de la información y planes para alcanzarlos | 6.2 | Documento |
| Evidencia de la competencia del personal relevante para el SGSI | 7.2 | Registro |
| Resultados del seguimiento y la medición del SGSI | 9.1 | Registro |
| Programa de auditoría interna y resultados de las auditorías | 9.2.2 | Documento + Registro |
| Evidencia de los resultados de la revisión por la dirección | 9.3.3 | Registro |
| Naturaleza de las no conformidades y acciones correctivas tomadas, y resultados de esas acciones | 10.2 | Registro |
| Información documentada adicional que la organización determine necesaria para la eficacia del SGSI (procedimientos operativos críticos, criterios de riesgo, controles del Anexo A implementados, etc.) | 7.5.1 b) | Documento / Registro (según el caso) |
Un matiz importante que a veces se pasa por alto: además de esta información documentada exigida explícitamente por las cláusulas 4-10, la Declaración de Aplicabilidad remite a las notas de implementación de los controles del Anexo A seleccionados, y varios de esos controles llevan asociados sus propios registros (por ejemplo, A.5.15 control de acceso conlleva registros de revisión de permisos; A.8.13 copias de seguridad conlleva registros de pruebas de restauración). Estos no aparecen en la tabla de cláusulas 4-10 porque dependen de qué controles resulten aplicables según la SoA de cada organización, pero son igualmente exigibles una vez que el control está en el alcance del SGSI.
Nota de rigor: si tu organización necesita el listado literal cláusula por cláusula para uso interno o para un auditor, contrástalo siempre contra el texto oficial de ISO/IEC 27001:2022 adquirido a través de AENOR o de ISO —esta tabla resume su contenido con fines formativos pero no sustituye a la norma original, que es la única referencia vinculante en una auditoría de certificación.
Paso 7 — Gestión documental del SGSI
La cláusula 7.5.3 exige que la información documentada esté controlada para asegurar que está disponible y es adecuada para su uso, y que está protegida de forma adecuada (por ejemplo, frente a pérdida de confidencialidad, uso inadecuado o pérdida de integridad). En la práctica, esto se traduce en un procedimiento de control documental que cubra, como mínimo:
- Control de versiones: cada documento debe tener un identificador de versión, fecha y autor, con un historial de cambios que permita saber qué se modificó y por qué respecto a la versión anterior.
- Aprobación: antes de publicarse o entrar en vigor, cada documento pasa por un circuito de revisión y aprobación por la persona con autoridad adecuada (la política de seguridad, por ejemplo, la aprueba la dirección; un procedimiento técnico puede aprobarlo el responsable del área correspondiente).
- Distribución: que el personal afectado tenga acceso a la versión vigente —y solo a esa versión— es tan importante como que el documento exista. Un repositorio único con control de acceso (intranet, gestor documental, incluso una carpeta compartida bien gestionada en organizaciones pequeñas) evita el problema clásico de versiones desactualizadas circulando por correo electrónico.
- Protección: control de acceso a los documentos según su clasificación (no toda la documentación del SGSI debe ser visible para toda la plantilla: el informe de riesgos, por ejemplo, suele tener una difusión restringida), copias de seguridad del repositorio documental, y prevención de cambios no autorizados.
- Conservación y eliminación: cuánto tiempo se conservan los registros (por ejemplo, los de auditoría interna o los de incidentes) y cómo se eliminan de forma segura cuando corresponde.
Para organizaciones pequeñas, un procedimiento de control documental de una o dos páginas, apoyado en una plantilla estándar de cabecera (versión, fecha, autor, aprobador) y un repositorio con permisos bien definidos, es suficiente para cumplir la cláusula 7.5.3 sin necesidad de invertir en software especializado de gestión documental.
Plantilla de índice documental
SGSI - INDICE DOCUMENTAL
=========================
01. GOBERNANZA
01.01 Politica de seguridad de la informacion (v.)
01.02 Alcance del SGSI (v.)
01.03 Roles y responsabilidades / RACI seguridad (v.)
02. RIESGOS
02.01 Metodologia de apreciacion de riesgos (v.)
02.02 Informe de apreciacion de riesgos <periodo> (registro)
02.03 Plan de tratamiento de riesgos (v.)
02.04 Declaracion de Aplicabilidad - SoA (v.)
03. OBJETIVOS Y SOPORTE
03.01 Objetivos de seguridad <anio> (v.)
03.02 Plan de formacion y concienciacion (v.)
03.03 Registro de competencia del personal (registro)
04. OPERACION - PROCEDIMIENTOS
04.01 Procedimiento de control de acceso
04.02 Procedimiento de copias de seguridad y restauracion
04.03 Procedimiento de gestion de incidentes de seguridad
04.04 Procedimiento de gestion de cambios
04.05 [uno por cada control del Anexo A con SoA = Aplica]
05. EVALUACION DEL DESEMPENO
05.01 Cuadro de indicadores (KPI/KRI) <periodo> (registro)
05.02 Programa de auditoria interna (v.)
05.03 Informe de auditoria interna <fecha> (registro)
05.04 Acta de revision por la direccion <fecha> (registro)
06. MEJORA
06.01 Registro de no conformidades y acciones correctivas (registro)
(v.) = documento versionado sujeto a control de cambios
(registro) = evidencia puntual, no se versiona, se conserva
Paso 8 — Implantar los controles seleccionados
Con la SoA aprobada, empieza la fase de ejecución real: cada control marcado como aplicable debe implementarse, no solo describirse en un documento. Esta fase suele ser la más larga del proyecto porque implica cambios operativos —configuraciones técnicas, nuevos procedimientos, cambios de proveedor, adquisición de herramientas— que compiten con las prioridades del día a día de cada área.
Para los controles tecnológicos, no basta con la palabra de quien los implementó: la evidencia de eficacia más sólida es una verificación técnica independiente. Si dentro del alcance hay aplicaciones web propias (como la plataforma SaaS del caso práctico más abajo), una prueba de intrusión con la metodología de hacking web antes de cerrar esta fase aporta una evidencia de eficacia mucho más convincente ante un auditor que la simple existencia de un procedimiento de desarrollo seguro.
Prioriza siempre los controles vinculados a los riesgos más altos del análisis del Paso 4 y a los requisitos legales o contractuales que hayan motivado el proyecto. Documenta cada control implementado con el detalle suficiente para que sirva de evidencia en la auditoría: no basta con «tenemos backups», hace falta el procedimiento, el calendario y los registros de ejecución. Los controles con componente técnico transversal (gestión de accesos, gestión de vulnerabilidades, segmentación de red, gestión de proveedores) suelen requerir coordinación con el equipo de infraestructura y Active Directory, especialmente en organizaciones donde el directorio activo es la base del control de identidad y acceso.
Paso 9 — Formación y concienciación del personal
La cláusula 7.2 (competencia) y la cláusula 7.3 (toma de conciencia) de ISO 27001:2022 no son requisitos opcionales ni un anexo simbólico: exigen que el personal cuyo trabajo afecta al desempeño del SGSI sea competente en base a educación, formación o experiencia adecuada, y que todo el personal bajo el control de la organización sea consciente de la política de seguridad, de su contribución a la eficacia del SGSI y de las implicaciones de no cumplir los requisitos.
En la práctica de un proyecto de implantación, esto se traduce en un plan de formación con al menos tres niveles:
- Concienciación general para toda la plantilla: qué es el SGSI, por qué existe, qué se espera de cada persona (identificar phishing, reportar incidentes, no compartir credenciales, clasificación básica de la información). Debe repetirse periódicamente, no ser un evento único al lanzar el proyecto.
- Formación específica para roles con responsabilidades directas sobre controles (administradores de sistemas, RRHH en el proceso de altas/bajas, responsables de proveedores).
- Formación de competencia técnica para quien opera el SGSI (el responsable de seguridad, el equipo de IT en materias como respuesta a incidentes).
Cada acción formativa debe dejar evidencia —asistencia, resultado de un test de comprensión, fecha— porque es información documentada exigida por la cláusula 7.2. Un SGSI que se salta esta fase, o la reduce a un correo con la política adjunta, no genera la evidencia de eficacia que un auditor de certificación exige, y expone a la organización a incidentes evitables por error humano, que sigue siendo la causa más frecuente de brechas de seguridad en cualquier sector.
Paso 10 — Métricas e indicadores
La cláusula 9.1 exige que la organización evalúe el desempeño de la seguridad de la información y la eficacia del SGSI, determinando qué necesita seguimiento y medición, con qué métodos, cuándo, quién lo hace y cuándo se analizan y evalúan los resultados. Sin métricas, no hay forma de demostrar —ni de saber internamente— si el sistema funciona.
Un cuadro de indicadores mínimo viable para una implantación inicial suele incluir:
- Porcentaje de riesgos del registro que tienen plan de tratamiento activo y al día.
- Número de incidentes de seguridad registrados por periodo y tiempo medio de resolución.
- Porcentaje de personal que ha completado la formación de concienciación obligatoria.
- Cobertura de parcheo / gestión de vulnerabilidades críticas dentro del plazo definido.
- Resultado de las pruebas de restauración de copias de seguridad.
- Número de no conformidades abiertas y cerradas, y tiempo medio de cierre.
- Grado de avance de las acciones del plan de tratamiento de riesgos.
Los indicadores deben revisarse en el comité de seguridad y alimentar directamente la revisión por la dirección del Paso 11. No hace falta un cuadro de mando sofisticado desde el primer día: una hoja de cálculo con revisión trimestral bien disciplinada cumple el requisito con creces en una pyme, y es preferible a una herramienta compleja que nadie actualiza.
Paso 11 — Operar el SGSI antes de certificar
Este es el paso que más proyectos subestiman. Un SGSI recién documentado e implementado no está listo para auditoría de certificación: la norma exige evidencia de que el sistema funciona, no solo de que existe sobre el papel. Eso requiere un periodo de operación real —habitualmente varios meses— durante el cual se acumulan las evidencias que un auditor va a pedir: registros de incidentes gestionados, resultados de monitorización, formación completada, revisiones de acceso ejecutadas, backups probados.
El procedimiento de gestión de incidentes (A.5.24-A.5.28 del Anexo A) es, en la práctica, uno de los que más evidencia genera durante este periodo: cada incidente real gestionado —desde un phishing detectado hasta una alerta de seguridad menor— deja registro de detección, análisis, contención y lecciones aprendidas. Contar con un proceso de respuesta a incidentes (DFIR) ya maduro antes de esta fase no solo reduce el impacto real de los incidentes que ocurran: también es la fuente de evidencia más directa de que el SGSI opera, no solo que existe.
Antes de la auditoría de certificación (que se trata en detalle en el Módulo 8 de este curso), deben completarse dos actividades obligatorias según la propia norma:
- Auditoría interna (cláusula 9.2): la organización verifica, por sí misma o con apoyo externo independiente del equipo que implementó el SGSI, que el sistema cumple los requisitos propios de la organización y los de la norma, y que está implementado y mantenido de forma eficaz.
- Revisión por la dirección (cláusula 9.3): la alta dirección revisa el SGSI a intervalos planificados —al menos una vez antes de la certificación inicial— cubriendo el estado de acciones de revisiones previas, cambios en cuestiones internas/externas, desempeño del SGSI (no conformidades, resultados de auditoría, indicadores, riesgo), retroalimentación de partes interesadas, adecuación de recursos y oportunidades de mejora.
Solo con al menos un ciclo completo de auditoría interna y revisión por la dirección resueltos, y con las evidencias de operación acumuladas, tiene sentido agendar la auditoría de certificación fase 1 y fase 2. Presentarse antes es la causa más común de no conformidades mayores en primera auditoría.
Cronograma tipo de un proyecto de implantación
| Fase | Mes (aprox.) | Entregables clave |
|---|---|---|
| Compromiso, equipo y alcance | 1 | Aprobación de dirección, nombramiento del responsable del SGSI, documento de alcance, política de seguridad |
| Gap analysis | 1-2 | Informe de brechas, plan de acción priorizado |
| Análisis de riesgos | 2-3 | Metodología, inventario de activos, informe de apreciación de riesgos |
| SoA y plan de tratamiento | 3-4 | Declaración de Aplicabilidad aprobada, plan de tratamiento con responsables y plazos |
| Implantación de controles | 4-8 | Procedimientos, controles técnicos y organizativos operativos |
| Formación y concienciación | 4-9 (continua) | Plan de formación ejecutado, registros de asistencia |
| Documentación e indicadores | 5-9 | Documentación obligatoria completa, cuadro de indicadores en marcha |
| Operación con evidencias | 9-13 | Registros de incidentes, revisiones de acceso, backups probados, no conformidades gestionadas |
| Auditoría interna | 12-13 | Informe de auditoría interna con no conformidades cerradas o en plan |
| Revisión por la dirección | 13 | Acta de revisión por la dirección |
| Auditoría de certificación (fase 1 y 2) | 14-15 | Certificado ISO 27001 (si procede) |
Este cronograma es orientativo para una pyme de complejidad media con un alcance razonablemente acotado: entre 12 y 15 meses desde el arranque hasta la certificación. Organizaciones muy pequeñas con alcance muy reducido y buena dedicación pueden completarlo en 8-9 meses; organizaciones grandes o con alcances complejos (múltiples ubicaciones, múltiples servicios, dependencias fuertes de terceros) pueden necesitar 18 meses o más. El punto que no se puede comprimir por mucho presupuesto que se invierta es el periodo mínimo de operación con evidencias del Paso 11: no existe un atajo documental para demostrar que un sistema lleva funcionando un tiempo razonable.
Caso práctico
Empresa ejemplo: NublaSoft, S.L., una pyme tecnológica española de 35 empleados que desarrolla y opera una plataforma SaaS de gestión de proyectos para clientes del sector financiero y de administración pública. Un cliente grande del sector bancario ha condicionado la renovación de su contrato a que NublaSoft certifique ISO 27001 en un plazo de 12 meses.
Definición del alcance
El comité de dirección, con el responsable de seguridad recién nombrado, decide el siguiente alcance:
«El Sistema de Gestión de Seguridad de la Información de NublaSoft, S.L. cubre el diseño, desarrollo, despliegue y operación de la plataforma SaaS «ProyectaNube» y de los servicios de soporte asociados, incluyendo las oficinas de Valencia (sede única) y la infraestructura cloud contratada en un proveedor de infraestructura como servicio (IaaS) europeo. Quedan dentro del alcance los procesos de desarrollo de software, gestión de infraestructura, atención al cliente y gestión de recursos humanos en lo relativo al ciclo de vida del personal con acceso a los sistemas de producción. Quedan fuera del alcance las líneas de negocio de consultoría puntual no relacionadas con ProyectaNube y la actividad comercial previa al cierre de contrato.»
Este alcance evita los dos errores típicos: no se limita a «la oficina de Valencia» (que dejaría fuera la infraestructura cloud, precisamente donde vive el riesgo real que le importa al cliente bancario), ni se extiende a líneas de negocio irrelevantes para el contrato que motiva la certificación. Las interfaces con el proveedor IaaS quedan explícitamente identificadas como dependencia externa a gestionar mediante el control de proveedores, no como parte directa del SGSI.
Primeras cinco filas del gap analysis de NublaSoft
| Requisito (cláusula/control) | Estado actual | Brecha | Acción |
|---|---|---|---|
| 4.3 — Alcance del SGSI | Sin documento; se conoce informalmente qué cubre «el producto» | Falta documento formal aprobado por dirección | Redactar y aprobar el documento de alcance descrito arriba; comunicarlo al equipo |
| 6.1.2 / 8.2 — Metodología y apreciación de riesgos | Nunca se ha hecho un análisis de riesgos formal; existe un backlog técnico de «cosas a arreglar» sin priorizar por riesgo | No hay metodología ni inventario de activos ni informe de riesgos | Definir metodología (escalas 1-5, matriz probabilidad×impacto), inventariar activos del alcance (código fuente, BD clientes, credenciales de infraestructura, backups) y ejecutar el primer análisis |
| A.8.9 — Gestión de la configuración | Infraestructura desplegada manualmente por el equipo de DevOps sin plantillas versionadas (IaC) | Configuraciones no documentadas ni reproducibles; riesgo de desviación no detectada | Migrar la infraestructura crítica a plantillas de Infraestructura como Código versionadas en el repositorio con revisión de cambios |
| A.5.19 — Seguridad en las relaciones con proveedores | Contrato con el proveedor IaaS firmado sin cláusulas específicas de seguridad ni SLA de notificación de incidentes | Falta evaluación y cláusulas contractuales de seguridad con el proveedor cloud | Revisar el contrato, incorporar anexo de seguridad (notificación de incidentes, ubicación de datos, derecho de auditoría) y documentar la evaluación del proveedor |
| 7.2 / 7.3 — Competencia y toma de conciencia | No existe programa de formación en seguridad; el onboarding solo cubre aspectos de producto | Personal sin formación en seguridad ni conciencia de sus responsabilidades en el SGSI | Diseñar plan de concienciación general (todo el personal) y formación específica para DevOps y soporte; ejecutar primera sesión en el mes 1 |
Con estas cinco filas ya se aprecia el patrón habitual en una pyme tecnológica: el mayor volumen de brechas suele concentrarse en la falta de documentación y formalización de prácticas que en parte ya existen de forma informal (hay backups, hay control de acceso básico, hay un proveedor cloud razonable), más que en la ausencia total de medidas técnicas. El gap analysis completo de NublaSoft continuaría recorriendo el resto de cláusulas y los 93 controles aplicables al alcance definido.
Errores comunes
- Alcance mal definido: ya visto en el Paso 2, es el error que más contamina el resto del proyecto. Revisarlo y corregirlo en el primer mes es barato; descubrir en la auditoría de certificación que el alcance no cubre lo que el cliente necesitaba es carísimo, tanto en tiempo como en credibilidad.
- Documentar sin operar: escribir políticas y procedimientos impecables que nadie sigue en el día a día. Un auditor de certificación no audita documentos aislados: pide evidencias de que lo escrito se cumple. Una política de control de acceso perfecta sin registros de revisión de permisos es papel, no un control operativo.
- Saltarse la concienciación: tratar la formación como un correo con la política adjunta en lugar de un programa con evidencia. Además de ser una no conformidad casi garantizada en auditoría, es la puerta de entrada más común para incidentes reales (phishing, ingeniería social, errores de manipulación de información).
- Querer certificar sin evidencias suficientes: presentarse a la auditoría de certificación a los dos o tres meses de haber implantado los controles, sin el periodo de operación real del Paso 11. El resultado casi seguro son no conformidades mayores por falta de evidencia de eficacia, que obligan a repetir fases de la auditoría y retrasan la certificación más de lo que se hubiera tardado esperando el tiempo necesario desde el principio.
- Tratar la SoA como un trámite: copiar una Declaración de Aplicabilidad genérica de internet sin que refleje el análisis de riesgos real de la organización. Un auditor experimentado detecta rápidamente una SoA que no está conectada con el informe de riesgos y con el contexto real del negocio.
- No planificar la dedicación de tiempo interno: aprobar presupuesto para consultoría externa mientras se asume, sin decirlo explícitamente, que el personal interno dedicará «el tiempo que le sobre» al proyecto. Sin horas protegidas en el calendario de las personas clave, los plazos se incumplen de forma sistemática.
Ejercicio
Elige una organización real que conozcas bien —tu empresa actual, una anterior, o una pyme de tu entorno cercano si trabajas de forma autónoma— y completa los siguientes puntos como si fueras el responsable de seguridad recién nombrado para liderar su proyecto de implantación de ISO 27001:
- Redacta el alcance del SGSI en un párrafo, siguiendo el modelo del caso práctico: qué procesos, ubicaciones, servicios y activos entran, qué dependencias externas (proveedores, infraestructura) hay que identificar, y qué queda explícitamente fuera y por qué.
- Identifica tres riesgos de que el alcance esté mal calibrado: ¿hay algo que se te ocurra excluir «para simplificar» que en realidad es donde vive el riesgo que le importa a tus clientes o reguladores?
- Construye una tabla de gap analysis con al menos ocho filas, cubriendo al menos dos cláusulas de gobernanza (4-7), dos de riesgo (6, 8), y cuatro controles del Anexo A relevantes para tu organización (elige controles organizacionales, de personas, físicos y tecnológicos según lo que sepas del estado real de la organización).
- Marca en un calendario los 12-15 meses del cronograma tipo adaptado a tu caso: ¿qué meses te parecen razonables para cada fase según los recursos reales que esa organización podría dedicar?
- Enumera qué documentos de la tabla del Paso 6 ya existen (aunque sea de forma informal o incompleta) en esa organización, y cuáles habría que crear desde cero.
Preguntas frecuentes
¿Cuánto cuesta realmente implantar un SGSI en una pyme, más allá del coste de la auditoría de certificación?
El coste de la auditoría de certificación en sí (la que factura la entidad certificadora) suele ser una parte relativamente pequeña del coste total. El grueso está en las horas de consultoría (si se contrata apoyo externo), las horas internas dedicadas por el equipo durante 9-15 meses, y la inversión en controles técnicos que puedan faltar (herramientas de gestión de accesos, copias de seguridad, monitorización). Para una pyme española, el rango combinado de consultoría más certificación suele moverse entre 15.000 y 50.000 euros, como se indicó en el módulo de fundamentos de este curso, pero el coste de las horas internas —a menudo no contabilizado explícitamente— puede ser comparable o superior al de la consultoría.
¿Es obligatorio contratar un consultor externo o se puede implantar el SGSI solo con personal interno?
No es obligatorio. Muchas organizaciones con un responsable de seguridad competente (idealmente con una certificación como ISO 27001 Lead Implementer) implantan el SGSI enteramente con personal interno. La ventaja de un consultor externo es la experiencia acumulada en varios proyectos similares, que ayuda a evitar los errores comunes de este módulo y suele acelerar el proyecto. La decisión depende del tamaño de la organización, de si ya existe competencia interna en la materia, y del presupuesto disponible.
¿Qué pasa si en la auditoría interna se detectan no conformidades? ¿Hay que reiniciar el proyecto?
No. Detectar no conformidades en la auditoría interna es exactamente el comportamiento esperado del sistema —para eso existe la cláusula 9.2—. Lo que exige la norma es que esas no conformidades se gestionen con el proceso de la cláusula 10.2: análisis de causa, acción correctiva y verificación de que la acción fue eficaz. Presentarse a la auditoría de certificación con no conformidades de la auditoría interna ya cerradas (o con un plan de acción sólido para las que sigan abiertas y no sean críticas) es señal de un SGSI maduro, no un problema.
¿Puede una empresa muy pequeña (menos de 10 empleados) certificarse en ISO 27001?
Sí. ISO 27001 no fija un umbral mínimo de tamaño. La propia cláusula 7.5.1 reconoce explícitamente que el volumen de información documentada necesaria depende del tamaño de la organización y de la complejidad de sus procesos, lo que permite a una microempresa tener un SGSI proporcionalmente más ligero que el de una corporación, sin dejar de cumplir los mismos requisitos de fondo. Lo que no cambia con el tamaño es la necesidad de operar el sistema el tiempo suficiente para generar evidencia real antes de auditar.
¿La Declaración de Aplicabilidad se hace una sola vez o hay que revisarla?
Es un documento vivo. Debe revisarse cada vez que cambie el alcance, que se identifiquen nuevos riesgos relevantes, que cambien los requisitos legales o contractuales aplicables, o como mínimo con la periodicidad que defina la organización (habitualmente anual, coincidiendo con el ciclo de revisión por la dirección). Un SoA que no se ha tocado en varios años, mientras la organización ha cambiado de infraestructura o de proveedores, es una señal de alerta típica en auditorías de seguimiento.
«La organización debe determinar la información documentada necesaria para la eficacia del sistema de gestión de seguridad de la información» — ISO/IEC 27001:2022, ISO — International Organization for Standardization.