Requisitos de ISO 27001: Cláusulas 4-10 Explicadas para Equipos SaaS

Los requisitos de ISO 27001 se definen en las Cláusulas 4 a 10 del estándar. Estas siete cláusulas especifican qué debe incluir su Sistema de Gestión de Seguridad de la Información (ISMS), cómo debe funcionar y cómo debe gobernarlo su organización. Son obligatorias — cada uno de los requisitos de las Cláusulas 4-10 debe cumplirse para obtener la certificación. No existen cláusulas opcionales.

Esta es la parte de ISO 27001 que muchos equipos SaaS malinterpretan. Se lanzan directamente al Annex A — el catálogo de 93 controles de seguridad — y comienzan a implementar medidas técnicas. Pero los controles del Annex A se seleccionan en función de su evaluación de riesgos (Cláusula 6), se documentan en su Declaración de Aplicabilidad (también Cláusula 6) y se pueden excluir controles con la debida justificación. Las Cláusulas 4-10, por otro lado, no pueden excluirse. Son los requisitos del sistema de gestión que hacen sostenibles los controles de seguridad.

Piénselo de esta manera: los controles del Annex A son el “qué” de la seguridad de la información (cifrar datos, gestionar accesos, monitorear registros). Las Cláusulas 4-10 son el “cómo” de dirigir un programa de seguridad (entender su contexto, obtener el apoyo del liderazgo, planificar basándose en riesgos, apoyar con recursos, operar de manera consistente, medir el rendimiento, mejorar continuamente). Para una descripción completa del Annex A, consulte nuestra guía de Controles del Annex A.

Esta guía desglosa cada cláusula con lo que el estándar requiere, lo que evalúan los auditores, cómo las empresas SaaS deben implementar cada requisito y los errores comunes que conducen a no conformidades. Si está comenzando con ISO 27001, nuestra descripción general ¿Qué es ISO 27001? proporciona el contexto fundamental.

Comprendiendo la Estructura de las Cláusulas

ISO 27001:2022 está organizado en secciones:

• Cláusulas 0-3: Introducción, alcance, referencias normativas, términos y definiciones. Son informativas — no contienen requisitos auditables.
• Cláusulas 4-10: Los requisitos obligatorios del ISMS. Cada subcláusula contiene declaraciones “debe” (shall) que su organización debe satisfacer.
• Annex A: Un conjunto de referencia de 93 controles organizados en 4 temas (Organizacionales, Personas, Físicos, Tecnológicos). Los controles se seleccionan en función de su evaluación de riesgos y se documentan en la Declaración de Aplicabilidad.

La relación entre las cláusulas y el Annex A es crítica: la Cláusula 6 (Planificación) requiere que realice una evaluación de riesgos y determine qué controles del Annex A son necesarios para tratar los riesgos identificados. Las cláusulas impulsan el sistema de gestión; el Annex A proporciona las opciones de control para el tratamiento de riesgos. No puede implementar el Annex A sin las cláusulas, y las cláusulas sin el Annex A serían un sistema de gestión sin controles de seguridad.

Para un enfoque de certificación paso a paso que mapea estos requisitos a un plan de proyecto, consulte nuestra Lista de Verificación de Certificación ISO 27001.

Cláusula 4: Contexto de la Organización

La Cláusula 4 requiere que comprenda su organización, su entorno y las necesidades de las partes interesadas antes de diseñar su ISMS. Este es el fundamento — todo lo demás en el ISMS se deriva del contexto que establezca aquí.

4.1 Comprensión de la Organización y su Contexto

Lo que requiere el estándar: Determinar las cuestiones externas e internas que son relevantes para el propósito de su organización y que afectan su capacidad para lograr los resultados previstos de su ISMS.

Lo que evalúan los auditores: El auditor quiere ver evidencia documentada de que ha considerado el contexto más amplio en el que opera su organización. No es un ejercicio teórico — debe reflejar su entorno empresarial real.

Implementación SaaS:

• Cuestiones externas: Requisitos regulatorios (GDPR, CCPA, regulaciones específicas de la industria), expectativas del mercado (requisitos de seguridad de los clientes, panorama competitivo), tendencias tecnológicas (evolución de la seguridad en la nube, amenazas emergentes), condiciones económicas y riesgos de la cadena de suministro (dependencias de proveedores de nube, integraciones de terceros).
• Cuestiones internas: Estructura organizacional, cultura empresarial y madurez de la conciencia de seguridad, arquitectura técnica (infraestructura en la nube, pila de aplicaciones, flujos de datos), capacidades de seguridad existentes, disponibilidad de recursos y objetivos estratégicos.
• Enfoque de documentación: Cree un documento de análisis de contexto que catalogue estas cuestiones. Muchos equipos SaaS utilizan un análisis PESTLE (Político, Económico, Social, Tecnológico, Legal, Ambiental) para factores externos y un análisis FODA para factores internos. Manténgalo práctico — este documento debe informar decisiones reales sobre el alcance de su ISMS y la evaluación de riesgos, no quedarse en un cajón.

Error común: Tratar esto como un ejercicio único. Su contexto cambia — aparecen nuevas regulaciones, su base de clientes se desplaza, su pila tecnológica evoluciona, surgen nuevas amenazas. Revise y actualice su análisis de contexto al menos anualmente, y siempre que ocurran cambios significativos.

4.2 Comprensión de las Necesidades y Expectativas de las Partes Interesadas

Lo que requiere el estándar: Identificar las partes interesadas (stakeholders) relevantes para su ISMS, determinar sus requisitos respecto a la seguridad de la información y determinar cuáles de esos requisitos se abordarán a través de su ISMS.

Lo que evalúan los auditores: Una lista documentada de partes interesadas, sus requisitos de seguridad y cómo esos requisitos alimentan el diseño de su ISMS.

Implementación SaaS:

Parte Interesada	Sus Requisitos
Clientes	Protección de datos, disponibilidad, notificación de incidentes, certificaciones de seguridad, SLAs contractuales
Organismos reguladores	Cumplimiento del GDPR, notificación de violaciones de datos, procesamiento lícito, evaluaciones de impacto en la protección de datos
Empleados	Protección de datos personales, responsabilidades de seguridad claras, formación adecuada
Inversores/Junta Directiva	Gestión de riesgos, continuidad del negocio, informes de gobernanza de seguridad
Proveedores de nube	Cumplimiento del modelo de responsabilidad compartida, seguridad de configuración
Socios/Integraciones	Seguridad de API, acuerdos de manejo de datos, controles de acceso
Organismos de la industria	Cumplimiento de estándares, adherencia a mejores prácticas

Error común: Listar partes interesadas sin conectar sus requisitos a las decisiones del ISMS. Cada requisito de una parte interesada debe rastrearse a controles, políticas o procesos específicos en su ISMS. Si un requisito del cliente es “cifrar datos en reposo y en tránsito”, ese requisito debe ser rastreable a controles específicos del Annex A en su Declaración de Aplicabilidad.

4.3 Determinación del Alcance del ISMS

Lo que requiere el estándar: Definir los límites y la aplicabilidad de su ISMS, considerando las cuestiones externas e internas (4.1), los requisitos de las partes interesadas (4.2) y las interfaces y dependencias entre sus actividades y las de otras organizaciones.

Lo que evalúan los auditores: Una declaración de alcance documentada que defina claramente qué está incluido y excluido, con justificación para las exclusiones. El alcance debe estar disponible como información documentada.

Implementación SaaS:

Un alcance bien definido para una empresa SaaS típicamente incluye:

• La aplicación SaaS y toda la infraestructura de soporte (entornos de nube, bases de datos, servidores de aplicaciones, CDN, DNS)
• El pipeline CI/CD y la infraestructura de desarrollo
• El equipo responsable de desarrollar, desplegar y operar la aplicación
• Datos de clientes procesados por la aplicación
• Sistemas corporativos que apoyan directamente la seguridad de la información (proveedor de identidad, correo electrónico, herramientas de comunicación, gestión de endpoints)
• Ubicaciones físicas desde las cuales opera el equipo (oficinas, o una declaración sobre los acuerdos de trabajo remoto)

Ejemplo de declaración de alcance: “El ISMS cubre el desarrollo, despliegue, operación y mantenimiento de [Nombre del Producto], una plataforma SaaS basada en la nube alojada en AWS, incluyendo todas las actividades de procesamiento de datos de clientes, infraestructura de TI de soporte y el equipo de [X] empleados ubicados en [ubicación/remoto]. El alcance incluye la infraestructura en la nube (AWS eu-west-1 y us-east-1), la capa de aplicación, el pipeline CI/CD y los sistemas administrativos utilizados para gestionar estos servicios.”

Error común: Definir el alcance demasiado amplio (incluyendo cada sistema corporativo independientemente de su relevancia para la seguridad) o demasiado estrecho (excluyendo sistemas que claramente afectan la seguridad de los servicios dentro del alcance). Su organismo de certificación cuestionará un alcance que no tenga sentido lógico. Si su proveedor de identidad controla el acceso a todo lo que está dentro del alcance pero el propio proveedor de identidad está fuera del alcance, el auditor señalará esto como una brecha.

4.4 Sistema de Gestión de Seguridad de la Información

Lo que requiere el estándar: Establecer, implementar, mantener y mejorar continuamente un ISMS de acuerdo con los requisitos del estándar.

Lo que evalúan los auditores: Evidencia de que el ISMS existe como un sistema funcional — no solo una colección de documentos, sino un conjunto integrado de procesos, controles y mecanismos de gobernanza que trabajan juntos.

Implementación SaaS: Esta cláusula se satisface implementando todo en las Cláusulas 4-10. Es un meta-requisito — confirmación de que el ISMS está establecido (diseñado y documentado), implementado (funcionando en la práctica), mantenido (actualizado) y mejorado continuamente (mejorado basándose en datos de rendimiento y condiciones cambiantes).

Cláusula 5: Liderazgo

La Cláusula 5 garantiza que la seguridad de la información no sea una iniciativa aislada — está integrada en el liderazgo y la gobernanza de la organización. Sin un compromiso genuino del liderazgo, un ISMS se convierte en un ejercicio de papel que satisface al auditor pero que en realidad no protege la información.

5.1 Liderazgo y Compromiso

Lo que requiere el estándar: La alta dirección debe demostrar liderazgo y compromiso con el ISMS asegurando que la política y los objetivos de seguridad de la información estén establecidos, asegurando la integración del ISMS en los procesos de la organización, asegurando que los recursos estén disponibles, comunicando la importancia de una gestión eficaz de la seguridad de la información, asegurando que el ISMS logre sus resultados previstos, dirigiendo y apoyando a las personas para que contribuyan a la eficacia del ISMS, promoviendo la mejora continua y apoyando a otros roles de gestión relevantes.

Lo que evalúan los auditores: Evidencia de que el liderazgo está genuinamente involucrado — no solo firmas en políticas, sino participación activa en la gobernanza de seguridad. Los auditores frecuentemente entrevistan a ejecutivos para verificar su comprensión y compromiso.

Implementación SaaS:

• Participación ejecutiva en revisiones por la dirección. El CEO, CTO o equivalente debe participar en las revisiones formales de gestión del ISMS (Cláusula 9.3). Las actas de las reuniones deben mostrar la presencia ejecutiva, discusión de temas de seguridad y decisiones sobre la asignación de recursos.
• Asignación de presupuesto. El liderazgo demuestra compromiso a través del presupuesto — aprobando financiamiento para herramientas de seguridad, plataformas GRC, formación, consultoría y personal de seguridad dedicado.
• Integración estratégica. Los objetivos de seguridad de la información deben alinearse con los objetivos de negocio. Si la estrategia de la empresa incluye expandirse a mercados regulados, el programa de seguridad debe evolucionar para apoyar esa expansión.
• Compromiso visible. El liderazgo marca el tono. Los CEOs que se saltan la formación de seguridad, ignoran los requisitos de las políticas o depriorizan las iniciativas de seguridad envían un mensaje claro a la organización — y los auditores lo perciben.

Error común: Tratar el compromiso del liderazgo como una formalidad — hacer que el CEO firme la política de seguridad de la información y nada más. Los auditores prueban este requisito entrevistando a los líderes y preguntándoles que describan su rol en el ISMS, qué riesgos de seguridad les preocupan y cómo aseguran que el programa sea eficaz. Si un líder no puede responder a estas preguntas, el auditor puede plantear una no conformidad.

5.2 Política

Lo que requiere el estándar: La alta dirección debe establecer una política de seguridad de la información que sea apropiada para el propósito de la organización, incluya objetivos de seguridad de la información o proporcione el marco para establecerlos, incluya un compromiso de satisfacer los requisitos aplicables e incluya un compromiso de mejora continua.

Lo que evalúan los auditores: El documento de política de seguridad de la información en sí, además de evidencia de que ha sido comunicado a todos los empleados y partes externas relevantes, y que está disponible como información documentada.

Implementación SaaS:

Su política de seguridad de la información es el documento de nivel superior en su ISMS. Establece la dirección y los principios que siguen todas las demás políticas y procedimientos. Para empresas SaaS, esta política debe:

• Declarar el compromiso de la organización con la protección de los datos de los clientes y sus propios activos de información
• Definir el alcance y los objetivos del ISMS
• Comprometerse con el cumplimiento de los requisitos legales, regulatorios y contractuales aplicables
• Comprometerse con la mejora continua del ISMS
• Estar redactada en un lenguaje apropiado para su organización (una empresa SaaS de 40 personas no necesita una política de 20 páginas escrita en jerga legal corporativa)

La política de seguridad de la información está respaldada por políticas específicas por tema que cubren control de acceso, criptografía, gestión de activos, seguridad de recursos humanos, gestión de incidentes y otras áreas. Consulte nuestra guía de Políticas ISO 27001 para la lista completa y plantillas.

Error común: Redactar una política de seguridad de la información genérica y desconectada del contexto real de la organización. Si su política podría pertenecer a cualquier empresa en cualquier industria, no es apropiada para su propósito. La política de una empresa SaaS debe reflejar principios de seguridad nativos de la nube, prioridades de protección de datos de clientes y el panorama regulatorio específico en el que opera la empresa.

5.3 Roles, Responsabilidades y Autoridades Organizacionales

Lo que requiere el estándar: La alta dirección debe asegurar que las responsabilidades y autoridades para los roles relevantes para la seguridad de la información estén asignadas y comunicadas.

Lo que evalúan los auditores: Documentación que muestre quién es responsable de qué en el ISMS, además de evidencia de que estas personas entienden sus responsabilidades.

Implementación SaaS:

Defina y documente los roles y responsabilidades de seguridad en toda la organización. Para una empresa SaaS, esto típicamente incluye:

Rol	Responsabilidades del ISMS
CEO/Fundador	Responsabilidad general del ISMS, asignación de recursos, dirección estratégica
CTO/VP de Ingeniería	Controles de seguridad técnica, prácticas de desarrollo seguro, seguridad de infraestructura
Gerente del ISMS/Líder de Seguridad	Gestión diaria del ISMS, coordinación de evaluaciones de riesgos, preparación de auditorías, mantenimiento de políticas
Gerentes de Ingeniería	Prácticas de desarrollo seguro dentro de sus equipos, gestión de acceso, control de cambios
Gerente de RRHH	Procedimientos de seguridad para incorporación/desvinculación de empleados, coordinación de formación, verificación de antecedentes
Todos los Empleados	Cumplimiento de políticas, reporte de incidentes, conciencia de seguridad

En empresas SaaS más pequeñas, una persona a menudo desempeña múltiples roles. Eso está bien — documéntelo y asegúrese de que la persona tenga el ancho de banda necesario. El auditor verificará que los roles estén asignados, no que tenga una persona dedicada para cada función.

Error común: Asignar responsabilidad sin autoridad. Si el Gerente del ISMS es responsable de la seguridad de la información pero no tiene la autoridad para hacer cumplir las políticas, aprobar gastos de seguridad o escalar problemas al liderazgo, el rol es ineficaz. Asegúrese de que los roles tengan tanto responsabilidad como autoridad para actuar.

Cláusula 6: Planificación

La Cláusula 6 es la cláusula de planificación estratégica — conecta su comprensión del contexto y los riesgos (Cláusula 4) con las acciones y controles específicos que implementa su ISMS. Aquí es donde reside la evaluación de riesgos, donde se definen los objetivos de seguridad de la información y donde se crea la Declaración de Aplicabilidad.

6.1 Acciones para Abordar Riesgos y Oportunidades

Lo que requiere el estándar:

• 6.1.1: Considerar las cuestiones de contexto (4.1) y los requisitos de las partes interesadas (4.2), y determinar los riesgos y oportunidades que necesitan abordarse para asegurar que el ISMS logre sus resultados previstos, prevenir o reducir efectos no deseados y lograr la mejora continua.
• 6.1.2: Definir y aplicar un proceso de evaluación de riesgos de seguridad de la información que establezca criterios de aceptación de riesgos, produzca resultados consistentes y comparables, identifique los riesgos de seguridad de la información (incluyendo propietarios de riesgos), analice los riesgos (probabilidad y consecuencias) y evalúe los riesgos (comparar con los criterios de aceptación y priorizar para tratamiento).
• 6.1.3: Definir y aplicar un proceso de tratamiento de riesgos de seguridad de la información que seleccione las opciones de tratamiento apropiadas, determine todos los controles necesarios para implementar las opciones de tratamiento elegidas, compare los controles determinados con el Annex A para verificar que no se haya pasado por alto nada necesario, y produzca una Declaración de Aplicabilidad que contenga los controles necesarios, justificaciones para su inclusión, si están implementados, y la justificación para excluir cualquier control del Annex A.

Lo que evalúan los auditores: Esta es una de las áreas más escrutadas de la auditoría. Los auditores examinan:

• Su metodología de evaluación de riesgos (¿está documentada, es repetible y se aplica de manera consistente?)
• Su registro de riesgos (¿contiene riesgos identificados con probabilidad, impacto, nivel de riesgo, propietarios de riesgos y decisiones de tratamiento?)
• Su plan de tratamiento de riesgos (para los riesgos que eligió mitigar, ¿qué controles se están implementando, por quién y para cuándo?)
• Su Declaración de Aplicabilidad (¿enumera los 93 controles del Annex A con decisiones de inclusión/exclusión y justificaciones?)
• Consistencia entre la evaluación de riesgos, el plan de tratamiento de riesgos y el SoA (¿los controles en el SoA realmente abordan los riesgos en el registro de riesgos?)

Implementación SaaS:

La evaluación de riesgos es el entregable más importante de su ISMS. Impulsa todo — qué controles implementa, cómo asigna recursos y qué evalúa su auditor. Para un recorrido completo, consulte nuestra guía de Evaluación de Riesgos ISO 27001.

Enfoque de evaluación de riesgos para empresas SaaS:

1. Identificar activos de información. Catalogue los sistemas, aplicaciones, almacenes de datos e información que están dentro del alcance. Para una empresa SaaS, esto incluye el entorno de producción, bases de datos, código de la aplicación, pipeline CI/CD, copias de seguridad, datos de clientes, datos de empleados e infraestructura de soporte.

2. Identificar amenazas y vulnerabilidades. Para cada activo, identifique qué podría salir mal (amenazas: acceso no autorizado, violación de datos, interrupción del servicio, malware, amenaza interna, compromiso de proveedores) y qué debilidades podrían ser explotadas (vulnerabilidades: recursos de nube mal configurados, software sin parches, controles de acceso débiles, falta de cifrado, registro insuficiente).

3. Evaluar probabilidad e impacto. Califique cada riesgo usando una escala consistente (por ejemplo, 1-5 para probabilidad y 1-5 para impacto). Multiplique para obtener un nivel de riesgo. Defina qué significa cada calificación en su contexto — un “5” para impacto en una empresa SaaS de 30 personas es diferente de un “5” en un banco multinacional.

4. Determinar el tratamiento. Para cada riesgo, decida mitigar (implementar controles), aceptar (el riesgo está dentro de la tolerancia), transferir (seguros o transferencia contractual) o evitar (eliminar la actividad que crea el riesgo).

5. Seleccionar controles. Para los riesgos que está mitigando, seleccione controles del Annex A (y cualquier control adicional que determine necesario). Documente la selección en su Declaración de Aplicabilidad.

Declaración de Aplicabilidad (SoA):

El SoA es un documento controlado que enumera los 93 controles del Annex A con:

• Si cada control es aplicable (incluido o excluido)
• Justificación para la inclusión (típicamente haciendo referencia al riesgo que aborda)
• Justificación para la exclusión (por qué el control no es necesario)
• Estado de implementación

Errores comunes:

• Evaluación de riesgos desconectada de la realidad. Una evaluación de riesgos que se completó como un ejercicio de cumplimiento, con calificaciones arbitrarias que no reflejan las amenazas reales a su plataforma SaaS, no sobrevivirá al escrutinio del auditor. Califique los riesgos basándose en inteligencia de amenazas real, incidentes reales y una evaluación genuina de sus vulnerabilidades.
• Excluir controles del Annex A sin justificación. Cada exclusión necesita una razón válida. “No queremos implementar esto” no es una justificación. “Este control se relaciona con el manejo de medios físicos y nuestra organización no maneja medios físicos” es una justificación válida.
• Sin propietarios de riesgos. Cada riesgo necesita un propietario — alguien responsable de asegurar que el riesgo se trate de acuerdo con el plan. Los auditores verifican que los propietarios de riesgos existan y entiendan su responsabilidad.
• Evaluación de riesgos estática. La evaluación de riesgos no es un documento único. Debe revisarse y actualizarse cuando ocurran cambios (nuevos productos, nueva infraestructura, nuevas amenazas, cambios organizacionales) y a intervalos planificados (al menos anualmente).

6.2 Objetivos de Seguridad de la Información y Planificación para Lograrlos

Lo que requiere el estándar: Establecer objetivos de seguridad de la información en funciones y niveles relevantes. Los objetivos deben ser consistentes con la política de seguridad de la información, medibles (si es practicable), tener en cuenta los requisitos aplicables y los resultados de la evaluación de riesgos, ser monitoreados, comunicados, actualizados según corresponda y estar disponibles como información documentada. Planifique cómo lograr los objetivos — qué se hará, recursos necesarios, quién es responsable, cuándo se completará y cómo se evaluarán los resultados.

Lo que evalúan los auditores: Objetivos documentados con planes asociados, evidencia de que los objetivos se miden y monitorean, y consistencia entre los objetivos y la política de seguridad de la información.

Implementación SaaS:

Los objetivos de seguridad de la información traducen los compromisos de su política en metas medibles. Para empresas SaaS, los objetivos efectivos incluyen:

• “Lograr y mantener una disponibilidad del sistema del 99,9% para el entorno de producción” — medible, directamente relevante para los compromisos con los clientes, respaldado por controles específicos (redundancia, conmutación por error, monitoreo).
• “Reducir el tiempo medio de detección (MTTD) de incidentes de seguridad a menos de 4 horas” — medible a través de métricas de respuesta a incidentes, impulsa la inversión en monitoreo y alertas.
• “Completar la formación en conciencia de seguridad para el 100% de los empleados dentro de los 30 días posteriores a la contratación y anualmente a partir de entonces” — medible a través de registros de la plataforma de formación, directamente vinculado a los requisitos de competencia de la Cláusula 7.2.
• “Remediar vulnerabilidades críticas en producción dentro de las 72 horas posteriores a su identificación” — medible a través de registros de gestión de vulnerabilidades, impulsa los procesos de parcheo y remediación.
• “Completar revisiones de acceso trimestrales para todos los sistemas de producción con cobertura del 100%” — medible a través de registros de revisión de acceso, aborda los riesgos de control de acceso.

Error común: Establecer objetivos que no sean medibles o que no se monitoreen. “Mejorar la seguridad de la información” no es un objetivo. “Reducir el número de incidentes de seguridad causados por recursos de nube mal configurados en un 50% año tras año” sí es un objetivo. Si no puede medirlo, no puede demostrar progreso, y el auditor lo señalará como una brecha.

6.3 Planificación de Cambios

Lo que requiere el estándar: Cuando la organización determine la necesidad de cambios en el ISMS, los cambios se llevarán a cabo de manera planificada.

Lo que evalúan los auditores: Evidencia de que los cambios en el propio ISMS (no solo cambios en los sistemas de TI) son planificados, aprobados e implementados de manera controlada.

Implementación SaaS: Esto aplica cuando cambia su ISMS — modificar el alcance, cambiar la metodología de evaluación de riesgos, reestructurar roles y responsabilidades, adoptar nuevas políticas o cambiar cómo gestiona los controles. Documente por qué se necesita el cambio, qué implica el cambio, quién lo aprobó y cómo se implementará. Mantenga un registro de cambios para su ISMS.

Esto es distinto de la gestión de cambios de TI (que cae bajo los controles del Annex A). La Cláusula 6.3 trata sobre cambios al propio sistema de gestión.

Cláusula 7: Soporte

La Cláusula 7 cubre los recursos, competencia, conciencia, comunicación y documentación que apoyan la operación de su ISMS. Sin el soporte adecuado, el ISMS no puede funcionar — los controles no se implementan, las personas no conocen sus responsabilidades y la documentación no existe para que el auditor la verifique.

7.1 Recursos

Lo que requiere el estándar: Determinar y proporcionar los recursos necesarios para establecer, implementar, mantener y mejorar continuamente el ISMS.

Lo que evalúan los auditores: Evidencia de que se asignan recursos adecuados (personas, presupuesto, herramientas, tiempo) al ISMS. Esto se conecta con la Cláusula 5.1 — el compromiso del liderazgo incluye la provisión de recursos.

Implementación SaaS: Documente su asignación de recursos para el ISMS. Esto incluye:

• Personal dedicado o compartido para la gestión del ISMS (líder de seguridad, gerente de cumplimiento o equivalente)
• Presupuesto para herramientas GRC, herramientas de seguridad, formación, consultoría y tarifas del organismo de certificación
• Tiempo de ingeniería asignado para la implementación y mantenimiento de controles de seguridad
• Tiempo asignado para evaluaciones de riesgos, auditorías internas, revisiones por la dirección y actualizaciones de políticas

Error común: No documentar formalmente la asignación de recursos. Incluso si su equipo está haciendo el trabajo, el auditor necesita evidencia de que la dirección ha asignado intencionalmente recursos — no que unas pocas personas estén haciendo trabajo de cumplimiento en su tiempo libre.

7.2 Competencia

Lo que requiere el estándar: Determinar la competencia necesaria de las personas que realizan trabajo bajo el ISMS que afecta su rendimiento, asegurar que esas personas sean competentes basándose en educación, formación o experiencia apropiadas, tomar acciones para adquirir la competencia necesaria (y evaluar la eficacia de esas acciones) y conservar evidencia de competencia.

Lo que evalúan los auditores: Registros de competencia (registros de formación, certificaciones, documentación de experiencia) para personas con responsabilidades del ISMS, además de evidencia de que las brechas de competencia han sido identificadas y abordadas.

Implementación SaaS:

Requisitos de competencia para diferentes roles en una empresa SaaS:

• Gerente del ISMS: Experiencia en implementación de ISO 27001, competencia en evaluación de riesgos, habilidades de gestión de auditorías. Evidencia: certificación de Implementador Líder ISO 27001, experiencia previa con ISMS, registros de formación relevantes.
• Auditores internos: Competencia en auditoría interna de ISO 27001. Evidencia: formación de Auditor Interno ISO 27001, experiencia previa en auditorías.
• Ingenieros con responsabilidades de seguridad: Competencia en seguridad en la nube, prácticas de desarrollo seguro. Evidencia: certificaciones de seguridad AWS/Azure/GCP, formación en codificación segura, experiencia en DevSecOps.
• Todos los empleados: Conciencia de seguridad de la información. Evidencia: registros de formación de conciencia de seguridad completados.

Error común: Asumir la competencia sin evidencia. Su CTO puede tener 15 años de experiencia en seguridad, pero el auditor necesita evidencia documentada — registros de formación, certificaciones, descripciones de puestos que muestren experiencia relevante. Mantenga registros de competencia en su plataforma GRC.

7.3 Conciencia

Lo que requiere el estándar: Las personas que realizan trabajo bajo el control de la organización deben ser conscientes de la política de seguridad de la información, su contribución a la eficacia del ISMS, las implicaciones de no conformarse con los requisitos del ISMS y cómo su trabajo afecta la seguridad de la información.

Lo que evalúan los auditores: Evidencia de que todos los empleados entienden la política de seguridad, conocen sus responsabilidades y comprenden las consecuencias del incumplimiento. Los auditores pueden entrevistar a cualquier empleado — no solo al equipo de seguridad — para verificar la conciencia.

Implementación SaaS:

• Programa de formación en conciencia de seguridad. Formación anual para todos los empleados que cubra la política de seguridad de la información, directrices de uso aceptable, procedimientos de reporte de incidentes, requisitos de manejo de datos, conciencia de phishing y riesgos de ingeniería social. Haga seguimiento de las tasas de finalización y dé seguimiento a la formación atrasada.
• Conciencia específica por rol. Los ingenieros necesitan conciencia de las prácticas de desarrollo seguro y sus responsabilidades específicas para los controles que operan. Los gerentes necesitan conciencia de sus responsabilidades de supervisión. RRHH necesita conciencia de los requisitos de seguridad para la incorporación/desvinculación.
• Incorporación de nuevos empleados. Formación en conciencia de seguridad dentro de la primera semana de empleo, incluyendo reconocimiento de políticas y acceso a toda la documentación de seguridad relevante.
• Refuerzo continuo. Boletines de seguridad, actualizaciones en canales de Slack, simulaciones de phishing y sesiones informativas de incidentes mantienen activa la conciencia de seguridad — no solo una casilla de verificación de formación anual.

Error común: Depender únicamente de la formación anual. Los auditores pueden entrevistar a cualquier empleado en cualquier momento durante la auditoría de Etapa 2. Si un desarrollador contratado hace tres meses no puede articular la política de seguridad de la información o explicar cómo reportar un incidente de seguridad, sugiere que su programa de conciencia no es eficaz.

7.4 Comunicación

Lo que requiere el estándar: Determinar la necesidad de comunicaciones internas y externas relevantes para el ISMS, incluyendo qué comunicar, cuándo, con quién, quién comunica y los procesos mediante los cuales se efectúa la comunicación.

Lo que evalúan los auditores: Un plan o matriz de comunicación documentado que cubra las comunicaciones relacionadas con el ISMS, además de evidencia de que las comunicaciones realmente ocurren.

Implementación SaaS:

Cree una matriz de comunicación:

Qué	Cuándo	Audiencia	Responsable	Método
Incidentes de seguridad	Inmediatamente al ser detectados	Interno: equipo de seguridad, liderazgo. Externo: clientes afectados, reguladores (según se requiera)	Gerente del ISMS	Proceso de respuesta a incidentes, página de estado
Cambios de políticas	Tras su aprobación	Todos los empleados	Gerente del ISMS	Correo electrónico, plataforma de gestión de políticas
Resultados de evaluación de riesgos	Tras su finalización (anual)	Liderazgo, propietarios de riesgos	Gerente del ISMS	Revisión por la dirección
Resultados de auditoría interna	Tras la finalización de la auditoría	Liderazgo, propietarios de procesos	Auditor interno	Revisión por la dirección
Métricas de rendimiento del ISMS	Trimestral	Liderazgo	Gerente del ISMS	Revisión por la dirección
Actualizaciones de conciencia de seguridad	Continuo	Todos los empleados	Gerente del ISMS	Slack, correo electrónico, plataforma de formación

Error común: No tener un plan de comunicación documentado. La comunicación informal funciona hasta que alguien olvida notificar a las personas adecuadas sobre un cambio crítico. Documente quién comunica qué a quién y cómo.

7.5 Información Documentada

Lo que requiere el estándar: El ISMS debe incluir la información documentada requerida por el estándar y la información documentada determinada por la organización como necesaria para la eficacia del ISMS. La información documentada debe controlarse — crearse, actualizarse, controlarse, distribuirse, accederse, almacenarse, preservarse y eliminarse apropiadamente.

Lo que evalúan los auditores: La existencia, calidad y control de toda la información documentada requerida. Esto incluye políticas, procedimientos, registros, evaluaciones de riesgos, el SoA, informes de auditoría interna, actas de revisión por la dirección, registros de acciones correctivas y más.

Implementación SaaS:

ISO 27001:2022 requiere la siguiente información documentada (esta no es una lista exhaustiva — el estándar hace referencia a “información documentada” a lo largo del mismo):

• Declaración del alcance del ISMS (4.3)
• Política de seguridad de la información (5.2)
• Proceso y resultados de evaluación de riesgos (6.1.2)
• Plan de tratamiento de riesgos (6.1.3)
• Declaración de Aplicabilidad (6.1.3)
• Objetivos de seguridad de la información (6.2)
• Registros de competencia (7.2)
• Registros de planificación y control operacional (8.1)
• Resultados de la evaluación de riesgos (8.2)
• Resultados del tratamiento de riesgos (8.3)
• Resultados de monitoreo y medición (9.1)
• Programa y resultados de auditoría interna (9.2)
• Resultados de la revisión por la dirección (9.3)
• No conformidades y acciones correctivas (10.2)

Requisitos de control de documentos:

• Control de versiones (rastrear quién cambió qué y cuándo)
• Flujos de trabajo de aprobación (los documentos son revisados y aprobados antes de su publicación)
• Control de acceso (los documentos están disponibles para quienes los necesitan y protegidos contra cambios no autorizados)
• Programación de revisiones (los documentos se revisan a intervalos planificados y se actualizan según sea necesario)
• Políticas de retención (los documentos se conservan durante un período apropiado y se eliminan adecuadamente)

Una plataforma GRC maneja el control de documentos de forma nativa — historial de versiones, flujos de trabajo de aprobación, permisos de acceso y recordatorios de revisión están incorporados. Consulte nuestra guía de Políticas ISO 27001 para orientación completa sobre documentación.

Error común: Tratar la documentación como un entregable único. Las políticas escritas para la auditoría de certificación y nunca actualizadas quedan obsoletas en meses. El auditor en su primera auditoría de vigilancia verificará las fechas de revisión de los documentos y preguntará sobre los cambios desde la certificación inicial. Los documentos obsoletos sugieren un ISMS obsoleto.

Cláusula 8: Operación

La Cláusula 8 trata sobre ejecutar los planes establecidos en la Cláusula 6. Donde la Cláusula 6 dice “planificar”, la Cláusula 8 dice “hacer”. Aquí es donde el ISMS opera de manera diaria.

8.1 Planificación y Control Operacional

Lo que requiere el estándar: Planificar, implementar y controlar los procesos necesarios para cumplir con los requisitos del ISMS y para implementar las acciones determinadas en 6.1 (tratamiento de riesgos) y 6.2 (objetivos). Controlar los cambios planificados y revisar las consecuencias de los cambios no previstos, tomando medidas para mitigar los efectos adversos. Asegurar que los procesos externalizados estén controlados.

Lo que evalúan los auditores: Evidencia de que sus controles planificados están operando en la práctica — no solo documentados, sino realmente en funcionamiento. El auditor verifica que lo que dijo que haría (en políticas, procedimientos y el plan de tratamiento de riesgos) es lo que realmente está haciendo.

Implementación SaaS:

Para empresas SaaS, la planificación y el control operacional significan:

• Operaciones de control. Sus controles del Annex A deben estar operando como están documentados. Si su política de control de acceso dice que las revisiones de acceso ocurren trimestralmente, necesitan ocurrir realmente cada trimestre. Si su procedimiento de gestión de cambios requiere revisión de código antes del despliegue, las revisiones de código deben estar ocurriendo para cada despliegue.
• Gestión de cambios. Los cambios en el alcance, controles o procesos del ISMS deben ser planificados, aprobados y documentados. Esto incluye cambios de infraestructura que afectan los controles de seguridad.
• Procesos externalizados. Si externaliza procesos relevantes para la seguridad (SOC gestionado, pruebas de penetración, gestión de infraestructura en la nube), necesita controlar esos procesos a través de contratos, SLAs y monitoreo. Esto se conecta con los controles de gestión de proveedores del Annex A.
• Evidencia de operación. Mantenga registros que demuestren que los controles están operando — registros de revisión de acceso, registros de gestión de cambios, registros de respuesta a incidentes, resultados de escaneo de vulnerabilidades, registros de finalización de formación. Esta evidencia cumple doble función: satisface al auditor y le da visibilidad sobre la eficacia de su propio programa.

Error común: Implementar controles para la auditoría y luego dejar que se deterioren. Si realiza una revisión de acceso exhaustiva antes de la auditoría de Etapa 2 pero luego se salta las siguientes tres revisiones trimestrales, el auditor de vigilancia encontrará la brecha. Los controles deben operar continuamente, no solo durante la preparación de la auditoría.

8.2 Evaluación de Riesgos de Seguridad de la Información

Lo que requiere el estándar: Realizar evaluaciones de riesgos de seguridad de la información a intervalos planificados o cuando se propongan o se produzcan cambios significativos, conservando información documentada de los resultados.

Lo que evalúan los auditores: Evidencia de que las evaluaciones de riesgos se realizan con la frecuencia definida en su proceso de evaluación de riesgos (típicamente al menos anualmente) y siempre que ocurran cambios significativos. El auditor verifica fechas, historial de versiones y contenido.

Implementación SaaS:

• Evaluaciones planificadas. Realice una evaluación de riesgos integral al menos anualmente. Revise y actualice el registro de riesgos, reevalúe las calificaciones de riesgos, evalúe la eficacia de los tratamientos existentes e identifique nuevos riesgos.
• Evaluaciones desencadenadas por cambios. Cuando ocurran cambios significativos — lanzamientos de nuevos productos, migraciones importantes de infraestructura, entrada a nuevos mercados, reestructuración organizacional, nuevas relaciones con proveedores, incidentes de seguridad significativos — realice una evaluación de riesgos dirigida para las áreas afectadas.
• Integración con las operaciones. Para empresas SaaS, integre los desencadenantes de evaluación de riesgos en su ciclo de vida de desarrollo. Cuando una nueva funcionalidad maneja datos sensibles o se propone una nueva integración con terceros, una evaluación de riesgos debe ser parte del proceso de evaluación.

Para orientación completa, consulte nuestra guía de Evaluación de Riesgos ISO 27001.

8.3 Tratamiento de Riesgos de Seguridad de la Información

Lo que requiere el estándar: Implementar el plan de tratamiento de riesgos de seguridad de la información y conservar información documentada de los resultados.

Lo que evalúan los auditores: Evidencia de que el plan de tratamiento de riesgos de 6.1.3 se está ejecutando — los controles están implementados, los propietarios de riesgos están haciendo seguimiento del progreso y las actividades de tratamiento se completan de acuerdo con el plan.

Implementación SaaS: Haga seguimiento de las actividades de tratamiento de riesgos en su plataforma GRC. Cada acción de tratamiento debe tener un propietario, una fecha límite, un estado y evidencia de finalización. Cuando un tratamiento de riesgos es “implementar MFA para todos los accesos a producción”, la evidencia de finalización son los registros de configuración de MFA, la documentación de la política y la verificación de que todos los usuarios se han inscrito.

Error común: Tener un plan de tratamiento de riesgos que muestra “mitigar” para un riesgo, pero sin evidencia de que los controles de mitigación estén realmente implementados. La brecha entre el plan y la ejecución es una de las fuentes más comunes de no conformidades.

Cláusula 9: Evaluación del Rendimiento

La Cláusula 9 requiere que mida, monitoree y evalúe la eficacia de su ISMS. Esta es la fase de “verificar” del ciclo PDCA — y es donde muchos equipos SaaS son más débiles, porque medir la eficacia del programa de seguridad es más difícil que implementar controles.

9.1 Monitoreo, Medición, Análisis y Evaluación

Lo que requiere el estándar: Determinar qué necesita ser monitoreado y medido, los métodos para el monitoreo y la medición, cuándo se realizarán el monitoreo y la medición, quién monitoreará y medirá, cuándo se analizarán y evaluarán los resultados, y quién analizará y evaluará los resultados. Conservar información documentada como evidencia.

Lo que evalúan los auditores: Métricas documentadas, evidencia de que las métricas se miden con la frecuencia definida y evidencia de que los resultados se analizan y alimentan las actividades de mejora.

Implementación SaaS:

Defina métricas de rendimiento del ISMS que sean significativas para una empresa SaaS:

• Métricas de respuesta a incidentes. Tiempo medio de detección (MTTD), tiempo medio de respuesta (MTTR), número de incidentes por gravedad, categorías de causa raíz.
• Métricas de gestión de vulnerabilidades. Tiempo para remediar vulnerabilidades críticas/altas/medias, número de vulnerabilidades abiertas por gravedad, tasas de cumplimiento de parches.
• Métricas de gestión de acceso. Tasas de finalización de revisiones de acceso, porcentaje de revisiones de acceso completadas a tiempo, número de excepciones de acceso identificadas y resueltas.
• Métricas de formación. Tasas de finalización de formación en conciencia de seguridad, tasas de clic en simulaciones de phishing, tiempo para completar la formación de nuevos empleados.
• Métricas de cumplimiento de políticas. Número de violaciones de políticas identificadas, acciones correctivas completadas, tasas de finalización de revisiones de políticas.
• Métricas de disponibilidad. Tiempo de actividad del sistema, número y duración de interrupciones, tiempo de recuperación después de incidentes.
• Métricas de riesgo. Número de riesgos por encima de la tolerancia, tasas de finalización del plan de tratamiento de riesgos, número de nuevos riesgos identificados por trimestre.

Frecuencia de medición: Mida estas métricas a intervalos que le permitan detectar tendencias y tomar medidas. Medición mensual o trimestral para la mayoría de las métricas, con monitoreo continuo para métricas críticas (disponibilidad, detección de incidentes).

Error común: Recopilar métricas pero no analizarlas. Los números sin procesar sin análisis y acción son inútiles. Su revisión por la dirección (9.3) debe incluir análisis de tendencias, identificación de áreas problemáticas y decisiones sobre acciones de mejora. Si su MTTR está aumentando trimestre tras trimestre, ¿qué va a hacer al respecto?

9.2 Auditoría Interna

Lo que requiere el estándar: Realizar auditorías internas a intervalos planificados para determinar si el ISMS se ajusta a los propios requisitos de la organización, se ajusta a los requisitos de ISO 27001 y está eficazmente implementado y mantenido. Establecer un programa de auditoría, definir criterios y alcance de cada auditoría, seleccionar auditores que aseguren objetividad e imparcialidad, informar resultados a la dirección relevante y conservar información documentada.

Lo que evalúan los auditores: El programa de auditoría interna, planes e informes de auditorías individuales, registros de competencia de los auditores, evidencia de que los hallazgos fueron reportados a la dirección y evidencia de que se tomaron acciones correctivas para las no conformidades identificadas.

Implementación SaaS:

La auditoría interna es una actividad crítica previa a la certificación y un requisito continuo. Para orientación completa, consulte nuestra guía de Auditoría Interna ISO 27001.

Principios clave para empresas SaaS:

• Frecuencia de auditoría. Realice una auditoría interna integral al menos anualmente, cubriendo todos los requisitos del ISMS. Muchas organizaciones auditan diferentes áreas en un programa rotativo — por ejemplo, auditar las Cláusulas 4-6 en el T1, la Cláusula 7 en el T2, la Cláusula 8 en el T3 y las Cláusulas 9-10 en el T4.
• Independencia del auditor. Los auditores internos no deben auditar su propio trabajo. Si el Gerente del ISMS elaboró la evaluación de riesgos, otra persona debe auditarla. En empresas SaaS pequeñas, esto puede ser un desafío — considere usar un consultor externo para las auditorías internas, o capacite cruzadamente a miembros del equipo para auditar áreas fuera de su responsabilidad.
• Metodología de auditoría. Use un enfoque sistemático — revise la documentación, entreviste a los propietarios de procesos, examine la evidencia, pruebe los controles y compare los hallazgos con los requisitos. Documente los hallazgos como conformidades, observaciones (áreas de mejora) o no conformidades (incumplimientos de los requisitos).
• Acciones correctivas. Cada no conformidad identificada en la auditoría interna debe tener una acción correctiva — un plan documentado para corregir el problema, prevenir la recurrencia y verificar que la corrección fue eficaz. Haga seguimiento de las acciones correctivas hasta su finalización.

Error común: Realizar una auditoría interna superficial que no identifica ningún hallazgo. Una auditoría interna sin hallazgos es una señal de alerta para el auditor externo — sugiere que la auditoría no fue lo suficientemente exhaustiva. Todo ISMS tiene áreas de mejora. Una buena auditoría interna las encuentra antes de que lo haga el organismo de certificación.

9.3 Revisión por la Dirección

Lo que requiere el estándar: La alta dirección debe revisar el ISMS a intervalos planificados para asegurar su continua idoneidad, adecuación y eficacia. La revisión debe considerar: el estado de las acciones de revisiones por la dirección anteriores, cambios en las cuestiones externas e internas relevantes para el ISMS, retroalimentación sobre el rendimiento del ISMS (incluyendo no conformidades, resultados de monitoreo, resultados de auditoría y cumplimiento de objetivos), retroalimentación de las partes interesadas, resultados de la evaluación de riesgos y estado del plan de tratamiento de riesgos, y oportunidades de mejora continua. Los resultados deben incluir decisiones relacionadas con oportunidades de mejora continua y cualquier necesidad de cambios en el ISMS.

Lo que evalúan los auditores: Actas de revisión por la dirección (o registros) que muestren que se discutieron todos los temas de entrada requeridos, que se tomaron decisiones y que se asignaron acciones con propietarios y plazos. Los auditores también verifican las listas de asistentes para confirmar la participación de la alta dirección.

Implementación SaaS:

• Frecuencia. Al menos anualmente, aunque muchas organizaciones realizan revisiones por la dirección semestralmente o trimestralmente. Las revisiones más frecuentes son mejores para mantener el compromiso de la dirección y detectar problemas tempranamente.
• Asistentes. CEO o equivalente, CTO, Gerente del ISMS y otros líderes relevantes. Esta es una reunión de dirección, no una reunión del equipo de seguridad.
• Agenda estructurada. Siga las entradas requeridas del estándar como plantilla de su agenda. Para cada punto, presente datos, discuta implicaciones y documente decisiones.
• Resultados documentados. Registre decisiones, acciones, personas responsables y plazos. Las actas de revisión por la dirección son un registro documentado obligatorio que los auditores examinan.

Plantilla de revisión por la dirección para empresas SaaS:

1. Estado de las acciones de la revisión anterior
2. Cambios en el contexto (nuevas regulaciones, cambios de mercado, cambios organizacionales)
3. Retroalimentación de partes interesadas (requisitos de seguridad de clientes, desarrollos regulatorios)
4. Métricas de rendimiento del ISMS (tendencias de incidentes, métricas de vulnerabilidades, finalización de formación)
5. Resultados de auditorías internas y externas
6. Estado de la evaluación de riesgos y progreso del tratamiento de riesgos
7. Oportunidades de mejora
8. Necesidades de recursos
9. Decisiones y acciones

Error común: Omitir la revisión por la dirección o realizarla como una formalidad sin discusión significativa. La revisión por la dirección es donde el liderazgo demuestra compromiso activo con el ISMS. Si las actas muestran una reunión de 15 minutos sin discusión ni decisiones, el auditor cuestionará si el compromiso del liderazgo (Cláusula 5.1) es genuino.

Cláusula 10: Mejora

La Cláusula 10 cierra el ciclo PDCA. Requiere que su organización responda a los problemas (no conformidades) y busque proactivamente formas de mejorar el ISMS. Esta es la cláusula que separa un ISMS impulsado por el cumplimiento de un programa de seguridad genuinamente eficaz.

10.1 Mejora Continua

Lo que requiere el estándar: Mejorar continuamente la idoneidad, adecuación y eficacia del ISMS.

Lo que evalúan los auditores: Evidencia de que el ISMS está mejorando con el tiempo — no solo manteniendo el statu quo, sino mejorando activamente. Los auditores buscan acciones de mejora impulsadas por actualizaciones de la evaluación de riesgos, hallazgos de auditorías internas, decisiones de la revisión por la dirección, lecciones aprendidas de incidentes y tendencias de métricas de rendimiento.

Implementación SaaS:

La mejora continua en un ISMS SaaS incluye:

• Mejoras post-incidente. Después de cada incidente de seguridad, realice una revisión de lecciones aprendidas e implemente cambios para prevenir la recurrencia. Haga seguimiento de estas mejoras como acciones correctivas o preventivas.
• Mejoras impulsadas por auditorías. Los hallazgos de auditorías internas y externas deben impulsar mejoras específicas. Hágales seguimiento a través de su proceso de acciones correctivas.
• Mejoras impulsadas por métricas. Cuando las métricas del ISMS muestran tendencias negativas (MTTR creciente, finalización de formación decreciente, acumulación creciente de vulnerabilidades), inicie proyectos de mejora.
• Mejoras proactivas. No espere a que surjan problemas. Busque oportunidades — nuevas tecnologías de seguridad, mejores procesos, mejores prácticas de la industria, retroalimentación de su equipo — e impleméntelas como mejoras planificadas.
• Progresión de madurez. Documente el nivel de madurez de su ISMS y establezca objetivos de avance. Un ISMS de primer año tendrá procesos básicos; para el tercer año, esos procesos deberían estar optimizados, automatizados donde sea posible y profundamente integrados en las operaciones.

Para un enfoque integral para construir un programa de mejora sostenible, consulte nuestra guía de Mejora Continua ISO 27001.

Error común: Tratar la mejora continua como una aspiración vaga en lugar de un proceso gestionado. La mejora debe rastrearse en su plataforma GRC — cada iniciativa de mejora tiene un propietario, una descripción, una fecha objetivo y evidencia de finalización. Cuando el auditor pregunte “¿cómo ha mejorado su ISMS desde el año pasado?”, debería tener una lista concreta.

10.2 No Conformidad y Acción Correctiva

Lo que requiere el estándar: Cuando ocurra una no conformidad, reaccionar ante ella (controlarla y corregirla, lidiar con las consecuencias), evaluar la necesidad de acción para eliminar la causa para que no se repita, implementar cualquier acción necesaria, revisar la eficacia de la acción correctiva y realizar cambios en el ISMS si es necesario. Conservar información documentada sobre la naturaleza de las no conformidades y las acciones tomadas, y los resultados de las acciones correctivas.

Lo que evalúan los auditores: Un proceso de acción correctiva que esté documentado y se siga, además de registros que muestren cómo se manejaron las no conformidades específicas — cuál fue la no conformidad, qué la causó, qué acción correctiva se tomó y si la acción correctiva fue eficaz.

Implementación SaaS:

Las no conformidades provienen de múltiples fuentes:

• Hallazgos de auditorías internas
• Hallazgos de auditorías externas (del organismo de certificación)
• Incidentes de seguridad
• Quejas de clientes relacionadas con la seguridad de la información
• Fallos de procesos o fallos de controles
• Problemas reportados por empleados

Proceso de acción correctiva para empresas SaaS:

1. Registrar la no conformidad. Documente qué sucedió, cuándo y el impacto. Sea específico — “revisión de acceso no completada” es mejor que “fallo de proceso”.
2. Contener el impacto inmediato. Si la no conformidad creó un riesgo de seguridad, abórdelo inmediatamente. Si una revisión de acceso reveló acceso no autorizado, revoque el acceso primero y luego investigue.
3. Identificar la causa raíz. No solo corrija el síntoma. Si la revisión de acceso no se completó, ¿por qué? ¿La persona responsable estaba sobrecargada? ¿No había un proceso de recordatorio? ¿El procedimiento era poco claro? El análisis de causa raíz previene la recurrencia.
4. Implementar la acción correctiva. Diseñe e implemente una solución que aborde la causa raíz. Si la causa raíz fue “no hay proceso de recordatorio”, implemente recordatorios automatizados en su plataforma GRC.
5. Verificar la eficacia. Después de implementar la acción correctiva, verifique que funcionó. ¿Se completó a tiempo la siguiente revisión de acceso? ¿Se ha eliminado la causa raíz?
6. Cerrar el registro. Documente la resolución y cierre la acción correctiva en su sistema de seguimiento.

Error común: Corregir síntomas sin abordar las causas raíz. Si sigue encontrando los mismos tipos de no conformidades en auditorías sucesivas, sus acciones correctivas no son eficaces. Los auditores específicamente verifican los hallazgos recurrentes — y los hallazgos recurrentes sugieren que su proceso de mejora (Cláusula 10) no está funcionando.

Errores Comunes de Implementación en Todas las Cláusulas

Habiendo examinado cada cláusula individualmente, estos son los errores sistémicos que causan más problemas en todo el ISMS:

ISMS de Papel

El error más fundamental es construir un ISMS que existe en papel pero no en la práctica. Políticas que nadie sigue, evaluaciones de riesgos que no reflejan la realidad, controles que no están operando, métricas que no se miden. El trabajo del auditor es verificar que su ISMS está implementado y mantenido — no solo documentado. Si sus políticas dicen una cosa y sus operaciones hacen otra, el auditor identificará no conformidades.

Solución: Escriba políticas y procedimientos que reflejen lo que realmente hace (o lo que puede comprometerse realistamente a hacer). Comience con sus operaciones actuales y formalícelas, en lugar de escribir políticas aspiracionales y esperar que las operaciones las alcancen.

Tratar ISO 27001 como un Proyecto de TI

ISO 27001 es un estándar de sistema de gestión, no un estándar de tecnología. Requiere participación del liderazgo (Cláusula 5), conciencia organizacional (Cláusula 7.3), revisión por la dirección (Cláusula 9.3) y mejora continua (Cláusula 10). Tratarlo como un proyecto de TI — delegar todo al equipo de ingeniería y esperar que entreguen un certificado — pasa por alto los requisitos del sistema de gestión y resulta en cláusulas 5, 9 y 10 débiles.

Solución: Involucre al liderazgo desde el principio. Haga de la revisión por la dirección una actividad genuina de liderazgo. Asegúrese de que el proyecto del ISMS tenga patrocinio ejecutivo, no solo recursos de ingeniería.

Ignorar la Cláusula 10

La mayoría de los equipos SaaS se enfocan mucho en construir el ISMS (Cláusulas 4-8) y medirlo (Cláusula 9), pero subinvierten en mejora (Cláusula 10). El auditor en su primera auditoría de vigilancia preguntará qué ha mejorado desde la certificación. Si la respuesta es “nada”, eso es un problema.

Solución: Incorpore la mejora en las operaciones de su ISMS desde el principio. Rastree las mejoras explícitamente. Establezca objetivos de mejora junto con sus objetivos de seguridad de la información (Cláusula 6.2).

Exceso de Ingeniería en la Documentación

Algunas organizaciones crean cientos de páginas de documentación — procedimientos detallados para cada escenario concebible, jerarquías complejas de políticas, flujos de procesos elaborados. Esto crea una carga de documentación que es imposible de mantener y que a menudo no coincide con cómo opera realmente la organización.

Solución: Escriba la documentación mínima necesaria para cumplir con los requisitos del estándar y para apoyar operaciones eficaces. ISO 27001:2022 es menos prescriptivo sobre la documentación que las versiones anteriores — aprovéchelo. Una política concisa y precisa es mejor que una extensa y desactualizada.

Evaluación de Riesgos Desconectada

Si su evaluación de riesgos se realizó como un ejercicio aislado (llenar una hoja de cálculo, archivarla) en lugar de como el motor de su selección de controles y asignación de recursos, su ISMS carece de coherencia. El auditor rastreará desde los riesgos hasta los controles y la evidencia — si los hilos no se conectan, el ISMS no funciona como sistema.

Solución: Haga de la evaluación de riesgos el artefacto central de su ISMS. Cada control en su SoA debe rastrearse hasta un riesgo. Cada riesgo debe rastrearse hacia adelante hasta controles y evidencia. Esta trazabilidad es lo que hace del ISMS un sistema, no una colección de documentos.

Cómo Ayuda GRCTrail

GRCTrail está diseñado para ayudar a los equipos SaaS a implementar los requisitos de ISO 27001 de manera eficiente y mantener el cumplimiento con cada cláusula.

• Flujos de trabajo de implementación estructurados cláusula por cláusula que guían a su equipo a través de cada requisito de las Cláusulas 4-10, proporcionando plantillas, listas de verificación y ejemplos específicos para empresas SaaS — para que construya un ISMS conforme sin necesitar experiencia profunda en ISO 27001 desde el primer día
• Gestión integrada de evaluación de riesgos y Declaración de Aplicabilidad que asegura que su registro de riesgos, planes de tratamiento y selecciones de controles del Annex A se mantengan conectados y trazables — eliminando las hojas de cálculo desconectadas que causan no conformidades durante las auditorías
• Recopilación automatizada de evidencia, seguimiento de auditorías internas y flujos de trabajo de revisión por la dirección que manejan los requisitos operativos continuos de las Cláusulas 8, 9 y 10 — para que su ISMS funcione continuamente en lugar de activarse solo durante la preparación de la auditoría

Comience con GRCTrail →

Guías Relacionadas

• ¿Qué es ISO 27001? Una Guía Completa para Empresas SaaS
• Lista de Verificación de Certificación ISO 27001
• Guía de Evaluación de Riesgos ISO 27001
• Guía de Políticas y Documentación ISO 27001
• Guía de Auditoría Interna ISO 27001
• Controles del Annex A de ISO 27001 Explicados
• Guía de Mejora Continua ISO 27001