Una evaluación de riesgos para ISO 27001, SOC 2 e HIPAA
ISO 27001, SOC 2 e HIPAA parten todas de una evaluación de riesgos. Solo necesita una, si está diseñada para responder a los tres auditores.
Esta entrada cubre los 11 marcos que ControlMapping había asignado cuando se redactó. Desde entonces, se añadieron DORA, CPS 234, Cyber Essentials el 2026-10-27; sus páginas y la matriz de cobertura ya los incluyen.
La evaluación de riesgos es el punto de partida de tres de los marcos más habituales. ISO 27001 construye todo sobre ella (cláusula 6.1.2). SOC 2 dedica una sección de sus criterios comunes a este tema (CC3.1 a CC3.4). La Regla de Seguridad de HIPAA convierte el análisis de riesgos en su primera especificación de implementación requerida (§164.308(a)(1)(ii)(A)), y es el primer documento que solicitan los investigadores de HHS. Muchas organizaciones realizan tres. Con una basta.
Qué revisa cada marco
- ISO 27001 exige un método definido y repetible, con criterios de aceptación; riesgos identificados para la confidencialidad, integridad y disponibilidad; propietarios; análisis de probabilidad y consecuencias; y un vínculo con el tratamiento de riesgos y la Declaración de Aplicabilidad.
- SOC 2 exige objetivos especificados con suficiente claridad para identificar riesgos (CC3.1), riesgos identificados y analizados en toda la entidad (CC3.2), riesgo de fraude considerado (CC3.3) y cambios evaluados (CC3.4).
- HIPAA exige una evaluación precisa y exhaustiva de los riesgos y vulnerabilidades para la ePHI, dondequiera que se cree, reciba, mantenga o transmita, que se mantenga actualizada y que vaya seguida de una gestión de riesgos (§164.308(a)(1)(ii)(B)).
En nuestros datos, estos requisitos se vinculan directamente:
| Marco | Evaluación de riesgos | Vínculo |
|---|---|---|
| NIST CSF 2.0 | ID.RA-03ID.RA-04ID.RA-05ID.RA-06 | Definición del tema |
| ISO 27001 | Clause 6.1.2Clause 6.1.3 | Correspondencia |
| CIS v8.1 | — | Sin correspondencia en nuestros datos |
| SOC 2 | CC3.2CC3.4CC3.3 | Editorial |
| PCI DSS | 12.3.1 | Correspondencia |
| CMMC | RA.L2-3.11.1 | Correspondencia |
| 800-53 | RA-3RA-7 | Correspondencia |
| HIPAA | §164.308(a)(1)(ii)(A) | Correspondencia |
| GDPR | Art.35(1)Art.35(7) | Editorial |
| NIS2 | 2.1 | Correspondencia |
| Essential Eight | — | Sin correspondencia en nuestros datos |
Detalle completo y motivo de cada vínculo: Evaluación de riesgos en todos los marcos →
Diseñar una evaluación para los tres
- Definir un alcance que lo abarque todo: el alcance del SGSI, el sistema SOC 2 y cada ubicación de la ePHI. Registre qué activos corresponden a qué marco.
- Usar un único método: basado en activos o escenarios, con una escala de probabilidad e impacto, criterios de aceptación y propietarios. Los requisitos de ISO para un método documentado y repetible son los más estrictos, así que cúmplalos.
- Añadir las preguntas específicas de cada marco: riesgo de fraude (SOC 2 CC3.3), amenazas y vulnerabilidades específicas de la ePHI (HIPAA), y riesgos legales y contractuales.
- Vincular cada riesgo con su tratamiento: controles elegidos, riesgo residual, aceptación por parte del propietario. Esa única tabla alimenta la Declaración de Aplicabilidad de ISO, las actividades de control de SOC 2 y la gestión de riesgos de HIPAA.
Resultados que satisfacen a los tres auditores
- El método, aprobado.
- Un registro de riesgos con propietarios, puntuaciones y decisiones de tratamiento.
- Un plan de tratamiento de riesgos con fechas.
- La aceptación del riesgo residual por parte de los propietarios.
- Evidencia de revisión al menos anual y tras cambios significativos.
Formato sencillo de registro de riesgos
Una fila por riesgo sirve para los tres marcos:
| Campo | Ejemplo |
|---|---|
| Riesgo | El ransomware cifra la base de datos de producción |
| Activos | Base de datos de producción, copias de seguridad, almacén de ePHI |
| Marcos | ISO 27001, SOC 2, HIPAA |
| Probabilidad e impacto | Posible, grave |
| Controles existentes | MFA, EDR, copias de seguridad nocturnas |
| Tratamiento | Aislar las copias de seguridad; probar restauraciones trimestralmente |
| Propietario | Responsable de infraestructura |
| Riesgo residual y aceptación | Medio, aceptado por el CTO |
| Fecha de revisión | Próximo trimestre |
La columna de marcos es el truco: permite que un solo registro responda a tres auditores sin tres hojas de cálculo.
Puntos clave
- Un método y un registro pueden satisfacer ISO 27001, SOC 2 y HIPAA.
- Añada las preguntas específicas de cada marco: riesgo de fraude y ubicaciones de la ePHI.
- Revísela al menos anualmente y tras cambios significativos.
Hallazgos habituales
- Riesgos genéricos ("hackers", "filtración de datos") sin vínculo con activos o controles específicos.
- Sin propietarios, o con el equipo de seguridad como propietario de todos los riesgos.
- Ubicaciones de la ePHI pasadas por alto: exportaciones, copias de seguridad, correo electrónico, sistemas de prueba.
- Desactualizada: evaluada una vez para la primera auditoría y nunca más.
Para más información sobre cómo se relacionan estos marcos, consulte la comparativa ISO 27001 vs HIPAA y el tema Evaluación de riesgos. El análisis de brechas muestra cada correspondencia entre dos marcos cualesquiera.
Preguntas
¿Es el análisis de riesgos de HIPAA lo mismo que una evaluación de riesgos de ISO 27001?
Se solapan considerablemente. HIPAA exige una evaluación precisa y exhaustiva de los riesgos para la confidencialidad, integridad y disponibilidad de la ePHI; una evaluación de riesgos de ISO 27001 que incluya la ePHI en el alcance y registre los elementos específicos de HIPAA puede servir para ambos.
¿Con qué frecuencia debe realizarse una evaluación de riesgos?
ISO 27001 exige evaluaciones de riesgos a intervalos planificados y tras cambios significativos. Los auditores de SOC 2 suelen esperar una evaluación de riesgos al menos una vez al año. HIPAA exige que el análisis de riesgos se mantenga actualizado.
¿Debe la evaluación de riesgos ser cualitativa o cuantitativa?
Cualquiera de las dos opciones funciona para los tres marcos, siempre que el método esté definido, se aplique de forma coherente y produzca resultados comparables. La mayoría de las organizaciones empiezan con un enfoque cualitativo y añaden números donde las decisiones los necesitan.
Datos a fecha de 2026-10-27: las cifras de esta entrada se calculan a partir de la correspondencia vigente y se actualizan cuando esta cambia. Correspondencia una tabla de correspondencias publicada (NIST, ENISA, CIS, PCI SSC) establece la relación · Editorial Criterio editorial de ControlMapping cuando no existe crosswalk; se muestra el motivo · solo comparte un resultado de CSF 2.0: conviene revisarlo, no es una asignación · Sin correspondencia en nuestros datos no hay nada asignado en nuestros datos; a menudo es trabajo nuevo, pero revisa las notas de cobertura. No es asesoramiento de cumplimiento.
Artículos relacionados
Análisis · 2026-10-27APRA CPS 234 y ISO 27001: qué cubre su SGSI y qué añade APRAUn SGSI conforme a ISO 27001 cubre casi todos los párrafos de la CPS 234 de APRA, pero APRA añade obligaciones del consejo de administración, garantías de terceros y plazos estrictos de notificación.
Análisis · 2026-10-13Requisitos de MFA comparados en 11 marcos de seguridadQué marcos exigen MFA, a quién y con qué rigor: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 y HIPAA, comparados en paralelo.
Análisis · 2026-09-29Regla de Seguridad de HIPAA desde la perspectiva de NIST CSF 2.0Un programa basado en NIST CSF 2.0 se corresponde con casi todos los requisitos de la Regla de Seguridad de HIPAA. Qué se traslada, los dos que no, y qué aporta CSF más allá de HIPAA.