Matriz de responsabilidad compartida en la nube para ISO, NIS2 y DORA
El director de operaciones de una fintech llama al CISO a las 07:15 de un lunes.
Un cliente bancario europeo solicita pruebas de que la plataforma SaaS de la empresa puede cumplir los requisitos de DORA sobre riesgo de terceros TIC. El equipo comercial ya ha enviado el paquete habitual de seguridad de proveedores: certificado ISO, resumen ejecutivo de pruebas de penetración, certificado de seguro de ciberriesgo, aviso de privacidad e informe de aseguramiento del proveedor de servicios en la nube.
El banco vuelve con una pregunta más precisa:
“Muéstrenos quién es responsable de cada control en su entorno en la nube. Ustedes, su proveedor de servicios en la nube, su proveedor de base de datos gestionada, su proveedor de identidad, su proveedor de registro de eventos y cualquier subencargado. Después, muéstrennos las evidencias.”
Más tarde esa misma mañana, el CISO tiene una reunión con el Consejo de Administración. El Director General formulará la misma pregunta en lenguaje de negocio: “¿Estamos seguros de que esta plataforma es segura y quién responde si algo sale mal?”
Ahí es donde muchos programas de cumplimiento en la nube se atascan.
La organización puede tener un proveedor de servicios en la nube sólido, buenas herramientas, políticas razonables y un registro de riesgos. Pero cuando se le pide demostrar los límites de responsabilidad, las evidencias están dispersas. Compras tiene los contratos. Legal tiene el contrato de encargo del tratamiento. Ingeniería tiene los diagramas de arquitectura. Seguridad tiene registros y configuraciones en la nube. Privacidad tiene la lista de subencargados. Cumplimiento tiene la Declaración de Aplicabilidad. Nadie tiene un único artefacto controlado que indique, control por control, qué hace el proveedor, qué debe configurar el cliente, qué subencargado interviene, qué cláusula hace exigible la obligación y qué evidencias debe esperar un auditor.
Ese artefacto es la matriz de responsabilidad compartida en la nube.
No la diapositiva genérica del hiperescalador que dice que el proveedor protege la nube y el cliente protege lo que está en la nube. Una matriz real de responsabilidad compartida en la nube para ISO/IEC 27001:2022, NIS2, DORA y GDPR es un registro de gobernanza. Resiste la diligencia debida de clientes, una auditoría ISO, una revisión DORA, un cuestionamiento de responsabilidad proactiva bajo GDPR y una investigación de incidentes.
Por qué la responsabilidad compartida en la nube se convierte en un problema de auditoría
El modelo de responsabilidad compartida suele explicarse como un límite técnico. En IaaS, el proveedor gestiona las instalaciones físicas, el hardware, la virtualización y la infraestructura esencial. El cliente gestiona identidades, datos, cargas de trabajo, reglas de red, decisiones de cifrado y configuraciones. En SaaS, el proveedor asume más responsabilidad operativa, pero el cliente sigue siendo responsable de los accesos de usuarios, la gobernanza de datos, la base jurídica, la configuración, las expectativas de monitorización y el escalado de incidentes.
Esa explicación es útil, pero incompleta.
Auditores, reguladores y clientes corporativos preguntan algo más que “¿quién opera el control?”. Quieren saber:
- ¿Quién asume la responsabilidad última del riesgo?
- ¿Qué cláusula contractual hace exigible esa responsabilidad?
- ¿Qué política exige el control?
- ¿Qué servicio en la nube, plataforma SaaS o subencargado está dentro del alcance?
- ¿Qué evidencias demuestran que el control operó durante el período revisado?
- ¿Qué requisito del marco satisface la evidencia?
- ¿Qué ocurre si el proveedor cambia su servicio, ubicación, subcontratista o postura de control?
ISO/IEC 27001:2022 ISO/IEC 27001:2022 convierte esto en un asunto del sistema de gestión. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda las cuestiones internas y externas, las partes interesadas, las obligaciones legales y contractuales, el alcance del SGSI, las interfaces y las dependencias. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, aprobación por el propietario del riesgo, aceptación del riesgo residual y una Declaración de Aplicabilidad. La cláusula 8.1 exige planificación y control operacional, incluido el control de procesos, productos y servicios suministrados externamente que sean pertinentes para el SGSI.
En términos sencillos, si un proveedor de servicios en la nube, proveedor SaaS o subencargado da soporte a un proceso de la organización dentro del alcance, no puede quedar fuera del SGSI. Debe ser visible en el alcance, el riesgo, el tratamiento, el control contractual y las evidencias.
NIS2 eleva el nivel de exigencia. Article 21 exige que las entidades esenciales e importantes implanten medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidas análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, adquisición segura, desarrollo seguro, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, criptografía, seguridad de los recursos humanos, control de acceso, gestión de activos y autenticación multifactor o autenticación continua cuando proceda. Article 20 sitúa la responsabilidad de gobernanza en los órganos de dirección.
DORA es aún más explícito para las entidades financieras. Se aplica desde el 17 de enero de 2025 y exige a las entidades financieras gestionar el riesgo TIC, la notificación de incidentes graves relacionados con las TIC, las pruebas de resiliencia operativa digital y el riesgo de terceros TIC. Articles 28 a 30 exigen gestión del riesgo de terceros TIC, evaluación preliminar del riesgo de concentración, salvaguardas contractuales, derechos de auditoría y acceso, visibilidad de la subcontratación, derechos de terminación y estrategias de salida.
GDPR añade la prueba de responsabilidad proactiva. Article 5 exige que los datos personales se traten con integridad y confidencialidad, y Article 5(2) exige que el responsable del tratamiento pueda demostrar el cumplimiento. Article 28 regula los contratos con encargados del tratamiento y subencargados. Article 32 exige seguridad del tratamiento. Articles 33 y 34 exigen la notificación de violaciones de datos personales cuando resulte aplicable.
La matriz de responsabilidad compartida en la nube se convierte en el puente entre estas obligaciones.
La definición de Clarysec: un artefacto de gobernanza, no un diagrama
En los proyectos de Clarysec, una matriz de responsabilidad compartida en la nube es un registro controlado del SGSI que vincula servicios en la nube, proveedores, subencargados, controles, políticas, obligaciones contractuales, evidencias y expectativas de auditoría.
La explicación más clara aparece en Zenith Blueprint Zenith Blueprint, en la fase Controles en acción, paso 23:
“Los proveedores de servicios en la nube protegen la infraestructura, pero usted sigue siendo responsable de sus datos, sus configuraciones, sus políticas de acceso y su preparación para la respuesta a incidentes.”
El mismo paso explica que el uso de la nube debe tratarse como parte del SGSI, incluida la clasificación de servicios en la nube, la comprensión de los datos tratados o almacenados, la evaluación del proveedor, las cláusulas contractuales y la gestión de cambios del servicio. Esto convierte la responsabilidad compartida, de concepto, en una estructura de control trazable.
Zenith Controls Zenith Controls trata los controles del Anexo A de ISO/IEC 27001:2022 y las orientaciones 5.20, 5.21 y 5.23 de ISO/IEC 27002:2022 como anclajes centrales:
- 5.20, tratamiento de la seguridad de la información en los acuerdos con proveedores.
- 5.21, gestión de la seguridad de la información en la cadena de suministro TIC.
- 5.23, seguridad de la información para el uso de servicios en la nube.
No son elementos aislados de una lista de verificación. Definen la columna vertebral de la matriz.
| Pregunta de la matriz | Anclaje del Anexo A de ISO/IEC 27001:2022 | Significado práctico |
|---|---|---|
| ¿A qué debe comprometerse contractualmente el proveedor? | 5.20 | La seguridad, la confidencialidad, los derechos de auditoría, la notificación de incidentes, la subcontratación y la terminación deben ser exigibles. |
| ¿Cómo controlamos al proveedor del proveedor? | 5.21 | Deben identificarse, evaluarse, monitorizarse y trasladarse contractualmente los riesgos de la cadena de suministro TIC y de las dependencias aguas abajo. |
| ¿Cómo gobernamos la selección, el uso y la salida de servicios en la nube? | 5.23 | Las responsabilidades en la nube, configuraciones, evidencias, registro de eventos, ubicación de datos y salida deben gestionarse durante todo el ciclo de vida. |
Las normas de apoyo pueden reforzar la matriz. ISO/IEC 27017 ayuda con prácticas de seguridad específicas de la nube. ISO/IEC 27018 e ISO/IEC 27701 apoyan la gobernanza de la información de identificación personal (PII) y de la privacidad. ISO/IEC 27005 apoya la evaluación de riesgos. ISO 22301 apoya la continuidad y la resiliencia. ISO/IEC 27035 apoya la gestión de incidentes. ISO/IEC 20000-1 puede ayudar cuando los servicios en la nube forman parte de la prestación de servicios gestionados.
La matriz mínima viable de responsabilidad compartida
Una matriz madura no empieza con 200 filas. Empieza con los servicios en la nube que más importan.
Para una SaaS, fintech o pyme regulada, Clarysec suele empezar por:
- Entorno en la nube de producción orientado al cliente.
- Proveedor de identidad.
- Servicio gestionado de base de datos o almacenamiento.
- Plataforma de registro, monitorización y SIEM.
- SaaS de pagos, KYC, analítica o soporte al cliente.
- Servicio de copia de seguridad y recuperación ante desastres.
- Proveedor de servicios gestionados o proveedor de servicios de seguridad gestionados.
- Subencargados que acceden, almacenan o tratan datos de clientes.
La primera matriz debe incluir las siguientes columnas.
| Columna | Por qué importa |
|---|---|
| Servicio o área de control | Identifica el servicio en la nube, producto SaaS o subproceso exacto dentro del alcance. |
| Datos y función de la organización | Conecta el servicio con datos personales, servicios críticos, funciones financieras u operaciones esenciales. |
| Responsable del control | Define proveedor, cliente, responsabilidad compartida, subencargado o responsable interno del control. |
| Obligación del cliente | Muestra qué debe configurar, aprobar, monitorizar o evidenciar su organización. |
| Obligación del proveedor | Muestra qué debe entregar el proveedor de servicios en la nube o SaaS mediante contrato, aseguramiento o capacidad de la plataforma. |
| Dependencia de subencargado | Traza proveedores aguas abajo que pueden afectar a la seguridad, privacidad, continuidad o residencia de los datos. |
| Control del Anexo A de ISO/IEC 27001:2022 | Vincula la fila con la Declaración de Aplicabilidad y la justificación del control. |
| Mapeo NIS2, DORA, GDPR, NIST CSF o COBIT 2019 | Muestra la relevancia transversal de cumplimiento sin duplicar controles. |
| Evidencias | Define pruebas preparadas para auditoría. |
| Frecuencia de revisión | Define la cadencia de monitorización, especialmente para proveedores críticos o de alto riesgo. |
Una fila práctica de registro de eventos podría verse así.
| Servicio o área de control | Responsable del control | Obligación del cliente | Obligación del proveedor | Dependencia de subencargado | Controles y marcos | Evidencias |
|---|---|---|---|---|---|---|
| Registro de auditoría en la nube de producción | Compartida | Habilitar registros de auditoría, definir la conservación, restringir el acceso, revisar alertas y probar la recuperación | Proporcionar capacidad de registro de eventos, eventos de plataforma, opciones de conservación y compromisos de disponibilidad | Proveedor de registro de eventos o SIEM si los registros se exportan | Anexo A de ISO/IEC 27001:2022 5.20, 5.23, 8.15, 8.16; NIS2 Article 21; DORA Articles 6, 8, 10, 17; resultados Detect y Govern de NIST CSF 2.0 | Estándar de registro y monitorización, exportación de configuración en la nube, registros de muestra, alertas SIEM, revisión de acceso, cláusula contractual del proveedor, evidencias de conservación |
Esa fila no es solo documentación. Indica a seguridad qué configurar, a compras qué lenguaje contractual comprobar, a privacidad qué flujo de datos registrar y a los auditores qué evidencias solicitar.
Base de políticas: convertir la matriz en un requisito exigible
Una matriz de responsabilidad compartida en la nube sin respaldo de políticas es solo una hoja de cálculo. Las políticas de Clarysec la hacen exigible.
Para pymes, Cloud Usage Policy - SME Cloud Usage Policy - SME, sección “Requisitos de gobernanza”, cláusula 5.3, exige:
“El proveedor de TI o el DG debe mantener un Registro de Servicios en la Nube. Debe registrar:”
La misma política para pymes, cláusula 5.2.3, vincula la gobernanza de la nube con la privacidad y el riesgo de ubicación:
“La residencia de los datos y las prácticas de privacidad cumplen los requisitos legales aplicables (por ejemplo, GDPR)”
Para entornos empresariales, Cloud Usage Policy Cloud Usage Policy, sección “Requisitos de gobernanza”, cláusula 5.1, establece:
“La organización debe mantener un Registro de Servicios en la Nube centralizado, propiedad del CISO, que contenga:”
La cláusula 5.4 hace entonces exigibles contractualmente las responsabilidades en la nube:
“Todos los contratos con proveedores de servicios en la nube (CSP) deben incluir disposiciones exigibles para:”
La gobernanza de proveedores extiende la matriz más allá del proveedor inmediato. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME, sección “Requisitos de gobernanza”, cláusula 5.3.5, exige:
“Restricciones a la subcontratación adicional sin aprobación”
La misma política para proveedores de pymes, sección “Requisitos de implementación de la política”, cláusula 6.3.1, añade una revisión periódica:
“Los proveedores críticos o de alto riesgo deben revisarse al menos anualmente. La revisión debe verificar:”
A nivel empresarial, Third party and supplier security policy Third party and supplier security policy, sección “Requisitos de gobernanza”, cláusula 5.3, establece:
“Los contratos con proveedores deben incluir:”
Para datos personales, Data Protection and Privacy Policy Data Protection and Privacy Policy, sección “Aplicación y cumplimiento”, cláusula 8.5.1, exige:
“Los contratos con encargados del tratamiento deben incluir:”
Para la visibilidad de dependencias, Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, cláusula 6.5.4, exige:
“Aprovechar la relación con el proveedor para obtener actualizaciones sobre subcontratistas o dependencias de la cadena de suministro un nivel aguas abajo cuando puedan afectarnos (por ejemplo, si un proveedor crítico de software depende en gran medida de una biblioteca de terceros, esto debe registrarse).”
Para registros, Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME, sección “Requisitos de gobernanza”, cláusula 5.5.1.3, proporciona un requisito contractual concreto:
“Los contratos deben exigir a los proveedores conservar los registros durante al menos 12 meses y proporcionar acceso previa solicitud”
En conjunto, estas políticas convierten la matriz en un registro de gobernanza obligatorio que respalda la aprobación de proveedores, la incorporación de servicios en la nube, la responsabilidad proactiva en privacidad, la revisión anual y las evidencias de auditoría.
Mapeo de la matriz en ISO/IEC 27001:2022, NIS2, DORA y GDPR
El error clásico es crear cuatro libros de cumplimiento separados. Un control puede satisfacer varias obligaciones si la responsabilidad y las evidencias son trazables.
| Área de control | Anexo A de ISO/IEC 27001:2022 | Evidencias del proveedor | Evidencias del cliente | Mapeo entre marcos |
|---|---|---|---|---|
| Acuerdos con proveedores | 5.20 | Contrato, anexo de seguridad, contrato de encargo del tratamiento, informe de aseguramiento, compromiso de notificación de incidentes | Evaluación de riesgos del proveedor, lista de verificación de revisión contractual, registro de aprobación | NIS2 Article 21; DORA Article 30; GDPR Article 28; NIST CSF 2.0 GV.SC |
| Cadena de suministro TIC | 5.21 | Lista de subencargados, condiciones de subcontratación, aseguramiento aguas abajo, notificaciones de cambios | Registro de dependencias, revisión de concentración, revisión anual de proveedores | NIS2 Article 21; DORA Articles 28 y 29; objetivos de gobernanza de proveedores de COBIT 2019 |
| Uso de servicios en la nube | 5.23 | Documentación del servicio, opciones de ubicación de datos, herramientas de exportación, soporte de eliminación | Registro de servicios en la nube, estándares de configuración, plan de salida, revisión del servicio | DORA Articles 6, 8, 28 y 30; GDPR Articles 5, 28 y 32 |
| Identidad y acceso | 5.15, 5.16, 5.18 | Capacidad IAM, opciones de MFA, controles de administración, eventos de auditoría de plataforma | Aplicación de MFA, mínimo privilegio, revisiones de acceso, registros de altas, cambios y bajas | NIS2 Article 21(2)(i); DORA Article 9; GDPR Article 32 |
| Registro y monitorización | 8.15, 8.16 | Registros de plataforma, interfaces API de auditoría, opciones de conservación, avisos de servicio | Ingesta en SIEM, revisiones de alertas, ajustes de conservación de registros, restricciones de acceso | NIS2 Article 21; DORA Articles 10 y 17; GDPR Article 32 |
| Gestión de incidentes | 5.24, 5.25, 5.26, 5.27 | Avisos de incidentes del proveedor, tickets de soporte, informes de análisis de causa raíz | Playbook de incidentes, evidencias de triaje, evaluación regulatoria, lecciones aprendidas | NIS2 Article 23; DORA Articles 17, 18 y 19; GDPR Articles 33 y 34 |
| Continuidad y salida | 5.29, 5.30, 5.23 | Compromisos de disponibilidad, herramientas de exportación, certificado de eliminación, soporte de recuperación | Resultados de pruebas de copia de seguridad, ejercicios de recuperación, prueba de salida, revocación de acceso | DORA Articles 11, 24, 28 y 30; NIS2 Article 21; GDPR Article 28 |
ISO/IEC 27001:2022 proporciona el motor del SGSI: contexto, partes interesadas, alcance, liderazgo, tratamiento de riesgos, objetivos, control operacional, evaluación del desempeño y mejora. El Anexo A proporciona la estructura práctica de controles.
NIS2 Article 21 se mapea de forma natural con la misma matriz mediante seguridad de la cadena de suministro, gestión de incidentes, continuidad, control de acceso, gestión de activos y adquisición segura. Article 20 hace que la matriz sea relevante para el Consejo de Administración porque los órganos de dirección deben aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad.
DORA convierte la matriz en una herramienta de riesgo de terceros TIC. Articles 5, 6 y 8 exigen gobernanza, gestión documentada del riesgo TIC e identificación de activos, funciones y dependencias. Articles 17 a 19 exigen detección, clasificación, escalado, comunicación y notificación de incidentes. Articles 28 a 30 exigen gestión del riesgo de terceros, análisis de riesgo de concentración, cláusulas contractuales, controles de subcontratación, derechos de auditoría, derechos de terminación y estrategias de salida.
GDPR aporta la perspectiva de datos personales. Cada fila de servicio en la nube debe identificar si se tratan datos personales, si el proveedor es encargado del tratamiento o subencargado, si la ubicación de los datos importa y qué contrato o evidencias del contrato de encargo del tratamiento existen.
NIST CSF 2.0 ayuda a comunicar la misma matriz en lenguaje de resultados. La función GOVERN aborda el contexto de la organización, requisitos legales y regulatorios, dependencias, gestión de riesgos, roles, políticas y supervisión. Los resultados GV.SC son especialmente útiles para el riesgo cibernético de proveedores, incluidos roles de proveedor, criticidad, requisitos contractuales, diligencia debida, monitorización, coordinación de incidentes y planificación de terminación.
COBIT 2019 añade una perspectiva de aseguramiento y gobernanza. Pregunta si la responsabilidad proactiva, las prácticas de gestión, la propiedad, la supervisión y la remediación de problemas son repetibles y están evidenciadas.
Construir la matriz desde el registro hasta la prueba
Imagine una empresa SaaS que utiliza una plataforma IaaS hiperescalable, una base de datos gestionada, un proveedor de identidad tercero, una plataforma SaaS de soporte al cliente y un SIEM externo. El flujo de implementación es directo.
Paso 1: Empiece con el Registro de Servicios en la Nube
Use Cloud Usage Policy o Cloud Usage Policy - SME como activador. Registre cada servicio en la nube, propietario, finalidad, categorías de datos, ubicación, función de la organización, nivel del proveedor, responsable del contrato y fecha de revisión.
Si el servicio almacena registros de clientes, registros de autenticación o tickets de soporte, márquelo como relevante para privacidad. Si soporta la disponibilidad de producción, márquelo como crítico operativamente. Si soporta una función crítica o importante de un cliente financiero, márquelo como relevante para DORA.
Paso 2: Añada dominios de responsabilidad compartida
Para cada servicio, defina responsabilidades en los dominios esenciales.
| Dominio | Responsabilidad típica del proveedor | Responsabilidad típica del cliente | Pregunta típica sobre subencargados |
|---|---|---|---|
| Seguridad física y de infraestructura | Instalaciones, hardware, controles ambientales, resiliencia de la plataforma | Revisar informes de aseguramiento y compromisos contractuales | ¿Depende el proveedor de un centro de datos, CDN o subencargado de alojamiento? |
| Identidad y acceso | Capacidad IAM de la plataforma, funcionalidades de seguridad de administración, soporte de federación | MFA, diseño de roles, mínimo privilegio, revisiones de altas, cambios y bajas | ¿Accede a las cuentas un intermediario de identidad o proveedor de soporte? |
| Protección de datos | Opciones de cifrado, opciones de ubicación de datos, funcionalidades de copia de seguridad | Clasificación, configuración de cifrado, conservación, base jurídica | ¿Algún subencargado almacena o accede a datos personales? |
| Registro y monitorización | Generación de eventos, interfaces API de auditoría, telemetría de plataforma | Habilitar registros, exportar al SIEM, revisar alertas, conservar evidencias | ¿El proveedor de SIEM o MDR trata registros que contienen datos personales? |
| Respuesta a incidentes | Detección del proveedor, avisos de incidentes de plataforma, escalado de soporte | Triaje interno, notificaciones a reguladores y clientes, conservación de evidencias | ¿Los incidentes aguas abajo pueden retrasar la notificación o el análisis de causa raíz? |
| Continuidad y salida | Compromisos de disponibilidad de la plataforma, herramientas de exportación, soporte de eliminación | Objetivos de recuperación, pruebas de copia de seguridad, plan de salida, devolución o destrucción de datos | ¿Existen restricciones de recuperación derivadas de servicios o ubicaciones subcontratados? |
Paso 3: Vincule los controles con el riesgo y la Declaración de Aplicabilidad
Zenith Blueprint, fase Gestión de riesgos, paso 13, explica el requisito de trazabilidad:
“Referencie regulaciones de forma cruzada: si determinados controles se implementan específicamente para cumplir GDPR, NIS2 o DORA, puede indicarlo en el Registro de Riesgos (como parte de la justificación del impacto del riesgo) o en las notas de la SoA.”
Por ejemplo, el riesgo “acceso no autorizado a datos de producción de clientes por una configuración incorrecta en la nube” puede mapearse con control de acceso, uso de la nube, registro de eventos, criptografía, gestión de vulnerabilidades y acuerdos con proveedores. La SoA puede referenciar el Anexo A de ISO/IEC 27001:2022 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 y 8.24, con notas para GDPR Article 32, NIS2 Article 21 y la gestión del riesgo TIC de DORA cuando proceda.
Paso 4: Adjunte evidencias antes de la temporada de auditoría
Las evidencias deben diseñarse dentro de la matriz, no recopilarse con urgencia.
| Fila de la matriz | Evidencias que deben conservarse |
|---|---|
| Diligencia debida del proveedor de servicios en la nube | Evaluación de proveedores, cuestionario de seguridad, informe de aseguramiento, certificaciones, calificación del riesgo, registro de aprobación |
| Compromisos contractuales de seguridad | MSA, contrato de encargo del tratamiento, anexo de seguridad, derechos de auditoría, cláusula de subcontratación, cláusula de notificación de incidentes, términos de ubicación de datos |
| Responsabilidad de configuración del cliente | Exportación de configuración en la nube, política IAM, informe de MFA, ajustes de configuración del cifrado, reglas de red, tickets de cambio |
| Registro y monitorización | Ajustes de conservación de registros, registros de auditoría de muestra, prueba de ingesta en SIEM, registros de revisión de alertas, tickets de escalado |
| Trazabilidad de subencargados | Lista de subencargados del proveedor, registro de aprobación, mapa de flujo de datos, notas de revisión anual, notificación de cambios |
| Salida y recuperación | Resultados de pruebas de copia de seguridad, prueba de exportación de datos, certificado de eliminación, plan de salida, informe de ejercicio de recuperación |
La lista de evidencias convierte la responsabilidad en prueba. También ayuda a los equipos comerciales a responder más rápido a la diligencia debida empresarial, porque pueden mostrar no solo certificaciones, sino propiedad del control y evidencias operativas.
Subencargados: el punto ciego en la mayoría de matrices
Los subencargados son donde la responsabilidad compartida se convierte en un riesgo real de cadena de suministro.
Un proveedor SaaS puede ser su encargado del tratamiento bajo GDPR. Ese proveedor puede depender de un proveedor de alojamiento en la nube, CDN, servicio de analítica, plataforma de soporte, servicio de envío de correo electrónico, base de datos gestionada, proveedor de observabilidad y procesador de pagos. Algunos pueden acceder a datos personales. Algunos pueden soportar la prestación de servicios críticos sin ver directamente los datos. Algunos pueden estar fuera de la UE. Algunos pueden ser sustituibles. Otros pueden generar riesgo de concentración.
DORA Article 29 exige una evaluación del riesgo de concentración para servicios TIC críticos o importantes, incluida la capacidad de sustitución, múltiples acuerdos con los mismos proveedores o proveedores conectados, cadenas de subcontratación, subcontratistas de terceros países, legislación de insolvencia, restricciones de recuperación de datos y exigibilidad de la protección de datos de la Unión. DORA Article 30 exige disposiciones contractuales sobre condiciones de subcontratación, ubicaciones, tratamiento y almacenamiento de datos, acceso y recuperación, asistencia en incidentes, cooperación con autoridades, derechos de auditoría, terminación y salida.
NIS2 Article 21 exige de forma similar seguridad de la cadena de suministro para proveedores directos y proveedores de servicios, además de considerar vulnerabilidades específicas del proveedor, prácticas de ciberseguridad del proveedor y procedimientos de desarrollo seguro.
Por eso Clarysec trata el mapeo de subencargados como una extensión obligatoria de la gobernanza de proveedores, no como una lista exclusivamente de privacidad. El registro de subencargados debe mostrar qué proveedor utiliza al subencargado, qué servicio depende de él, si se tratan datos personales, si soporta una función crítica, la región de tratamiento cuando sea pertinente, el traslado contractual de requisitos, los derechos de aprobación u oposición, el aseguramiento disponible, el método de monitorización y la opción de salida.
Zenith Blueprint, fase Controles en acción, paso 23, establece:
“Para cada proveedor crítico, identifique si utiliza subcontratistas (subencargados) que puedan acceder a sus datos o sistemas. Documente cómo sus requisitos de seguridad de la información se trasladan a estas partes, ya sea mediante las condiciones contractuales de su proveedor o mediante sus propias cláusulas directas.”
Ese es el nivel de prueba que los auditores esperan cuando preguntan si las responsabilidades en la nube están controladas aguas abajo.
Cómo prueban los auditores la misma matriz
Una matriz de responsabilidad compartida en la nube sólida resiste varios estilos de auditoría porque se construye sobre propiedad, exigibilidad y evidencias.
| Perspectiva de auditoría | Qué probará el auditor | Evidencias que esperará |
|---|---|---|
| Auditor de ISO/IEC 27001:2022 | Alcance del SGSI, partes interesadas, evaluación de riesgos, aplicabilidad de la SoA, controles de proveedores, uso de la nube, evidencias operativas y mejora continua | Alcance del SGSI, registro de riesgos, SoA, registro de proveedores, registro de servicios en la nube, contratos, registros de revisión, hallazgos de auditoría interna, acciones correctivas |
| Revisor de preparación NIS2 | Aprobación de la dirección, cobertura de controles de Article 21, seguridad de la cadena de suministro, gestión de incidentes, continuidad, acceso, gestión de activos y evaluación de la eficacia | Informes al Consejo de Administración, aprobaciones de políticas, revisiones de riesgo de proveedores, playbooks de incidentes, pruebas de continuidad, evidencias de MFA, registros de vulnerabilidades y registro de eventos |
| Evaluador DORA | Gobernanza TIC, marco de riesgo TIC, inventario de activos y dependencias, acuerdos críticos con terceros TIC, cláusulas contractuales, riesgo de concentración, pruebas y estrategia de salida | Marco de riesgo TIC, registro de servicios TIC, evaluación de criticidad, contratos, derechos de auditoría, registros de incidentes, pruebas de resiliencia, pruebas de salida, análisis de subcontratación |
| Revisor GDPR | Roles de responsable del tratamiento y encargado del tratamiento, finalidades del tratamiento, integridad y confidencialidad, preparación ante violaciones de seguridad, contratos con encargados del tratamiento y transparencia de subencargados | Registro de actividades de tratamiento, contrato de encargo del tratamiento, lista de subencargados, mapa de flujo de datos, medidas de seguridad, procedimiento de violaciones de datos, evidencias de conservación y eliminación |
| Evaluador NIST CSF | Resultados GOVERN, riesgo cibernético de proveedores, inventario de activos, control de acceso, seguridad de datos, monitorización, respuesta y recuperación | Perfiles actual y objetivo, proceso de riesgo de proveedores, inventario de activos, informes de acceso, registros de monitorización, ejercicios de incidentes, prueba de recuperación |
| Auditor COBIT 2019 o ISACA | Responsabilidad proactiva de la gobernanza, prácticas de gestión, propiedad de controles, supervisión del desempeño, gestión de problemas y trazabilidad del aseguramiento | RACI, actas de gobernanza, excepciones a la política, KPI, cuadros de mando de proveedores, registros de problemas, resultados de revisión por la dirección |
La matriz no es el objetivo final. Es el mapa que usan los auditores para comprobar si el sistema de gobernanza es real.
Un auditor ISO puede seleccionar un riesgo de alto impacto de acceso en la nube y trazarlo desde el registro de riesgos hasta la SoA, y después hasta las revisiones de acceso, evidencias de MFA y alertas de monitorización. Un evaluador DORA puede seleccionar un proveedor TIC crítico y pedir la prueba de salida, el análisis de subcontratación y los derechos contractuales de auditoría. Un revisor GDPR puede centrarse en eliminación, residencia de los datos, notificación de violaciones de datos y transparencia de subencargados.
Patrones habituales de fallo
Los fallos más frecuentes de responsabilidad compartida no son exóticos.
Primero, las organizaciones dependen de informes de aseguramiento del proveedor sin mapearlos con las responsabilidades del cliente. Un proveedor de servicios en la nube puede demostrar seguridad física, resiliencia de infraestructura y controles de plataforma, pero no si su bucket de almacenamiento era privado, si los roles IAM aplicaban mínimo privilegio o si los registros estaban habilitados.
Segundo, los contratos contienen lenguaje genérico de seguridad, pero no plazos de incidentes, derechos de acceso a registros, derechos de auditoría, límites de subcontratación, disposiciones de devolución de datos o soporte de salida. Zenith Blueprint, fase Controles en acción, paso 23, destaca áreas típicas de acuerdos con proveedores como confidencialidad, control de acceso, medidas técnicas y organizativas, plazos de incidentes, derecho de auditoría, controles de subcontratistas y disposiciones de fin de contrato.
Tercero, los subencargados se enumeran para fines de privacidad, pero no se vinculan con seguridad, continuidad o riesgo de concentración. Un proveedor aguas abajo de observabilidad o soporte puede no aparecer nunca en el registro de riesgos aunque su indisponibilidad o brecha de seguridad pueda afectar a la prestación del servicio al cliente.
Cuarto, la SoA dice que un control es aplicable, pero nadie puede producir evidencias operativas. El registro de eventos en la nube puede estar marcado como implementado, pero la organización no puede demostrar los ajustes de conservación, las revisiones de acceso, la gestión de alertas o los compromisos del proveedor de acceso a registros.
Quinto, los planes de respuesta a incidentes no reflejan la dependencia del proveedor. Si el proveedor notifica un incidente de plataforma, ¿quién evalúa el impacto en el cliente? ¿Quién determina si se requiere notificación bajo NIS2, DORA o GDPR? ¿Quién contacta con los clientes afectados? ¿Qué ocurre si la causa raíz está en un subencargado?
Responsabilidad de la dirección: por qué debe importarle al Consejo
NIS2 Article 20 exige que los órganos de dirección aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implementación y reciban formación. DORA Article 5 exige que el órgano de dirección defina, apruebe, supervise y sea responsable de los acuerdos de gestión del riesgo TIC, incluidas las políticas de terceros TIC, los planes de continuidad y recuperación, los planes de auditoría, la formación y los canales de notificación.
Esto cambia el propósito de la matriz. Ya no es solo una hoja de trabajo de seguridad. Se convierte en evidencia de que la dirección conoce:
- Qué servicios en la nube soportan operaciones críticas.
- Qué terceros y subencargados son materiales.
- Qué obligaciones aplican bajo contratos de cliente, GDPR, NIS2 y DORA.
- Qué responsabilidades retiene la organización.
- Qué compromisos del proveedor son contractualmente exigibles.
- Qué deficiencias requieren financiación, remediación o aceptación del riesgo.
Para pymes, la proporcionalidad importa. Una entidad más pequeña no necesita una burocracia pesada, pero sí necesita documentación, supervisión, sistemas resilientes, detección de fuentes de riesgo TIC, identificación de dependencias clave de terceros, medidas de continuidad, pruebas, lecciones aprendidas y revisión periódica cuando esté dentro del alcance.
La matriz es una de las herramientas proporcionales más eficientes porque consolida obligaciones en lugar de multiplicarlas.
Un sprint de 30 días para preparar su modelo en la nube para auditorías
Si no puede responder quién es responsable de cada control en la nube, qué evidencias lo demuestran y qué subencargado podría afectarlo, su modelo de responsabilidad compartida sigue siendo un diagrama, no un artefacto de gobernanza.
Un sprint práctico de 30 días se ve así:
- Cree o actualice el Registro de Servicios en la Nube usando Cloud Usage Policy o Cloud Usage Policy - SME.
- Identifique servicios críticos, tratamiento de datos personales, sistemas orientados al cliente y relevancia DORA o NIS2.
- Construya la primera matriz alrededor de los controles 5.20, 5.21 y 5.23 del Anexo A de ISO/IEC 27001:2022 usando Zenith Controls.
- Vincule cada fila con el registro de riesgos y la Declaración de Aplicabilidad usando el paso 13 de Zenith Blueprint.
- Valide cláusulas de proveedores y encargados del tratamiento usando Third party and supplier security policy, Third-Party and Supplier Security Policy - SME y Data Protection and Privacy Policy.
- Añada conservación de registros, escalado de incidentes, aprobación de subencargados, derechos de auditoría y evidencias de salida.
- Revise proveedores críticos anualmente y después de cambios importantes, incidentes, nuevos subencargados o hallazgos de auditoría.
El objetivo es sencillo. Cuando el cliente, auditor, regulador o Consejo pregunte “¿quién es responsable de este control?”, no busque entre contratos, tickets y carpetas. Abra la matriz, muestre el responsable, muestre la cláusula, muestre las evidencias y muestre la pista aguas abajo.
Clarysec puede ayudarle a convertir los paquetes de aseguramiento de proveedores de servicios en la nube en una matriz integrada de responsabilidad compartida para auditorías ISO/IEC 27001:2022, preparación NIS2, riesgo de terceros TIC DORA, responsabilidad proactiva GDPR y diligencia debida de clientes corporativos.
Empiece por el registro. Construya la matriz. Adjunte las evidencias. Después úsela como prueba preparada para el Consejo de que el riesgo en la nube no se externaliza: se gobierna.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
