Workspace ISO 27001 ISMS: del alcance a la preparación para certificación en 19 pasos
Guía práctica para consultores GRC y equipos internos de seguridad sobre cómo usar el template de workspace ISO 27001 ISMS de Rakenne para construir un conjunto completo y coherente de documentación de ISMS — con validación asistida por herramientas en cada paso.
Construir un ISMS compatible con ISO 27001 implica mucha documentación. Una primera certificación para una empresa mediana suele requerir entre 6 y 12 meses de esfuerzo de consultoría, con más del 60% del tiempo dedicado a producción documental, análisis de riesgos, evaluación de brechas y verificación cruzada de requisitos contra controles. El cuello de botella rara vez es “escribir texto”: es traducir operaciones reales (desordenadas) en documentación auditable, coherente internamente y alineada por cláusula.
El template de workspace ISO 27001 ISMS de Rakenne ofrece 19 skills especializadas y más de 55 herramientas de validación que guían a un agente LLM a lo largo de todo el ciclo PDCA. Cada skill impone un flujo estructurado, carga referencias específicas de ISO y usa herramientas deterministas para comprobar la salida del agente — capturando los tipos de errores que el drafting genérico con LLM suele pasar por alto: cláusulas obligatorias faltantes, puntuaciones de riesgo inconsistentes, controles huérfanos, registros CAPA incompletos y inconsistencias entre documentos donde un artefacto contradice a otro.
Esta guía recorre las 19 skills en secuencia, muestra extractos reales de diálogo y salidas de herramientas de una sesión en vivo, y explica por qué la documentación de ISMS asistida por herramientas es materialmente mejor que el drafting genérico con IA.
Por qué los LLM “puros” se quedan cortos para ISO 27001
Un LLM genérico como ChatGPT puede redactar políticas, procedimientos y enunciados de riesgo. Donde falla es en la validación a nivel de cumplimiento:
| Aspecto | LLM puro | Rakenne con skills ISO 27001 |
|---|---|---|
| Completitud por cláusula | Puede omitir requisitos obligatorios | Escanea el workspace en busca de artefactos obligatorios y señala brechas |
| Trazabilidad riesgo–control | Débil sin estado estructurado | Obliga vínculos entre registro de riesgos, SoA y plan de tratamiento |
| Consistencia entre documentos | Las contradicciones entre documentos pasan desapercibidas | 11 verificaciones de trazabilidad entre documentos detectan inconsistencias en todos los artefactos del ISMS — desde el alcance hasta políticas y registro CAPA |
| Proceso repetible | La salida varía según el prompt | Cada skill define un flujo fijo; se ejecutan los mismos checks siempre |
| Autocorrección | El modelo puede “afirmar” cobertura sin entregarla | Las herramientas devuelven PASS/FAIL; el agente revisa hasta que pase |
La diferencia es estructural: las skills le dan al agente una especificación (workflow + referencias + estructura) y herramientas (checks deterministas) para verificar su propia salida. Eso es lo que transforma un borrador en un artefacto auditable.
El recorrido del ISMS en 19 pasos
El template de workspace instala 19 skills que se alinean con el ciclo PDCA de ISO 27001:
| Fase | Paso | Skill | Qué se valida |
|---|---|---|---|
| Plan | 1 | Organization Profile | Clasificación del stack tecnológico, completitud del perfil |
| Plan | 2 | ISMS Scope | Integridad de límites del alcance, justificaciones de exclusión, análisis de impacto downstream |
| Plan | 3 | Asset Inventory | Consistencia de etiquetado de activos, accountability del owner |
| Plan | 4 | Risk Assessment | Cumplimiento metodológico, completitud de registros, detección de duplicados, mapeo riesgo–control, umbrales de riesgo residual, cobertura activo–riesgo |
| Plan | 5 | Statement of Applicability | Sugerencias de inclusión de controles, auditoría de justificaciones, consistencia SoA–riesgo, validación de evidencias de políticas, seguimiento del estado de implementación |
| Plan | 6 | Gap Assessment | Detección de artefactos obligatorios, cobertura de requisitos por cláusula, rating de madurez, priorización de remediación, dashboard de trazabilidad del ISMS |
| Do | 7 | Policy Generator | Selección de plantilla, metadatos del documento, cobertura de temas obligatorios, trazabilidad tratamiento–política (16 tipos de documentos) |
| Do | 8 | Physical Security Perimeter | Controles de prevención de tailgating |
| Do | 9 | Supplier Security Policy | Generación de cláusulas por tier, refuerzo de derecho de auditoría |
| Do | 10 | Legal Requirements Register | Identificación de obligaciones legales, regulatorias y contractuales, mapeo a controles del Anexo A |
| Do | 11 | Confidentiality & NDA Agreements | Plantillas de NDA por escenario, registro de seguimiento de acuerdos |
| Do | 12 | Operating Procedures (SOPs) | Procedimientos paso a paso, trazabilidad a controles del Anexo A, índice de SOPs |
| Do | 13 | Secure Architecture Principles | Catálogo de principios de ingeniería segura, aplicabilidad por stack tecnológico |
| Do | 14 | Awareness & Training Plan | Audiencias objetivo, módulos de formación, calendario, métricas de efectividad |
| Check | 15 | Monitoring & Evaluation | Generación de KPI, Registro de Objetivos de SI, objectives_completeness_checker, completitud de CAPA, seguimiento de acciones correctivas, reconciliación NC de auditoría–CAPA |
| Do | 16 | Business Continuity Plan | BIA, secuencias de recuperación RTO/RPO, procedimientos de failover, registros de ejercicios |
| Check | 17 | Internal Audit Report | Imparcialidad del auditor, completitud de hallazgos, clasificación de severidad |
| Act | 18 | Management Review | Cobertura de entradas obligatorias, compilación del “input pack”, completitud de acciones |
| Act | 19 | Executive Readiness Report | Resumen ejecutivo para dirección, scoring de preparación por área, brechas críticas, timeline a auditoría |
Cada skill lee archivos del workspace producidos en pasos anteriores — el perfil de la organización alimenta el alcance, el alcance alimenta la evaluación de riesgos, la evaluación alimenta la SoA, y así sucesivamente. Toda la cadena es trazable.
Paso 1: Organization Profile — la base que todo lo demás reutiliza
Toda iniciativa ISO 27001 empieza por entender la organización. La skill Organization Profile captura hechos estructurados — razón social, tamaño, ubicaciones, stack tecnológico, obligaciones regulatorias, personal clave — en un archivo de perfil reutilizable.
Tú: CloudSync Solutions es una empresa SaaS B2B con base en São Paulo, 45 empleados. Corremos en GCP, usamos GitHub, Google Workspace, Okta para IAM, Stripe para pagos y SendGrid para email. Maria Santos es CISO, João Silva es CTO. Procesamos datos de proyectos de clientes y estamos sujetos a LGPD.
Agente: He redactado el perfil de la organización. Voy a ejecutar el clasificador de stack tecnológico y el verificador de completitud del perfil.
El clasificador categorizó 8 entradas: GCP como IaaS, GitHub como SaaS (DevOps), Google Workspace como SaaS (Productividad), Okta como SaaS (Seguridad/IAM). Un flag — AWS CloudFront aparece sin especificación de región.
Completitud del perfil: PASS (92%). Brecha menor: el rango de facturación es estimado — considera confirmarlo con finanzas.
También actualicé el dashboard del proyecto para marcar Organization Profile como completo.
Paso 2: ISMS Scope — delimitar fronteras defendibles
La skill ISMS Scope define qué partes de la organización, procesos, ubicaciones y sistemas están dentro del alcance de certificación — y, de forma crítica, justifica cualquier exclusión. Lee el perfil de la organización y produce una declaración de alcance que un auditor puede trazar hasta la Cláusula 4.3.
Tú: Define el alcance del ISMS para CloudSync Solutions. Nuestra plataforma SaaS y la infraestructura de soporte deben estar en alcance. Sistemas de marketing y RR. HH. quedan fuera.
Agente: He redactado la declaración de alcance basada en tu Organization Profile. Voy a ejecutar las verificaciones de frontera de alcance y exclusiones.
Integridad de frontera de alcance: PASS. El alcance cubre la plataforma SaaS, infraestructura en GCP, procesamiento de datos de clientes y todos los servicios TI de soporte. Las fronteras quedan claramente definidas por unidad organizativa, ubicación (HQ São Paulo + regiones GCP) y tecnología.
Verificación de justificación de exclusiones: WARNING. Dos exclusiones necesitan una justificación más sólida. “Sistemas de marketing” se acepta — no procesan datos de clientes. Pero “RR. HH.” requiere aclaración: RR. HH. mantiene PII de empleados sujeta a LGPD, y la Cláusula 4.3 exige justificar por qué el tratamiento de datos de RR. HH. no afecta los objetivos del ISMS. Lo marqué para revisión y sugerí añadir una frase indicando que los datos de RR. HH. se gobiernan bajo un programa separado de cumplimiento LGPD.
La declaración de alcance se convierte en el ancla de todos los pasos posteriores: la evaluación de riesgos solo cubre activos en alcance, la SoA solo aborda controles en alcance, y el gap assessment verifica cobertura contra los límites definidos.
Cuando el alcance cambia más adelante (se abre una nueva oficina, se añade un proveedor cloud), el analizador de impacto de cambios de alcance escanea todos los documentos downstream — inventario de activos, registro de riesgos, SoA y políticas — y marca inconsistencias. Por ejemplo, si excluyes “oficina de Tokio” del alcance pero el inventario aún lista un “Servidor de archivos de la oficina de Tokio”, la herramienta lo detecta de inmediato.
Paso 3: Asset Inventory — lo que proteges debe estar nombrado
Antes de evaluar riesgos, el ISMS necesita un inventario completo de activos de información. La skill Asset Inventory cataloga activos por tipo (información, software, hardware, servicios, personas), asigna owners y valida la consistencia de etiquetado.
Tú: Construye el inventario de activos basado en nuestro perfil y alcance.
Agente: He identificado 18 activos de información dentro del alcance del ISMS y los clasifiqué por tipo. Voy a validar etiquetado y ownership.
Consistencia de etiquetado: PASS. Los 18 activos siguen la convención (prefijo de tipo + ID secuencial). Los niveles de clasificación (Confidencial, Interno, Público) se asignaron de forma consistente — datos de proyectos de clientes y claves API son Confidenciales; documentación interna es Interna.
Chequeo de accountability del owner: WARNING. Dos activos tienen owners a nivel de equipo (“Equipo de Ingeniería”) en lugar de personas identificadas. ISO 27001 A.5.9 requiere owners identificables. Marqué AST-011 (Pipeline CI/CD) y AST-014 (Dashboard de monitoreo) para reasignación a individuos concretos.
El inventario de activos alimenta directamente la evaluación de riesgos: cada riesgo debe referenciar un activo específico, y los activos huérfanos (sin riesgos asociados) se marcan para revisión.
Paso 4: Risk Assessment — donde la validación realmente paga
La evaluación de riesgos (Cláusula 6.1.2) es donde la validación asistida por herramientas marca la mayor diferencia. Un LLM puro puede listar riesgos, pero no puede verificar de forma fiable que cada riesgo tenga una cadena amenaza–vulnerabilidad–consecuencia, que los scores sigan la metodología definida, o que las decisiones de tratamiento mapeen a controles reales del Anexo A.
La skill Risk Assessment activa seis checks en secuencia:
- Cumplimiento metodológico — valida que se definan escalas de probabilidad/impacto, matriz de scoring y criterios de aceptación según la Cláusula 6.1.2
- Completitud de entrada — comprueba que cada riesgo tenga activo, amenaza, vulnerabilidad, consecuencia, scores, owner y decisión de tratamiento
- Detección de duplicados — identifica riesgos solapados o casi duplicados
- Cobertura activo–riesgo — cruza el inventario con el registro para verificar que los activos Confidenciales y Restringidos tengan entradas de riesgo
- Mapeo riesgo–control — asegura que todo riesgo tratado esté vinculado a controles específicos del Anexo A
- Umbral de riesgo residual — verifica que los scores post-tratamiento queden por debajo del umbral de aceptación
Tú: Basado en nuestro perfil y alcance, evalúa nuestros riesgos de seguridad de la información.
Agente: Identifiqué 7 riesgos y construí el registro con scoring probabilidad × impacto. Voy a ejecutar la suite de validación.
El verificador metodológico confirmó que los 11 requisitos de la Cláusula 6.1.2 están cubiertos — escalas, matriz y umbral de aceptación de 12 están correctamente definidos.
Cada una de las 7 entradas pasó validación de completitud: activo, amenaza, vulnerabilidad, consecuencia, scores P×I, owner y decisión de tratamiento están presentes.
El detector de duplicados no encontró solapamientos — los 7 riesgos cubren escenarios distintos.
El validador de cobertura activo–riesgo cruzó el inventario: 5 de 6 activos Confidenciales tienen riesgos correspondientes. Sin embargo, AST-008 (Bóveda de claves API) está clasificado como Confidencial y no tenía riesgo — añadí R-08 sobre extracción no autorizada de claves con score 4×5=20 (Tratar, controles A.5.17, A.8.24).
El mapeador riesgo–control verificó que los 8 riesgos tratados enlazan a controles del Anexo A. Y el verificador de riesgo residual confirmó que los scores post-tratamiento quedan por debajo del umbral 12.
Aquí tienes una muestra del registro de riesgos producido:
| ID | Activo | Amenaza | P | I | Score | Tratamiento | Controles |
|---|---|---|---|---|---|---|---|
| R-01 | Datos de proyectos de clientes | Acceso no autorizado | 3 | 5 | 15 | Tratar | A.5.15, A.5.18 |
| R-02 | Infraestructura cloud | Configuración incorrecta | 4 | 4 | 16 | Tratar | A.8.20, A.8.21 |
| R-06 | Plataforma SaaS | Vulnerabilidades en APIs | 4 | 5 | 20 | Tratar | A.8.25, A.8.26 |
Sin estas herramientas, el agente podría producir un registro “verosímil” pero con scores mal alineados, tratamientos huérfanos, o controles que no abordan realmente la amenaza. Las herramientas aplican los mismos checks lógicos que un consultor senior realizaría — automáticamente y de forma consistente.
Paso 5: Statement of Applicability — el puente entre riesgos y controles
La Statement of Applicability (SoA) es uno de los documentos más auditados en ISO 27001. Lista los 93 controles del Anexo A e indica cuáles son aplicables, cuáles se excluyen y por qué. La skill de SoA cruza el registro de riesgos para sugerir inclusiones de controles, verifica que cada justificación sea trazable y realiza seguimiento del estado de implementación de cada control.
Tú: Genera la Statement of Applicability basada en nuestra evaluación de riesgos. Incluye seguimiento del estado de implementación.
Agente: Mapeé los 93 controles del Anexo A contra el registro de riesgos y el perfil. Voy a ejecutar la suite de validación de la SoA.
Sugerencias de inclusión: 78 controles marcados como aplicables, 15 excluidos. La herramienta señaló 2 controles a reconsiderar: A.7.4 (Monitoreo de seguridad física) — marcado como excluido, pero tienes una oficina física con acceso a sala de servidores. Y A.5.23 (Seguridad de la información para servicios cloud) — debería ser aplicable dada la dependencia de GCP.
Auditoría de justificaciones: PASS. Las 15 exclusiones tienen justificación documentada, referenciando límites de alcance o contexto organizativo. La auditoría también señaló 12 controles con evidencia pero estado aún “Not Started” — considera actualizar a medida que implementas.
Consistencia SoA–riesgo: PASS. Cada riesgo tratado del registro mapea al menos a un control aplicable en la SoA, y ningún control aplicable carece de un riesgo o requisito de negocio asociado.
Resumen de estado de implementación: Not Started: 34, Planned: 28, Implemented: 14, Verified: 2. El checker ahora lo sigue para que puedas ver el progreso de un vistazo.
Chequeo de evidencias de políticas: el checker escaneó el directorio de políticas. 3 controles incluidos referencian evidencias que aún no existen — A.5.24 cita “Incident-Management-Procedure.md”, pero ese archivo todavía no fue generado. Lo dejé como recordatorio para el paso Policy Generator.
La SoA incluye una columna opcional de Estado de implementación con cuatro valores: Not Started, Planned, Implemented y Verified. Esto da al auditor una visión clara no solo de qué controles aplican, sino de en qué estado está cada uno. La columna es opcional; las SoA existentes sin ella siguen funcionando. Cuando está poblada, los validadores reportan sobre ella: la auditoría de justificaciones marca controles con evidencia pero estado desactualizado, el checker resume la distribución, y el índice de evidencias incluye el estado en su tabla de salida.
La SoA se convierte en un documento vivo: si los riesgos cambian, el sistema puede revalidar si las decisiones de aplicabilidad siguen siendo válidas, y el estado de implementación registra tu progreso hacia el cumplimiento total.
Paso 6: Gap Assessment — encontrar lo que falta
Después de que los primeros cinco pasos generen los artefactos base, la skill Gap Assessment revisa el workspace completo para identificar lo que aún se necesita para certificación.
Tú: Evalúa el estado actual de nuestro ISMS contra requisitos ISO 27001.
Agente: He escaneado el workspace buscando artefactos obligatorios y he calificado la madurez por área de cláusulas. Esto es lo que encontré.
El escaneo de artefactos obligatorios produjo un checklist trazable — la declaración de alcance del ISMS y el registro de riesgos existen, pero aún faltan la Política de Seguridad de la Información, la SoA y resultados de Auditoría Interna.
En madurez por cláusula, califiqué la Cláusula 6 (Planificación) con nivel 3 (“Definido”) basado en la metodología y registro de riesgos existentes, mientras que la Cláusula 9 (Evaluación del desempeño) está en nivel 0 (“Inexistente”) porque aún no hay monitoreo, auditoría o revisión por la dirección.
Según riesgo de auditoría, la prioridad de remediación es:
- Inmediato — Política de Seguridad de la Información (Cláusula 5.2), justificaciones de exclusión de alcance
- Corto plazo — SoA, Plan de Tratamiento de Riesgos, Objetivos de Seguridad
- Medio plazo — Procedimientos operativos (control de accesos, gestión de incidentes, seguridad de proveedores)
- Preparación para auditoría — Auditoría interna, revisión por la dirección, proceso CAPA
Aquí el ciclo PDCA se vuelve tangible: la evaluación de brechas te dice exactamente qué skills ejecutar después y en qué orden.
Paso 7: Policy Generator — políticas a medida con control documental
La skill Policy Generator crea políticas conformes a ISO adaptadas al contexto de la organización. Lee el perfil, el registro de riesgos y la declaración de alcance para producir políticas que referencian sistemas, roles y obligaciones reales — no placeholders genéricos. Soporta 16 tipos de documentos, incluyendo políticas de alto nivel, procedimientos operativos y directrices técnicas.
Tú: Genera la Política de Seguridad de la Información para CloudSync Solutions.
Agente: He redactado POL-001 basada en tu perfil y contexto de riesgo. Voy a validar metadatos del documento y cobertura de temas obligatorios.
Verificación de metadatos: PASS. POL-001 tiene versión, owner (Maria Santos), aprobación (João Silva), fecha de vigencia, próxima revisión y clasificación (Interno) — todo presente.
Checker de temas obligatorios: PASS. Se cubren todas las secciones requeridas — compromiso de la dirección (5.1), propósito (5.2), roles y responsabilidades (5.3), gestión de riesgos (6.1), requisitos de cumplimiento y calendario de revisión.
Tras generar las 16 políticas y procedimientos, ejecuté el check de trazabilidad tratamiento–política. Cruzó 8 decisiones “Tratar” del plan de tratamiento contra las políticas generadas. 7 de 8 tienen cadena completa — existe la política que implementa cada control. Un gap: R-06 (vulnerabilidades en APIs, controles A.8.25–A.8.26) mapea a un Procedimiento de Desarrollo Seguro, pero aún no existe porque los procedimientos de desarrollo de software eran opcionales en tu alcance. Recomiendo añadirlo dado que la plataforma SaaS es el activo principal.
La política generada incluye:
- Encabezados alineados por cláusula (5.1 Compromiso de la Dirección, 5.2 Propósito, 5.3 Roles y Responsabilidades)
- Objetivos específicos de la organización (“Alcanzar certificación ISO 27001 para Q4 2026”, “Cumplimiento LGPD”)
- Asignación nominal de roles (“Maria Santos — CISO”, “João Silva — CTO”)
- Referencias cruzadas a documentos relacionados (POL-002 Política de Gestión de Riesgos, inventario de activos, SoA)
Un LLM genérico podría redactar una política plausible. La skill asegura que sea coherente con todos los demás artefactos del workspace.
Paso 8: Physical Security Perimeter — controles más allá de lo digital
Incluso organizaciones cloud-native tienen preocupaciones de seguridad física — oficinas, salas de reunión y armarios de red. La skill Physical Security Perimeter genera controles adaptados a la huella física de la organización, con foco en control de accesos, gestión de visitantes y prevención de tailgating.
Tú: Define controles de seguridad física para nuestra oficina en São Paulo.
Agente: Basado en el perfil, tu oficina es una única sede con sala de servidores y espacio open-plan. Redacté el documento con controles para tres zonas: entrada del edificio, planta de oficinas y sala de servidores. Voy a validar.
Verificación de prevención de tailgating: PASS. Los controles incluyen acceso solo con credencial en recepción, registro de visitantes con escolta obligatoria y un mantrap para la sala de servidores con doble autenticación (credencial + PIN).
También lo crucé con la SoA — A.7.1 (Perímetros de seguridad física), A.7.2 (Entrada física) y A.7.4 (Monitoreo de seguridad física) quedan cubiertos.
Paso 9: Supplier Security Policy — gestionar el riesgo de terceros
Las empresas SaaS dependen mucho de terceros. La skill Supplier Security Policy genera requisitos escalonados según el nivel de acceso a datos y criticidad de cada proveedor, garantizando cláusulas de derecho de auditoría y acuerdos de tratamiento de datos.
Tú: Crea la política de seguridad de proveedores basada en nuestro stack y evaluación de riesgos.
Agente: Clasifiqué tus 8 proveedores en tres tiers según acceso a datos y criticidad. Voy a validar la política.
Clasificación por tier:
- Tier 1 (Crítico): GCP (IaaS — aloja todos los datos de clientes), Okta (IAM — controla autenticación)
- Tier 2 (Importante): GitHub (código fuente), Stripe (procesamiento de pagos), Google Workspace (comunicaciones internas)
- Tier 3 (Estándar): SendGrid (entrega de email), CloudFront (CDN), herramientas de monitoreo
Generación de cláusulas por tier: PASS. Tier 1 requiere SOC 2 Type II anual, derecho de auditoría, notificación de incidentes en 24 horas y garantías de residencia de datos. Tier 2 requiere SOC 2 o evidencia ISO 27001 y notificación en 48 horas. Tier 3 requiere cuestionarios básicos.
Refuerzo de derecho de auditoría: PASS. Todas las cláusulas Tier 1 y Tier 2 incluyen derecho contractual de auditoría según A.5.19 y A.5.21.
Paso 10: Legal Requirements Register — obligaciones legales documentadas
La skill Legal Requirements Register identifica y documenta todas las obligaciones legales, regulatorias y contractuales relevantes para la seguridad de la información, según el control A.5.31 del Anexo A. Lee el perfil de la organización para detectar jurisdicciones y regulaciones aplicables, y mapea cada requisito a controles específicos del ISMS.
Tú: Crea el registro de requisitos legales para CloudSync Solutions.
Agente: Basado en el perfil de la organización, identifiqué 12 obligaciones legales y regulatorias aplicables. Voy a validar el registro.
Requisitos identificados: LGPD (protección de datos personales), Marco Civil da Internet (retención de registros), Código de Defesa do Consumidor (protección al consumidor en servicios digitales), cláusulas contractuales de clientes enterprise con requisitos de residencia de datos, y 8 requisitos regulatorios adicionales.
Mapeo a controles del Anexo A: PASS. Cada requisito tiene al menos un control asociado — LGPD mapea a A.5.34 (Privacidad y protección de PII), A.5.31 (Requisitos legales) y A.5.12 (Clasificación de información). Los requisitos contractuales de residencia de datos mapean a A.5.23 (Seguridad de servicios cloud).
Verificación de completitud: WARNING. No se encontró referencia a regulaciones laborales sobre monitoreo de empleados. Dado que el ISMS podría incluir monitoreo de actividades en endpoints, recomiendo documentar la base legal para dicho tratamiento.
Paso 11: Confidentiality & NDA Agreements — acuerdos de confidencialidad formalizados
La skill Confidentiality & NDA Agreements genera plantillas de acuerdos de confidencialidad y no divulgación para empleados y terceros, además de un registro de seguimiento, conforme al control A.6.6 del Anexo A.
Tú: Genera las plantillas de NDA y el registro de seguimiento para CloudSync Solutions.
Agente: He creado dos plantillas de NDA: una para empleados y contratistas, y otra para terceros y proveedores. También generé el registro de seguimiento de acuerdos. Voy a validar.
Plantilla de empleados: PASS. Incluye definición de información confidencial, obligaciones del firmante, duración de la obligación (2 años post-terminación), excepciones y consecuencias del incumplimiento. Adaptada al contexto LGPD con referencia a datos de clientes procesados por CloudSync.
Plantilla de terceros: PASS. Incluye cláusulas de derecho de auditoría, notificación de incidentes, devolución o destrucción de información al término del acuerdo, y referencia a los tiers de proveedores definidos en la política de seguridad de proveedores.
Registro de seguimiento: 11 acuerdos registrados — 45 empleados activos, más 6 proveedores Tier 1 y Tier 2. Dos proveedores Tier 2 tienen acuerdos próximos a vencer (dentro de 60 días). Lo marqué para renovación.
Paso 12: Operating Procedures (SOPs) — procedimientos operativos documentados
La skill Operating Procedures produce procedimientos operativos estándar (SOPs) paso a paso para instalaciones de procesamiento de información, conforme al control A.5.37 del Anexo A. Cada SOP mantiene trazabilidad directa a los controles del Anexo A que implementa.
Tú: Genera los procedimientos operativos clave para nuestro ISMS.
Agente: Basado en la SoA y las políticas generadas, identifiqué 8 SOPs prioritarios. He redactado los procedimientos y generado el índice. Voy a validar.
SOPs generados: SOP-001 (Gestión de accesos y privilegios), SOP-002 (Respuesta a incidentes de seguridad), SOP-003 (Gestión de backups y restauración), SOP-004 (Gestión de cambios), SOP-005 (Gestión de vulnerabilidades), SOP-006 (Monitoreo de logs de seguridad), SOP-007 (Onboarding/offboarding de personal), SOP-008 (Gestión de medios removibles).
Trazabilidad SOP–control: PASS. Cada SOP referencia los controles del Anexo A que implementa. Por ejemplo, SOP-002 cubre A.5.24, A.5.25, A.5.26 y A.5.27 (la cadena completa de gestión de incidentes).
Índice de SOPs: PASS. El índice incluye ID del procedimiento, título, controles del Anexo A cubiertos, owner, fecha de vigencia y próxima revisión.
Paso 13: Secure Architecture Principles — principios de ingeniería segura
La skill Secure Architecture Principles documenta los principios de arquitectura e ingeniería segura conforme al control A.8.27 del Anexo A. Produce un catálogo de principios con justificación, guía de implementación y aplicabilidad específica al stack tecnológico de la organización.
Tú: Documenta los principios de arquitectura segura para nuestra plataforma SaaS en GCP.
Agente: He generado un catálogo de 14 principios de ingeniería segura adaptados al stack de CloudSync Solutions. Voy a validar.
Principios documentados: defensa en profundidad, privilegio mínimo, segregación de entornos (dev/staging/prod en proyectos GCP separados), cifrado en tránsito y en reposo, autenticación y autorización centralizadas vía Okta, inmutabilidad de infraestructura, logging centralizado, secure defaults y 6 principios adicionales.
Aplicabilidad por stack: PASS. Cada principio incluye guía específica para GCP (VPC Service Controls, Cloud KMS, IAM Conditions), GitHub (branch protection, secret scanning) y la plataforma SaaS (OWASP Top 10, validación de input, gestión de sesiones).
Verificación cruzada con SoA: PASS. A.8.27 (Principios de ingeniería segura) está marcado como aplicable y ahora referencia este catálogo como evidencia de implementación.
Paso 14: Awareness & Training Plan — concienciación y competencia
La skill Awareness & Training Plan crea el plan de formación y concienciación en seguridad de la información conforme a las Cláusulas 7.2 (Competencia) y 7.3 (Concienciación) y al control A.6.3 del Anexo A. Define audiencias objetivo con requisitos de formación por rol, módulos, métodos de entrega, calendario anual y métricas de evaluación de efectividad.
Tú: Crea el plan de concienciación y formación en seguridad para CloudSync Solutions.
Agente: He diseñado el plan de formación basado en el perfil de la organización y los riesgos identificados. Voy a validar.
Audiencias definidas: 4 grupos — Todo el personal (45 empleados), Equipo de desarrollo (12 personas), Management (5 personas), Nuevos ingresos. Cada grupo tiene requisitos de formación diferenciados según su rol y nivel de acceso.
Módulos de formación: 6 módulos — Fundamentos de seguridad de la información, Phishing y ingeniería social, Protección de datos y LGPD, Desarrollo seguro (solo devs), Gestión de incidentes (roles clave), Responsabilidades de management (solo dirección).
Calendario: PASS. Formación general obligatoria anual, simulaciones de phishing trimestrales, formación de desarrollo seguro semestral, onboarding de seguridad para nuevos ingresos dentro de los primeros 5 días.
Métricas de efectividad: PASS. Tasa de completitud de cursos (meta: 95%), tasa de clics en simulaciones de phishing (meta: <10%), score medio en evaluaciones post-formación (meta: >80%), tiempo desde ingreso hasta completar onboarding de seguridad (meta: <5 días hábiles).
Paso 15: Monitoring & Evaluation — medir lo que importa
La skill Monitoring & Evaluation genera KPI alineados a los objetivos del ISMS, mantiene el Registro de Objetivos de Seguridad de la Información, y ejecuta el objectives_completeness_checker para validar que cada objetivo tenga métricas, responsables y plazos. También rastrea acciones correctivas derivadas de hallazgos de auditoría y asegura que el proceso CAPA (Corrective and Preventive Action) esté completo.
Tú: Configura el marco de monitoreo y evaluación para nuestro ISMS.
Agente: Generé 8 KPI alineados a los objetivos definidos en alcance y políticas, y completé el Registro de Objetivos de SI. Voy a validar el seguimiento de CAPA.
Generación de KPI: PASS. Cada KPI tiene métrica, objetivo, frecuencia, fuente de datos y owner. Ejemplos: “Porcentaje de revisiones de acceso completadas a tiempo” (meta: 100%, trimestral, fuente: logs de auditoría de Okta, owner: Maria Santos), “Tiempo medio para parchear vulnerabilidades críticas” (meta: <72 horas, mensual, fuente: GitHub security alerts, owner: João Silva).
Registro de Objetivos de SI: PASS. El objectives_completeness_checker validó que los 6 objetivos de seguridad de la información tienen métricas medibles, responsables asignados, plazos definidos y fuentes de datos especificadas.
Completitud de CAPA: WARNING. Dos de los tres hallazgos (Finding 01 y 02) tienen CAPA completo — causa raíz, acción correctiva, owner, due date y criterios de efectividad. Finding 03 (verificación de backups) tiene causa raíz y acción correctiva, pero le faltan criterios de verificación de efectividad. Lo marqué para completar.
Reconciliación NC–CAPA: el reconciliador cruzó el informe de auditoría interna contra el registro CAPA. Las 3 NC (NC-001 a NC-003) tienen entradas CAPA correspondientes. También verificó controles fallidos del reporte de monitoreo — la métrica de revisiones de acceso (72% completado vs. 100% objetivo) estaba correctamente vinculada a CAPA-001. Sin hallazgos huérfanos.
Seguimiento de acciones correctivas: PASS. Todos los CAPA tienen owners asignados y due dates dentro de 90 días desde la fecha del hallazgo.
Paso 16: Business Continuity Plan — preparación ante interrupciones
La skill Business Continuity Plan genera planes de continuidad del negocio (BCP) y recuperación ante desastres (DRP) operativamente detallados, conforme a los controles A.5.29 y A.5.30 del Anexo A. Incluye análisis de impacto en el negocio (BIA), secuencias de recuperación basadas en RTO/RPO, procedimientos de failover y registros de ejercicios.
Tú: Crea el plan de continuidad del negocio y recuperación ante desastres para CloudSync Solutions.
Agente: Basado en el inventario de activos y la evaluación de riesgos, he redactado el BCP/DRP. Voy a validar.
Análisis de impacto en el negocio (BIA): PASS. Los 5 procesos críticos están priorizados — la plataforma SaaS tiene RTO de 4 horas y RPO de 1 hora, autenticación Okta tiene RTO de 2 horas, procesamiento de pagos Stripe tiene RTO de 8 horas.
Validación de RTO/RPO: PASS. Los objetivos de recuperación son consistentes con la arquitectura GCP actual — replicación multi-región soporta el RPO de 1 hora, y las capacidades de auto-scaling permiten el RTO de 4 horas.
Procedimientos de failover: PASS. Procedimientos paso a paso documentados para 3 escenarios — falla de región GCP, compromiso de credenciales (rotación de claves vía Okta), y falla de proveedor crítico (playbook de migración de DNS).
Registros de ejercicios: WARNING. El plan está listo pero no se han ejecutado ejercicios de prueba. Recomiendo programar un tabletop exercise dentro de 30 días y un test de failover técnico dentro de 60 días.
Paso 17: Internal Audit — imparcialidad y validación de hallazgos
La skill Internal Audit Report produce plan de auditoría, checklist, hallazgos y severidad. Lo que la diferencia de un drafting simple:
Tú: Crea el informe de auditoría interna para nuestro ISMS.
Agente: Redacté el plan de auditoría para 20–24 de marzo de 2026 con Carlos Mendes (Equipo de Calidad) como auditor líder. Voy a ejecutar el check de imparcialidad.
Validación de imparcialidad: PASS. Carlos Mendes no tiene responsabilidades operativas, de gestión o de diseño del ISMS — independencia confirmada.
Completé el checklist contra todas las cláusulas y controles del Anexo A. Se identificaron tres hallazgos:
Finding 01 (Evidencia de revisiones de acceso, A.5.15): No conformidad menor. La Política de Control de Accesos requiere revisiones trimestrales, pero no existen registros de Q1 2026. Causa raíz: se completó la migración a Okta, pero no se programaron los flujos de revisión.
Finding 02 (Procedimiento de gestión de incidentes, A.5.24): No conformidad menor. PROC-003 está en borrador y le faltan pasos específicos para incidentes SaaS.
Finding 03 (Verificación de backups, A.8.13): No conformidad mayor. Existen backups en GCP, pero no hay logs de pruebas de restauración. La suposición de que los servicios gestionados garantizan integridad sin verificación manual es insuficiente.
El checklist referencia artefactos reales del workspace:
| Ref | Requisito | Evidencia | Estado |
|---|---|---|---|
| 4.3 | ¿Alcance del ISMS documentado? | isms-scope-statement.md | Pass |
| 6.1 | ¿Existe registro de riesgos? | risk-register.md | Pass |
| A.5.15 | ¿Se realizaron revisiones de acceso? | No hay registros de Q1 | Fail |
| A.8.13 | ¿Backups verificados? | Backups en GCP, sin logs de prueba | Fail |
Paso 18: Management Review — cerrar el ciclo PDCA
La skill Management Review compila el management review input pack según la Cláusula 9.3, extrayendo información de todos los artefactos producidos. El checker de entradas obligatorias valida que se cubran los 10 inputs requeridos:
- Estado de acciones de revisiones anteriores
- Cambios en cuestiones internas/externas
- No conformidades y acciones correctivas
- Resultados de monitoreo y medición
- Resultados de auditorías
- Cumplimiento de objetivos
- Feedback de partes interesadas
- Resultados de evaluación de riesgos
- Oportunidades de mejora
- Necesidades de recursos
Tú: Compila el input pack de management review.
Agente: Compilé el input pack con referencias trazables a todos los artefactos del workspace. El checker confirmó que los 10 inputs obligatorios de la Cláusula 9.3 están cubiertos.
También validé que cada action item tenga owner, due date y criterios de aceptación — todos los checks pasaron.
Paso 19: Executive Readiness Report — resumen ejecutivo para la dirección
La skill Executive Readiness Report genera un informe ejecutivo listo para presentar a dirección, comité de auditoría o consejo. Sintetiza datos del dashboard, gap assessment, registro de riesgos y estado de políticas en un documento exportable con scoring de preparación por área, brechas críticas y timeline estimado hacia auditoría.
Tú: Genera el informe ejecutivo de preparación para el comité directivo de CloudSync Solutions.
Agente: He sintetizado los datos de todos los artefactos del ISMS en un informe ejecutivo. Voy a validar la cobertura.
Scoring de preparación por área: Alcance y Contexto 100%, Gestión de Riesgos 95%, Políticas y Procedimientos 88%, Controles Operativos 82%, Monitoreo y Auditoría 78%, Continuidad del Negocio 70%. Preparación general: 86%.
Brechas críticas: 3 items requieren atención antes de Stage 1 — procedimiento de desarrollo seguro (R-06), registros de ejercicio de BCP, y criterios de efectividad de CAPA para Finding 03.
Timeline estimado: con dedicación actual, Stage 1 viable en 6 semanas, Stage 2 en 10 semanas. El informe incluye un roadmap visual con hitos y responsables.
El informe está listo para exportación en formato ejecutivo — sin jerga técnica, con gráficos de progreso y recomendaciones priorizadas.
Trazabilidad entre documentos: la perspectiva del auditor
Los auditores ISO 27001 no evalúan documentos aislados — trazan cadenas. “Muéstrame el riesgo que llevó a este control. Muéstrame la política que lo implementa. Muéstrame la evidencia de que funciona.” Si un eslabón se rompe, el auditor registra una no conformidad.
Las herramientas de trazabilidad entre documentos de Rakenne fuerzan automáticamente 11 de esos vínculos. Cada herramienta se ejecuta dentro de la skill que produce el documento downstream, verificándolo contra artefactos upstream. Todos los parámetros entre documentos son opcionales: las herramientas auto-descubren documentos en el workspace y solo verifican enlaces cuando existen ambos extremos.
Esto es lo que ocurre al ejecutar el dashboard de trazabilidad del ISMS tras completar las 19 skills:
Tú: Ejecuta el dashboard de trazabilidad para verificar la consistencia general del ISMS.
Agente: Escaneé el workspace y verifiqué los 11 vínculos de trazabilidad. Estos son los resultados.
Progreso de implementación:
- Fase Plan (Cláusulas 4–6): 6/6 documentos completos
- Fase Do (Cláusulas 7–8): 16 políticas y procedimientos encontrados
- Fase Check (Cláusula 9): 2/2 documentos completos
- Fase Act (Cláusula 10): 3/3 documentos completos
Vínculos de trazabilidad: 9 de 11 vínculos son plenamente consistentes. 2 advertencias:
- SoA → Políticas: 3 controles incluidos citan evidencias que fueron modificadas después de la última actualización de la SoA — puede que la SoA necesite refrescarse para reflejar el contenido actual.
- Tratamiento de riesgos → Políticas: R-06 (vulnerabilidades en APIs) está como “Tratar” con controles A.8.25–A.8.26, pero el Procedimiento de Desarrollo Seguro aún no existe.
Preparación para auditoría: 91% — resuelve las 2 advertencias antes de Stage 1.
El dashboard es sensible a la fase. Si estás a mitad de implementación — por ejemplo, Plan completado pero Check y Act aún no empezaron —, el dashboard no te penaliza por no tener informes de auditoría. En su lugar, reporta:
“Fase Plan: 6/6 completa, trazabilidad 100%. Fase Do: 16/18 documentos, 2 advertencias. Fase Check: aún no iniciada. Fase Act: aún no iniciada.”
Esto da a consultores y dirección una visión clara de dónde está el proyecto y qué sigue — sin el desmoralizante “17/21 documentos faltantes” de otros enfoques.
Cómo se detecta consistencia y se autocorrige
El poder de la validación entre documentos está en el bucle de feedback. Un ejemplo concreto de cómo el agente detecta y corrige una inconsistencia a través de tres documentos:
Agente: He completado el registro de riesgos con 8 entradas. Ejecutando la suite de validación…
El validador de cobertura activo–riesgo encontró una brecha: AST-008 (Bóveda de claves API, clasificado Confidencial) aparece en el inventario de activos, pero no tiene entrada correspondiente en el registro de riesgos. Esto es una bandera roja de auditoría — un activo Confidencial sin evaluación de riesgos sugiere análisis incompleto.
Añadí el riesgo R-08: “Extracción no autorizada de claves API desde la bóveda de secretos” (Probabilidad: 4, Impacto: 5, Score: 20, Tratamiento: Tratar, Controles: A.5.17, A.8.24).
Ahora ejecutando el checker de consistencia de SoA con el registro actualizado…
El checker confirmó que A.5.17 (Información de autenticación) y A.8.24 (Uso de criptografía) están marcados como aplicables en la SoA — consistente con el nuevo riesgo. Sin embargo, detectó que el campo de evidencia de implementación de A.8.24 contiene “[TBD]” — un placeholder que debe reemplazarse por una referencia real.
Actualicé la evidencia de A.8.24 para referenciar la “Sección de Controles Criptográficos” en la Política de Seguridad de la Información. Ejecutando de nuevo… PASS.
En este ejemplo, una herramienta (cobertura activo–riesgo) detectó un riesgo faltante y el agente lo añadió. Luego otra herramienta (consistencia SoA) confirmó el mapeo de controles, pero encontró un placeholder en evidencia. El agente lo corrigió y validó la cadena. Tres documentos — inventario de activos, registro de riesgos y SoA — quedan consistentes, verificados por checks deterministas en lugar de revisión manual.
Este tipo de autocorrección en cascada es lo que hace que la documentación de ISMS asistida por herramientas sea fundamentalmente diferente del drafting basado en plantillas. Las herramientas no solo “revisan”: crean las condiciones para que el agente corrija problemas antes de que un humano o un auditor vea la brecha.
El dashboard: seguimiento de progreso en las 19 skills
A medida que cada skill se completa, el agente actualiza el dashboard del proyecto. El dashboard ofrece una vista única del progreso del ISMS:
Dashboard tras completar las 19 skills del ISMS — documentos de políticas, procedimientos, planes y registros producidos, riesgos identificados y tratados, madurez por cláusula evaluada.
Métricas clave:
- Finalización del ISMS — porcentaje de skills completadas (Plan → Do → Check → Act)
- Documentos producidos — total de artefactos (políticas, procedimientos, registros, informes, planes)
- Distribución de riesgos — por severidad (Crítico / Alto / Medio / Bajo)
- Cobertura de tratamiento — porcentaje de riesgos identificados con plan de tratamiento
- Madurez por cláusula — rating por cláusula en escala 0–5
- Hallazgos de brechas — abiertos vs. cerrados desde gap assessment
- CAPA — estado de acciones correctivas desde hallazgos de auditoría interna
- Preparación Stage 1/2 — estimación de preparación para auditorías de certificación
El dashboard da a consultores y management una visión en tiempo real de dónde está el proyecto y qué falta.
Comparación de esfuerzo: tiempo de consultoría con y sin herramientas
Basado en desgloses típicos de esfuerzo para una certificación inicial ISO 27001 en una organización pequeña-mediana:
| Actividad | % del esfuerzo | Aceleración asistida por herramientas |
|---|---|---|
| Alcance, contexto, aplicabilidad | 8% | Organization Profile + ISMS Scope reducen entrevistas y retrabajo |
| Evaluación de brechas | 12% | Detección de artefactos obligatorios y análisis por cláusula reemplazan checklists manuales |
| Evaluación de riesgos + SoA + tratamiento | 24% | Cinco checks de riesgos + consistencia de SoA aplican metodología automáticamente |
| Conjunto de políticas y procedimientos | 16% | Generación contextual con validación de metadatos y temas obligatorios |
| Auditoría interna + CAPA | 4% | Chequeo de imparcialidad y estructura de severidad ordenan el proceso |
| Revisión por la dirección | 3% | Validación de los 10 inputs de Cláusula 9.3 asegura completitud |
Las actividades más pesadas (riesgos, políticas, brechas) son exactamente donde las herramientas agregan más valor — no reemplazando el juicio del consultor, sino capturando errores mecánicos y omisiones que consumen ciclos de revisión.
Cómo empezar
- Crea un nuevo proyecto en Rakenne y selecciona el template de workspace ISO 27001 ISMS
- Las 19 skills y herramientas de validación se instalan automáticamente
- Empieza con Organization Profile — proporciona los datos del cliente y deja que el agente construya el perfil estructurado
- Sigue la secuencia PDCA por los 19 pasos, o salta a skills específicas según los resultados del gap assessment
- Usa el dashboard para seguir el progreso e identificar lo que falta
Cada skill es independiente, pero lee artefactos de pasos anteriores. Puedes ejecutarlas en cualquier orden, pero la secuencia recomendada asegura que cada skill tenga el contexto que necesita.
Resumen
El template de workspace ISO 27001 ISMS convierte la documentación de ISMS de un ejercicio ad hoc de redacción en un proceso estructurado y validado. Las 19 skills cubren todo el ciclo PDCA, y las 55+ herramientas de validación aplican los mismos checks que un consultor GRC senior realizaría — de manera consistente, automática y trazable.
Lo que diferencia este enfoque de cualquier otro — plantillas, IA genérica o incluso plataformas GRC — es la malla de trazabilidad entre documentos. Once checks automatizados verifican que los riesgos trazan a controles, los controles trazan a políticas, las políticas trazan a evidencias, los hallazgos de auditoría trazan a CAPA y que los límites de alcance son consistentes a lo largo de todos los documentos downstream. Cuando un enlace se rompe, el agente lo detecta, explica por qué y lo corrige — antes de que un revisor humano o un auditor vea la brecha.
El resultado no es un set de plantillas genéricas. Es un conjunto de artefactos específicos de la organización, coherentes internamente y alineados por cláusula, que se referencian entre sí, conectan riesgos con controles, procedimientos y evidencias, y señalan brechas antes de que lo haga un auditor.
Pruébalo tú mismo
Abre un workspace con los skills descritos en este artículo y empieza a redactar en minutos.
Empieza Gratis — Sin Registro