Evaluación de Riesgos ISO 27001: Proceso, Metodología y Ejemplos

La evaluación de riesgos es el motor que impulsa todo su Sistema de Gestión de Seguridad de la Información. Sin ella, su ISMS es una colección de políticas y controles elegidos por instinto en lugar de por evidencia. ISO 27001 no deja esto a la interpretación — la Cláusula 6.1.2 exige un proceso formal y repetible de evaluación de riesgos que identifique amenazas, evalúe su severidad y produzca un plan de tratamiento de riesgos que vincule cada riesgo significativo con una respuesta concreta.

Para las empresas SaaS, la evaluación de riesgos determina qué controles del Annex A implementa, cuáles excluye (documentados en su Declaración de Aplicabilidad) y cómo asigna los recursos limitados de seguridad. Una evaluación de riesgos que refleje su panorama real de amenazas — errores de configuración en infraestructura cloud, ataques a la cadena de suministro a través de dependencias de código abierto, fallos en el aislamiento de datos multitenant — produce un ISMS que genuinamente protege su negocio. Una evaluación genérica copiada de una plantilla produce hallazgos de auditoría y, peor aún, vulnerabilidades sin abordar.

Esta guía recorre todo el proceso de evaluación de riesgos ISO 27001: qué requiere la norma, cómo elegir y aplicar una metodología, cómo puntuar y tratar los riesgos, y las consideraciones específicas que aplican a las organizaciones SaaS.

¿Qué Requiere ISO 27001 para la Evaluación de Riesgos?

La Cláusula 6.1.2 de ISO 27001 establece seis requisitos explícitos para el proceso de evaluación de riesgos de seguridad de la información. Comprender cada requisito es esencial antes de comenzar a construir su metodología.

Requisito 1: Establecer y Mantener Criterios de Evaluación de Riesgos

Debe definir y documentar los criterios que utilizará para evaluar los riesgos. Esto incluye sus criterios de aceptación de riesgos (qué nivel de riesgo residual es tolerable) y los criterios para realizar la evaluación de riesgos en sí (cómo medirá la probabilidad y el impacto). Estos criterios deben establecerse antes de que comience la evaluación — no retroajustados para justificar decisiones ya tomadas.

En la práctica: Defina sus escalas de puntuación de riesgos, sus umbrales de apetito de riesgo y las reglas para cuándo un riesgo debe ser tratado versus cuándo puede ser aceptado. Documente estos en su política de gestión de riesgos para que sean consistentes entre evaluaciones y auditables.

Requisito 2: Asegurar Resultados Repetibles y Consistentes

El proceso de evaluación de riesgos debe producir resultados consistentes, válidos y comparables cuando se repite. Esto significa que su metodología no puede depender del juicio de una sola persona sin estructura. Dos equipos diferentes ejecutando la misma evaluación contra el mismo alcance deberían llegar a conclusiones razonablemente similares.

En la práctica: Use escalas de puntuación definidas, criterios documentados para cada nivel de calificación y talleres estructurados en lugar de lluvias de ideas ad hoc. Una matriz de probabilidad-impacto 5x5 con descripciones escritas para cada nivel produce resultados más consistentes que “discutir y acordar una calificación.”

Requisito 3: Identificar Riesgos de Seguridad de la Información

Debe identificar los riesgos asociados con la pérdida de confidencialidad, integridad y disponibilidad de la información dentro del alcance del ISMS. Esto requiere una identificación sistemática — no simplemente listar las amenazas obvias.

En la práctica: Esto significa identificar los activos de información en alcance, las amenazas a esos activos, las vulnerabilidades que las amenazas podrían explotar y las consecuencias potenciales. Para las empresas SaaS, el alcance típicamente cubre la infraestructura de producción, los datos de clientes, los sistemas internos que soportan el servicio y las personas y procesos que los operan.

Requisito 4: Analizar los Riesgos Identificados

Cada riesgo identificado debe ser analizado para determinar su probabilidad de ocurrencia y el impacto potencial si se materializa. Este análisis produce el nivel de riesgo que impulsa las decisiones de tratamiento.

En la práctica: Aplique sus criterios de puntuación de manera consistente. Para cada riesgo, evalúe tanto la probabilidad de que la amenaza explote la vulnerabilidad como el impacto empresarial si lo hace. Documente la justificación — no solo los números.

Requisito 5: Evaluar los Riesgos Identificados

Debe comparar los resultados del análisis de riesgos contra sus criterios de aceptación de riesgos y priorizar los riesgos para su tratamiento. La evaluación determina qué riesgos requieren acción y en qué orden.

En la práctica: Los riesgos por encima de su umbral de aceptación requieren tratamiento. Los riesgos por debajo pueden ser aceptados — pero la aceptación debe ser una decisión documentada, no un valor predeterminado. La priorización asegura que aborde primero los riesgos más críticos, lo cual importa cuando los recursos son limitados (como siempre lo son en empresas SaaS en crecimiento).

Requisito 6: Documentar los Resultados

Los resultados de la evaluación de riesgos deben conservarse como información documentada. Esto no es negociable. Su registro de riesgos, documentación de metodología, justificación de puntuación y decisiones de tratamiento son todos artefactos auditables.

En la práctica: Mantenga un registro de riesgos que capture cada riesgo identificado, su análisis, su evaluación y la decisión de tratamiento. Este registro es un documento vivo — se revisa y actualiza a lo largo del ciclo de vida del ISMS, no solo durante las evaluaciones anuales.

Elección de su Metodología de Evaluación de Riesgos

ISO 27001 no prescribe una metodología específica. Requiere que su enfoque elegido cumpla con los seis requisitos anteriores, pero el marco específico es su decisión. Esta flexibilidad es intencional — diferentes organizaciones tienen diferentes perfiles de riesgo, recursos y niveles de madurez.

Evaluación de Riesgos Cualitativa

La evaluación cualitativa utiliza categorías descriptivas (Alto, Medio, Bajo, o escalas numéricas como 1-5) en lugar de valores financieros precisos. Es el enfoque más común para las empresas SaaS que buscan ISO 27001 por primera vez.

Cómo funciona: Los riesgos se puntúan en dos dimensiones — probabilidad e impacto — usando escalas predefinidas. Las puntuaciones se multiplican o combinan para producir una calificación de riesgo general que determina la prioridad de tratamiento.

Ventajas:

• Más rápida de implementar y más fácil de mantener
• No requiere datos actuariales o cifras históricas de pérdidas
• Accesible para partes interesadas no técnicas que participan en talleres de riesgo
• Suficiente para la certificación — los auditores aceptan enfoques cualitativos

Desventajas:

• Subjetiva — diferentes evaluadores pueden asignar diferentes puntuaciones al mismo riesgo
• No produce estimaciones en valor monetario útiles para cálculos de ROI en inversiones de seguridad
• Puede llevar a agrupamiento (todo calificado como “Medio”) si las escalas no están bien definidas

Ideal para: Empresas SaaS con menos de 500 empleados, organizaciones que buscan certificación inicial, equipos sin analistas de riesgo dedicados.

Evaluación de Riesgos Cuantitativa

La evaluación cuantitativa asigna valores monetarios tanto a la probabilidad de ocurrencia como al impacto potencial. Utiliza fórmulas como la Expectativa de Pérdida Anual (ALE) = Expectativa de Pérdida Única (SLE) x Tasa Anual de Ocurrencia (ARO) para producir estimaciones de riesgo en valor monetario.

Cómo funciona: Para cada riesgo, se estima el costo financiero si el evento ocurre (SLE) y con qué frecuencia se espera que ocurra por año (ARO). El producto es la pérdida anual esperada, que puede compararse directamente con el costo de mitigación para determinar si una inversión en control está justificada.

Ventajas:

• Produce cifras financieras que resuenan con la dirección ejecutiva y juntas directivas
• Permite un análisis directo de costo-beneficio de las inversiones en controles
• Reduce la subjetividad cuando hay datos confiables disponibles

Desventajas:

• Requiere datos históricos y estimaciones actuariales que muchas empresas SaaS no tienen
• Intensiva en tiempo para desarrollar y mantener
• Falsa precisión — los números pueden crear una ilusión de exactitud cuando las suposiciones subyacentes son estimaciones aproximadas

Ideal para: Organizaciones maduras con funciones dedicadas de gestión de riesgos, empresas con extensos datos de historial de incidentes, grandes empresas donde los informes a nivel de junta requieren cuantificación financiera del riesgo.

Enfoque Híbrido

Muchas organizaciones utilizan la evaluación cualitativa como metodología principal y la complementan con análisis cuantitativo para los riesgos de mayor prioridad o para decisiones específicas de inversión. Este es un enfoque pragmático que satisface la norma mientras proporciona contexto financiero donde más importa.

Ejemplo: Una empresa SaaS utiliza una matriz cualitativa 5x5 para su evaluación de riesgos anual pero realiza un análisis cuantitativo al evaluar si invertir $200,000 en una nueva solución WAF versus aceptar el riesgo de ataques a la capa de aplicación.

Evaluación Basada en Activos vs. Basada en Escenarios

Más allá de la distinción cualitativa/cuantitativa, también necesita decidir su enfoque de identificación.

La evaluación basada en activos comienza con un inventario de activos de información (bases de datos, servidores, aplicaciones, almacenes de datos) e identifica amenazas y vulnerabilidades para cada activo. Es exhaustiva pero puede ser laboriosa para organizaciones con inventarios extensos de activos.

La evaluación basada en escenarios comienza con escenarios de amenazas (por ejemplo, “ransomware cifra las bases de datos de producción,” “laptop de desarrollador robada con credenciales en caché”) y traza el impacto a los activos afectados. Esto es a menudo más eficiente para las empresas SaaS porque se enfoca en rutas de ataque realistas en lugar de catalogar exhaustivamente cada activo.

La norma permite ambos. La mayoría de las empresas SaaS se benefician de un enfoque basado en escenarios anclado a un inventario de activos de alto nivel. Necesita saber qué activos existen, pero su identificación de riesgos se organiza alrededor de escenarios de amenazas en lugar de enumeración activo por activo.

Identificación y Clasificación de Activos

Independientemente de su metodología, necesita saber qué está protegiendo. ISO 27001 requiere que los activos de información dentro del alcance del ISMS sean identificados y clasificados.

Categorías de Activos de Información

Activos de datos: Datos de clientes (PII, datos comerciales, analíticas de uso), datos de empleados, registros financieros, propiedad intelectual (código fuente, algoritmos, datos de entrenamiento), credenciales de autenticación, claves de cifrado, datos de configuración, registros.

Activos tecnológicos: Servidores de producción, bases de datos, repositorios de código de aplicación, pipelines CI/CD, sistemas de monitoreo, almacenamiento de respaldo, entornos de desarrollo y staging, herramientas SaaS utilizadas internamente (proveedores de identidad, gestión de proyectos, plataformas de comunicación).

Activos humanos: Empleados con acceso a sistemas sensibles, contratistas, personal de soporte de terceros. Las personas son activos porque su conocimiento, acceso y acciones afectan directamente la seguridad de la información.

Activos de procesos: Procedimientos de respuesta a incidentes, flujos de trabajo de gestión de cambios, procesos de respaldo, procedimientos de incorporación/desvinculación. Estos son activos porque su fallo o ausencia crea riesgo.

Propiedad de Activos

Cada activo debe tener un propietario designado — una persona responsable de la protección del activo. Los propietarios de activos son responsables de asegurar que los riesgos a sus activos sean identificados, evaluados y tratados. En las empresas SaaS, la propiedad de activos típicamente sigue la estructura de la organización de ingeniería: el equipo que construye y opera un sistema posee los activos asociados.

Clasificación

Clasifique los activos según la sensibilidad y criticidad de la información que contienen o procesan. Un esquema simple de tres niveles funciona para la mayoría de las empresas SaaS:

• Confidencial — Datos de clientes, credenciales, claves de cifrado, código fuente. La divulgación no autorizada causaría un daño significativo.
• Interno — Documentos empresariales internos, información no sensible de empleados, planes de proyectos. La divulgación causaría un impacto moderado.
• Público — Materiales de marketing, documentación publicada, especificaciones de API públicas. Sin impacto por divulgación.

La clasificación determina el nivel de protección requerido e influye en la puntuación de riesgos — una amenaza a un activo Confidencial tiene mayor impacto que la misma amenaza a un activo Público.

Análisis de Amenazas y Vulnerabilidades

Con sus activos identificados, puede identificar sistemáticamente qué podría salir mal y por qué.

Identificación de Amenazas

Las amenazas son eventos o acciones potenciales que podrían dañar sus activos de información. Para las empresas SaaS, las amenazas abarcan varias categorías:

Amenazas cibernéticas:

• Ransomware y malware dirigido a la infraestructura de producción
• Ataques de relleno de credenciales contra la autenticación de clientes
• Compromiso de la cadena de suministro a través de bibliotecas de terceros o herramientas de compilación
• Ataques DDoS que interrumpen la disponibilidad del servicio
• Abuso de API — scraping, inyección, evasión de límites de tasa
• Explotación de zero-day de vulnerabilidades de framework o sistema operativo
• Phishing dirigido a empleados con acceso a sistemas de producción

Amenazas internas:

• Exfiltración maliciosa de datos por empleados o contratistas
• Configuración negligente de recursos cloud (buckets S3 públicos, grupos de seguridad abiertos)
• Shadow IT — empleados que utilizan herramientas no autorizadas que procesan datos de la empresa o de clientes
• Abuso de privilegios — empleados que acceden a datos más allá de los requisitos de su puesto

Amenazas ambientales y operacionales:

• Interrupciones del proveedor cloud que afectan la disponibilidad
• Fallos de centros de datos (incluso en la nube, ocurren interrupciones regionales)
• Agotamiento de capacidad durante picos de tráfico
• Fallos de despliegue que introducen errores o regresiones de seguridad

Amenazas de terceros:

• Brechas de seguridad en proveedores SaaS que procesan sus datos
• Discontinuación del servicio del proveedor que fuerza una migración de emergencia
• Fallos de cumplimiento por sub-procesadores que afectan sus obligaciones regulatorias

Identificación de Vulnerabilidades

Las vulnerabilidades son debilidades que las amenazas pueden explotar. Existen en la tecnología, los procesos y las personas:

Vulnerabilidades técnicas:

• Software y sistemas operativos sin parches
• Configuraciones predeterminadas inseguras
• Falta de cifrado para datos en reposo o en tránsito
• Registro y monitoreo inadecuados
• Mecanismos de autenticación débiles (factor único, credenciales compartidas)
• Segmentación de red insuficiente entre inquilinos o entornos

Vulnerabilidades de procesos:

• Sin proceso formal de gestión de cambios
• Falta de requisitos de revisión de código para despliegues a producción
• Procedimientos de restauración de respaldo faltantes o no probados
• Procesos inadecuados de evaluación de seguridad de proveedores
• Sin playbooks de respuesta a incidentes

Vulnerabilidades humanas:

• Capacitación insuficiente en concientización de seguridad
• Dependencia de personas clave (un ingeniero que sabe cómo funciona el sistema)
• Verificaciones de antecedentes inadecuadas para empleados con acceso sensible
• Mala higiene de contraseñas a pesar de los requisitos de la política

Mapeo de Amenazas a Vulnerabilidades

El riesgo existe en la intersección de una amenaza y una vulnerabilidad. Una amenaza sin una vulnerabilidad correspondiente es teórica. Una vulnerabilidad sin una amenaza correspondiente es una debilidad pero no un riesgo activo. Su registro de riesgos debe documentar las combinaciones específicas de amenaza-vulnerabilidad que producen riesgo para sus activos.

Ejemplo:

• Activo: Base de datos PostgreSQL de producción que contiene datos de clientes
• Amenaza: Ataque de inyección SQL a través de API pública
• Vulnerabilidad: Validación de entrada no implementada consistentemente en todos los endpoints de API
• Riesgo: Acceso no autorizado a datos de clientes a través de inyección SQL, llevando a una brecha de datos, notificación regulatoria y daño reputacional

Puntuación de Probabilidad e Impacto

Aquí es donde su evaluación de riesgos se transforma de una lista de preocupaciones a una herramienta priorizada de toma de decisiones.

Definición de su Escala de Probabilidad

Use definiciones descriptivas que su equipo pueda aplicar consistentemente. Etiquetas vagas como “Bajo” y “Medio” sin definiciones llevan a una puntuación inconsistente.

Calificación	Etiqueta	Definición
1	Raro	Podría ocurrir solo en circunstancias excepcionales. No se conocen incidentes en organizaciones similares.
2	Improbable	Podría ocurrir pero no se espera. Incidentes aislados conocidos en la industria.
3	Posible	Podría ocurrir en algún momento. Los incidentes ocurren periódicamente en organizaciones similares.
4	Probable	Probablemente ocurrirá en la mayoría de las circunstancias. Incidentes regulares en la industria.
5	Casi Seguro	Se espera que ocurra frecuentemente. Ocurrencia continua o casi continua en la industria.

Definición de su Escala de Impacto

El impacto debe considerar múltiples dimensiones relevantes para su negocio SaaS:

Calificación	Etiqueta	Financiero	Operacional	Reputacional	Regulatorio
1	Insignificante	< $10K	Sin interrupción del servicio	Sin conocimiento externo	Sin interés regulatorio
2	Menor	$10K - $50K	Interrupción breve, < 1 hora	Quejas limitadas de clientes	Consulta regulatoria informal
3	Moderado	$50K - $250K	Interrupción de 1-8 horas	Cobertura en medios de la industria	Investigación formal
4	Significativo	$250K - $1M	Interrupción extendida de 8-48 horas	Cobertura en medios generales	Acción de cumplimiento, multas
5	Severo	> $1M	Interrupción prolongada > 48 horas	Cobertura negativa sostenida	Multas mayores, remediación obligatoria

La Matriz de Riesgos

Multiplique la probabilidad por el impacto para producir una puntuación de riesgo. Una matriz 5x5 produce puntuaciones de 1 a 25:

	Insignificante (1)	Menor (2)	Moderado (3)	Significativo (4)	Severo (5)
Casi Seguro (5)	5	10	15	20	25
Probable (4)	4	8	12	16	20
Posible (3)	3	6	9	12	15
Improbable (2)	2	4	6	8	10
Raro (1)	1	2	3	4	5

Bandas de Calificación de Riesgo

Defina qué significan las puntuaciones para las decisiones de tratamiento:

• Crítico (20-25): Acción inmediata requerida. El riesgo debe ser tratado antes de la próxima revisión de la dirección.
• Alto (12-19): Plan de tratamiento requerido en 30 días. El propietario del riesgo debe presentar opciones a la dirección.
• Medio (6-11): Plan de tratamiento requerido en 90 días. Monitoreado en revisiones regulares de riesgos.
• Bajo (1-5): Aceptar o tratar basándose en análisis de costo-beneficio. Revisado durante la evaluación anual.

Apetito de Riesgo y Criterios de Aceptación

El apetito de riesgo es la cantidad y tipo de riesgo que su organización está dispuesta a asumir en la búsqueda de sus objetivos. Es definido por la alta dirección y documentado en su política de gestión de riesgos.

Establecimiento del Apetito de Riesgo

Su declaración de apetito de riesgo debe ser lo suficientemente específica para guiar las decisiones de tratamiento. “Tenemos un bajo apetito de riesgo” es demasiado vago. En su lugar:

• “No aceptamos ningún riesgo residual calificado como Crítico o Alto para riesgos que afecten la confidencialidad de los datos de clientes.”
• “Aceptamos riesgo residual Medio para riesgos de disponibilidad operativa cuando el costo de mitigación adicional excede tres veces la expectativa de pérdida anualizada.”
• “No aceptamos ningún riesgo que resulte en incumplimiento regulatorio con GDPR u otras regulaciones de protección de datos aplicables a nuestra base de clientes.”

Aceptación Formal de Riesgos

Cuando un riesgo cae dentro de sus criterios de aceptación — o cuando la dirección toma una decisión deliberada de aceptar un riesgo por encima del umbral normal — esa decisión debe ser documentada:

• Descripción del riesgo y puntuación actual
• Justificación para la aceptación (análisis de costo-beneficio, bajo riesgo residual después de controles existentes, decisión estratégica)
• Aprobador — un individuo identificado con autoridad para aceptar el riesgo (típicamente CISO, CTO o presidente del comité de riesgos)
• Fecha de revisión — cuándo se reevaluará la aceptación
• Condiciones — cualquier condición que invalidaría la aceptación (por ejemplo, “aceptado hasta que la base de clientes supere los 1,000 inquilinos”)

Los auditores verificarán que las decisiones de aceptación de riesgos sean tomadas por individuos autorizados, documentadas con justificación y revisadas periódicamente. La aceptación de riesgos sin documentar es un hallazgo común de no conformidad.

Planificación del Tratamiento de Riesgos

Una vez que los riesgos son evaluados y comparados contra sus criterios de aceptación, cada riesgo por encima del umbral requiere un plan de tratamiento. ISO 27001 define cuatro opciones de tratamiento.

Opción 1: Mitigar (Reducir)

Implementar controles para reducir la probabilidad o el impacto del riesgo. Este es el tratamiento más común y crea la conexión directa entre su evaluación de riesgos y sus controles del Annex A.

Ejemplo: Riesgo de acceso no autorizado a bases de datos de producción (puntuación: 16, Alto).

• Controles: Implementar autenticación multifactor para todo acceso a producción (A.8.5), aplicar control de acceso basado en roles con mínimo privilegio (A.5.15), habilitar registro de actividad de base de datos con alertas (A.8.15), realizar revisiones trimestrales de acceso (A.5.18).
• Riesgo residual esperado: 6 (Medio) — probabilidad reducida de Probable a Improbable a través de controles de acceso; impacto sin cambios.

Opción 2: Transferir (Compartir)

Trasladar parte del riesgo a un tercero. Los mecanismos comunes incluyen seguros de responsabilidad cibernética y acuerdos contractuales con proveedores.

Ejemplo: Riesgo de pérdida financiera por una brecha de datos (puntuación: 15, Alto).

• Tratamiento: Adquirir seguro de responsabilidad cibernética que cubra costos de respuesta a brechas, multas regulatorias (donde sean asegurables) e interrupción del negocio. Negociar contratos con proveedores que incluyan provisiones de responsabilidad por brechas causadas por negligencia del proveedor.
• Nota: La transferencia reduce la exposición financiera pero no elimina el riesgo. Aún necesita controles de detección y respuesta.

Opción 3: Evitar (Terminar)

Eliminar el riesgo eliminando la actividad, proceso o sistema que lo crea.

Ejemplo: Riesgo de exposición de datos a través de una API legacy que usa autenticación básica (puntuación: 12, Alto).

• Tratamiento: Descomisionar la API legacy y migrar a todos los consumidores a la API actual que soporta OAuth 2.0 y limitación de tasa. El riesgo se elimina porque el componente vulnerable ya no existe.

Opción 4: Aceptar (Retener)

Reconocer el riesgo y elegir no tomar acciones adicionales. Válido cuando el riesgo está dentro de su apetito de riesgo o cuando el costo del tratamiento excede significativamente el impacto potencial.

Ejemplo: Riesgo de breve interrupción del servicio por ventanas de mantenimiento del proveedor cloud (puntuación: 4, Bajo).

• Tratamiento: Aceptar. El mantenimiento programado del proveedor cloud ocurre en ventanas de bajo tráfico y típicamente causa menos de 5 minutos de rendimiento degradado. El costo de implementar una arquitectura multi-región activo-activo para eliminar este riesgo es desproporcionado al impacto.

El Documento del Plan de Tratamiento de Riesgos

Su plan de tratamiento de riesgos debe documentar para cada riesgo tratado:

• Referencia del riesgo — vinculando al registro de riesgos
• Opción de tratamiento seleccionada — mitigar, transferir, evitar o aceptar
• Acciones específicas — qué se hará
• Referencias a controles del Annex A — qué controles implementan el tratamiento (para mitigación)
• Propietario — quién es responsable de implementar el tratamiento
• Fecha objetivo — cuándo se implementará completamente el tratamiento
• Recursos requeridos — presupuesto, personal, herramientas
• Riesgo residual esperado — el nivel de riesgo anticipado después del tratamiento

Este documento es una entrada obligatoria para su Declaración de Aplicabilidad, que mapea cada control del Annex A a los riesgos que aborda.

Vinculación de Riesgos con Controles del Annex A

La conexión entre la evaluación de riesgos y los controles del Annex A es lo que da coherencia a su ISMS. Cada control que implemente debe rastrearse a uno o más riesgos identificados. Cada riesgo significativo debe ser abordado por uno o más controles (o formalmente aceptado).

Cómo Funciona el Mapeo

1. Comience con el plan de tratamiento de riesgos. Para cada riesgo que está mitigando, identifique las acciones de control específicas que tomará.
2. Mapee las acciones a controles del Annex A. Cada acción de control corresponde a uno o más de los 93 controles del Annex A. Por ejemplo, “implementar autenticación multifactor” se mapea a A.8.5 (Autenticación segura).
3. Documente el mapeo en su Declaración de Aplicabilidad. El SoA muestra cada control del Annex A, si está incluido o excluido, y la justificación de riesgo para esa decisión.
4. Incluya controles no impulsados por la evaluación de riesgos. Algunos controles del Annex A abordan requisitos legales, regulatorios o contractuales en lugar de riesgos específicos. Estos aún se incluyen en el SoA con la justificación apropiada.

Mapeos Comunes para Empresas SaaS

Riesgo	Controles del Annex A
Acceso no autorizado a datos de clientes	A.5.15 (Control de acceso), A.5.16 (Gestión de identidad), A.8.5 (Autenticación segura), A.8.3 (Restricción de acceso a la información)
Ataque a la cadena de suministro a través de código de terceros	A.5.19-A.5.22 (Controles de relación con proveedores), A.8.25 (Ciclo de vida de desarrollo seguro), A.8.28 (Codificación segura)
Brecha de datos por recursos cloud mal configurados	A.8.9 (Gestión de configuración), A.8.8 (Gestión de vulnerabilidades técnicas), A.8.15 (Registro)
Ransomware que interrumpe operaciones	A.8.7 (Protección contra malware), A.8.13 (Respaldo de información), A.5.24 (Planificación de gestión de incidentes)
Partida de persona clave	A.5.2 (Roles de seguridad de la información), A.5.4 (Responsabilidades de la dirección), A.6.5 (Responsabilidades después de la terminación)
Incumplimiento de GDPR	A.5.34 (Privacidad y protección de PII), A.5.31 (Requisitos legales, estatutarios, regulatorios)

Mantenimiento del Registro de Riesgos

Su registro de riesgos no es un entregable de una sola vez. Es un documento vivo que refleja su panorama actual de amenazas, entorno de control y contexto empresarial.

Campos Requeridos

Cada entrada de riesgo debe capturar:

• ID de Riesgo — Identificador único (por ejemplo, RISK-2026-001)
• Título del riesgo — Nombre conciso para referencia
• Descripción del riesgo — Descripción detallada de la amenaza, vulnerabilidad e impacto potencial
• Activo(s) afectado(s) — Qué activos de información están en riesgo
• Fuente de amenaza — Atacante externo, interno, ambiental, proveedor
• Vulnerabilidad — La debilidad que la amenaza explota
• Probabilidad inherente — Puntuación antes de controles
• Impacto inherente — Puntuación antes de controles
• Puntuación de riesgo inherente — Probabilidad x Impacto
• Controles existentes — Controles actualmente en vigor
• Probabilidad residual — Puntuación después de controles
• Impacto residual — Puntuación después de controles
• Puntuación de riesgo residual — Probabilidad x Impacto después de controles
• Decisión de tratamiento — Mitigar, transferir, evitar, aceptar
• Referencia del plan de tratamiento — Enlace al plan de tratamiento
• Propietario del riesgo — Individuo identificado responsable
• Fecha de revisión — Cuándo se revisó por última vez el riesgo
• Estado — Abierto, en tratamiento, aceptado, cerrado

Cadencia de Revisión

• Continua — Actualice el registro cuando ocurran eventos significativos (incidentes de seguridad, nuevas vulnerabilidades, brechas de proveedores, cambios arquitectónicos, incorporación de proveedores)
• Trimestral — Revisión formal de los principales riesgos, progreso del tratamiento y amenazas emergentes
• Anual — Reevaluación completa de todos los riesgos como parte de la revisión de la dirección del ISMS
• Activada — Reevaluación cuando ocurran cambios significativos (lanzamiento de nuevo producto, fusiones y adquisiciones, migración de infraestructura, nuevas regulaciones)

Conexión con la Auditoría Interna

Su programa de auditoría interna debe verificar que el proceso de evaluación de riesgos esté operando según lo documentado. Los auditores verificarán:

• ¿Se siguió la metodología consistentemente?
• ¿Se capturaron en el registro los nuevos riesgos identificados durante el período?
• ¿Se implementaron los planes de tratamiento según lo programado?
• ¿Se autorizaron adecuadamente las decisiones de aceptación de riesgos?
• ¿Refleja el registro los cambios que ocurrieron durante el período?

Ejemplos de Riesgos Específicos de SaaS

Estos ejemplos ilustran cómo se documentan los riesgos reales de SaaS en un registro de riesgos. No son una plantilla para copiar — sus riesgos deben reflejar su arquitectura, datos y contexto empresarial específicos.

Ejemplo 1: Fallo en el Aislamiento de Datos Multitenant

ID de Riesgo: RISK-2026-012 Descripción: Un defecto de software en la capa de aislamiento de inquilinos permite que un cliente acceda a los datos de otro cliente. Esto podría resultar de un filtro de ID de inquilino faltante en una consulta de base de datos, un error de caché que sirve los datos de otro inquilino, o una condición de carrera en la gestión de sesiones. Activo: Datos de clientes, aplicación de producción Probabilidad inherente: 3 (Posible) — el aislamiento de inquilinos es complejo; incidentes similares han ocurrido en proveedores SaaS importantes Impacto inherente: 5 (Severo) — brecha de datos que afecta a múltiples clientes, notificación obligatoria, daño reputacional severo Puntuación de riesgo inherente: 15 (Alto) Controles existentes: Aplicación de ID de inquilino en la capa ORM, pruebas de integración para aislamiento de inquilinos, requisitos de revisión de código para código de acceso a datos Probabilidad residual: 2 (Improbable) Impacto residual: 5 (Severo) — el impacto no cambia; solo se reduce la probabilidad Puntuación de riesgo residual: 10 (Medio) Tratamiento: Mitigar — implementar seguridad a nivel de fila en la base de datos como mecanismo secundario de aislamiento, agregar pruebas automatizadas de aislamiento de inquilinos al pipeline CI/CD, desplegar monitoreo en tiempo de ejecución para patrones de acceso a datos entre inquilinos Controles: A.8.25 (Ciclo de vida de desarrollo seguro), A.8.28 (Codificación segura), A.8.29 (Pruebas de seguridad), A.8.16 (Actividades de monitoreo)

Ejemplo 2: Pipeline CI/CD Comprometido

ID de Riesgo: RISK-2026-018 Descripción: Un atacante obtiene acceso al pipeline CI/CD (GitHub Actions, Jenkins o similar) e inyecta código malicioso en un despliegue a producción. Los vectores de ataque incluyen tokens de GitHub comprometidos, pull requests maliciosos de repositorios bifurcados, o ataques a la cadena de suministro a través de GitHub Actions comprometidas usadas en flujos de trabajo. Activo: Código fuente, infraestructura de producción, datos de clientes Probabilidad inherente: 3 (Posible) — los ataques a la cadena de suministro están aumentando en frecuencia Impacto inherente: 5 (Severo) — el atacante logra ejecución de código en producción con acceso a todos los datos de clientes Puntuación de riesgo inherente: 15 (Alto) Controles existentes: Revisión de código requerida para todos los PRs, protección de rama en la rama principal, escaneo de secretos en CI Probabilidad residual: 2 (Improbable) Impacto residual: 5 (Severo) Puntuación de riesgo residual: 10 (Medio) Tratamiento: Mitigar — implementar commits firmados, fijar todos los GitHub Actions a hashes SHA específicos, desplegar procedencia de compilación SLSA Nivel 2, restringir acceso a runners auto-alojados, implementar verificación de integridad de artefactos de compilación Controles: A.8.25 (Ciclo de vida de desarrollo seguro), A.8.9 (Gestión de configuración), A.5.19 (Seguridad de la información en relaciones con proveedores), A.8.15 (Registro)

Ejemplo 3: Brecha en Proveedor SaaS de Terceros

ID de Riesgo: RISK-2026-024 Descripción: Un proveedor SaaS que procesa o almacena datos de la empresa o de clientes sufre una brecha de seguridad, exponiendo los datos que se le confiaron. Los proveedores afectados podrían incluir proveedores de identidad, plataformas de analítica, herramientas de soporte al cliente o procesadores de pagos. Activo: Datos de clientes, datos de empleados, datos comerciales Probabilidad inherente: 4 (Probable) — las brechas de proveedores son frecuentes en toda la industria Impacto inherente: 4 (Significativo) — dependiendo del proveedor, podría exponer PII de clientes, requerir notificación de brecha y causar daño reputacional Puntuación de riesgo inherente: 16 (Alto) Controles existentes: Evaluación de seguridad del proveedor durante la incorporación, cláusulas contractuales de protección de datos, revisión anual de proveedores Probabilidad residual: 3 (Posible) — no se puede controlar completamente la postura de seguridad del proveedor Impacto residual: 3 (Moderado) — impacto reducido a través de minimización de datos y cifrado Puntuación de riesgo residual: 9 (Medio) Tratamiento: Mitigar — implementar monitoreo continuo de proveedores, requerir certificación SOC 2 Tipo II o ISO 27001 de proveedores críticos, minimizar los datos compartidos con proveedores a lo operacionalmente necesario, cifrar datos sensibles antes de transmitirlos a proveedores, mantener playbooks de respuesta a incidentes de proveedores Controles: A.5.19-A.5.22 (Controles de gestión de proveedores), A.5.31 (Requisitos legales), A.8.11 (Enmascaramiento de datos)

Ejemplo 4: Error de Configuración en Infraestructura Cloud

ID de Riesgo: RISK-2026-031 Descripción: Un error de configuración en la infraestructura cloud (AWS, GCP, Azure) expone recursos a la internet pública. Los ejemplos incluyen buckets S3 accesibles públicamente, grupos de seguridad que permiten acceso entrante sin restricciones, instancias de base de datos sin cifrar con endpoints públicos, o roles IAM excesivamente permisivos. Activo: Infraestructura de producción, datos de clientes, datos de aplicación Probabilidad inherente: 4 (Probable) — los errores de configuración son la causa más común de incidentes de seguridad en la nube Impacto inherente: 4 (Significativo) — podría exponer datos de clientes, proporcionar movimiento lateral para atacantes o permitir abuso de recursos Puntuación de riesgo inherente: 16 (Alto) Controles existentes: Infraestructura como código con revisión de PR, reglas de AWS Config para errores de configuración comunes Probabilidad residual: 2 (Improbable) — IaC y verificaciones automatizadas reducen significativamente la probabilidad Impacto residual: 4 (Significativo) — impacto sin cambios si ocurre el error de configuración Puntuación de riesgo residual: 8 (Medio) Tratamiento: Mitigar — implementar herramienta de Gestión de Postura de Seguridad en la Nube (CSPM), aplicar infraestructura como código para todos los cambios de recursos cloud (sin cambios manuales por consola), desplegar SCPs de AWS para prevenir la creación de recursos públicos, realizar auditorías trimestrales de configuración cloud Controles: A.8.9 (Gestión de configuración), A.8.8 (Gestión de vulnerabilidades técnicas), A.8.15 (Registro), A.8.23 (Filtrado web)

Ejemplo 5: Exfiltración de Datos por Insider

ID de Riesgo: RISK-2026-037 Descripción: Un empleado o contratista con acceso privilegiado a sistemas de producción exfiltra intencionalmente datos de clientes para beneficio personal, ventaja competitiva o intención maliciosa. Esto incluye exportaciones de base de datos, extracción de datos por API o copia de datos a almacenamiento personal. Activo: Datos de clientes, propiedad intelectual Probabilidad inherente: 2 (Improbable) — los ataques internos son menos frecuentes que los ataques externos pero sí ocurren Impacto inherente: 5 (Severo) — brecha de datos, obligaciones de notificación regulatoria, responsabilidad legal, daño reputacional severo Puntuación de riesgo inherente: 10 (Medio) Controles existentes: Control de acceso basado en roles, verificaciones de antecedentes para empleados con acceso a producción, acuerdos de NDA Probabilidad residual: 1 (Raro) — los controles reducen pero no pueden eliminar el riesgo interno Impacto residual: 5 (Severo) Puntuación de riesgo residual: 5 (Bajo) Tratamiento: Mitigar — implementar monitoreo de actividad de base de datos con alertas para exportaciones masivas de datos, desplegar controles DLP en endpoints y correo electrónico, aplicar acceso justo a tiempo para bases de datos de producción, realizar revisiones trimestrales de acceso para asegurar mínimo privilegio, registrar y monitorear todo acceso a producción Controles: A.5.15 (Control de acceso), A.6.1 (Verificación), A.6.2 (Términos y condiciones de empleo), A.8.15 (Registro), A.8.16 (Actividades de monitoreo), A.8.12 (Prevención de fuga de datos)

Integración de la Evaluación de Riesgos con el Ciclo de Vida del ISMS

La evaluación de riesgos no es un ejercicio aislado. Se conecta con cada otro componente de su ISMS.

Conexión con la Declaración de Aplicabilidad

Su plan de tratamiento de riesgos es la entrada principal a la Declaración de Aplicabilidad. El SoA lista los 93 controles del Annex A e indica si cada uno está incluido o excluido, con justificación. Para los controles incluidos, la justificación se remonta al/los riesgo(s) que el control aborda. Para los controles excluidos, la justificación explica por qué el riesgo no aplica.

Conexión con Políticas y Procedimientos

Sus políticas del ISMS deben referenciar la evaluación de riesgos como base para los requisitos de control. Por ejemplo, su política de control de acceso no solo declara “se requiere autenticación multifactor” — declara que se requiere MFA porque la evaluación de riesgos identificó el acceso no autorizado como un riesgo Alto para la confidencialidad de los datos de clientes.

Conexión con el Proceso de Certificación

Durante su auditoría de certificación ISO 27001, el auditor examinará su metodología de evaluación de riesgos, registro de riesgos, plan de tratamiento y la conexión entre riesgos y controles. Los hallazgos comunes de auditoría relacionados con la evaluación de riesgos incluyen:

• Metodología de evaluación de riesgos no documentada o no seguida
• Registro de riesgos no actualizado para reflejar cambios durante el período de auditoría
• Planes de tratamiento sin evidencia de implementación
• Controles del Annex A incluidos en el SoA sin justificación de riesgo correspondiente
• Decisiones de aceptación de riesgos sin aprobación de la dirección
• Sin evidencia de revisión periódica de riesgos

Conexión con GDPR y Protección de Datos

Si su empresa SaaS procesa datos personales sujetos a GDPR, su evaluación de riesgos ISO 27001 respalda — pero no reemplaza — las Evaluaciones de Impacto en la Protección de Datos (DPIAs). Los dos procesos son complementarios: su evaluación de riesgos del ISMS cubre los riesgos de seguridad de la información de manera amplia, mientras que las DPIAs se enfocan específicamente en los riesgos a los derechos y libertades de los interesados derivados de actividades de procesamiento específicas.

Errores Comunes en la Evaluación de Riesgos ISO 27001

Tratarla como un ejercicio de una sola vez. La evaluación de riesgos realizada una vez durante la certificación y olvidada hasta la auditoría de vigilancia es un ejercicio de cumplimiento, no una práctica de seguridad. Su panorama de amenazas cambia continuamente. Se descubren nuevas vulnerabilidades, se incorporan nuevos proveedores, la infraestructura evoluciona y las técnicas de los atacantes avanzan. Su evaluación de riesgos debe mantener el ritmo.

Usar plantillas genéricas sin personalización. Un registro de riesgos que lista “incendio en el centro de datos” para una empresa SaaS 100% nativa en la nube no refleja la realidad. Sus riesgos deben ser específicos a su arquitectura, pila tecnológica, base de clientes y modelo de negocio. Las plantillas genéricas son un punto de partida para la estructura, no para el contenido.

No involucrar a las personas adecuadas. Los ingenieros saben dónde está la deuda técnica. Los gerentes de producto saben qué funcionalidades manejan los datos más sensibles. Los equipos de éxito del cliente saben qué compromisos de disponibilidad se han hecho. Los equipos de seguridad por sí solos no pueden identificar todos los riesgos relevantes. Los talleres multifuncionales producen registros de riesgos más completos.

Puntuar todo como Medio. Si cada riesgo en su registro puntúa entre 6 y 12, sus criterios de puntuación no están discriminando efectivamente. Revise sus definiciones de probabilidad e impacto para asegurar que produzcan una diferenciación significativa. Un registro de riesgos bien calibrado debe tener riesgos distribuidos a lo largo del rango de puntuación.

Desconectar la evaluación de riesgos de las decisiones de control. Si su registro de riesgos y su implementación de controles viven en documentos separados sin referencias cruzadas, los auditores identificarán la brecha inmediatamente. Cada control debe rastrearse a un riesgo. Cada riesgo significativo debe rastrearse a un control o una decisión de aceptación.

No documentar la metodología. “Hicimos una lluvia de ideas sobre riesgos y los escribimos” no es una metodología. Documente sus criterios de puntuación, su proceso de evaluación, su cadencia de revisión y los roles involucrados. El documento de metodología es en sí mismo un artefacto auditable.

Cómo Ayuda GRCTrail

GRCTrail proporciona a las empresas SaaS las herramientas y la estructura para ejecutar un proceso de evaluación de riesgos ISO 27001 que satisface a los auditores y produce perspectivas de seguridad genuinas.

• Flujo de trabajo guiado de evaluación de riesgos que acompaña a su equipo a través de los requisitos de la Cláusula 6.1.2 — desde la definición de la metodología hasta la finalización del registro de riesgos — asegurando que cada paso cumpla con la norma sin necesidad de un consultor externo para interpretar las cláusulas
• Biblioteca de riesgos SaaS precargada con escenarios de amenazas específicos para empresas SaaS nativas en la nube, cubriendo aislamiento multitenant, seguridad de pipelines CI/CD, errores de configuración cloud, riesgos de cadena de suministro y dependencias de proveedores para que comience desde amenazas relevantes en lugar de plantillas en blanco
• Mapeo automático de controles del Annex A que vincula los riesgos identificados con los 93 controles del Annex A y alimenta directamente su Declaración de Aplicabilidad, manteniendo la trazabilidad desde la amenaza hasta el tratamiento y el control

Comience con GRCTrail →

Guías Relacionadas

• ¿Qué es ISO 27001? Una Guía para Empresas SaaS
• Requisitos de ISO 27001: Comprendiendo las Cláusulas 4-10
• Controles del Annex A de ISO 27001: Guía Completa de los 93 Controles
• Declaración de Aplicabilidad ISO 27001: Cómo Crearla
• Guía de Gestión de Proveedores ISO 27001
• Lista de Verificación de Certificación ISO 27001
• Guía de Evaluación de Riesgos SOC 2
• Guía de DPIA GDPR