Modelo de Responsabilidad Compartida Cloud GxP: roles y matriz RACI
Modelo de Responsabilidad Compartida en Cloud GxP: matriz de roles y responsabilidades para IaaS, PaaS y SaaS
En un proyecto Cloud GxP hay una pregunta que decide el éxito —o un hallazgo en auditoría—:
«De acuerdo, ¿pero quién hace qué?»
El cloud traslada actividades operativas (parcheo, infraestructura, hardening de seguridad, copias de seguridad, monitorización) al proveedor. La responsabilidad de cumplimiento, sin embargo, sigue siendo tuya: puedes delegar actividades, no la responsabilidad final.
Esta página te ayuda a:
- comprender las diferencias reales entre IaaS, PaaS y SaaS (en términos de controles),
- construir una matriz de responsabilidades que resista una auditoría,
- transformar la matriz en Quality Agreements + SOPs + evidencias.
Qué es realmente el Modelo de Responsabilidad Compartida en un contexto GxP
El principio es sencillo:
- el proveedor gestiona parte del stack y proporciona controles/garantías,
- tú gestionas la parte restante y debes demostrar que el sistema en su conjunto está controlado,
- en una inspección, si existe una brecha, no puedes decir «era del proveedor»: debes demostrar cómo la gobernaste.
La guía es clara: en el cloud algunas responsabilidades son compartidas, pero la empresa regulada debe garantizar, mediante contratos, auditorías y gobernanza, que el proveedor opere con estándares adecuados.
IaaS vs PaaS vs SaaS: cómo cambia el “peso” de la responsabilidad
Regla práctica (muy útil para QA e IT):
- SaaS: muchas responsabilidades técnicas recaen en el proveedor → tú gobiernas configuración, accesos, procesos, gobierno del dato, cambios/actualizaciones, uso previsto y formación.
- IaaS: más responsabilidades permanecen en el cliente (SO, parcheo, hardening, backup, monitorización, etc.) → el esfuerzo de cumplimiento es mucho más cercano a on-prem.
En síntesis: en SaaS gran parte del stack es gestionado por el proveedor; al acercarse a IaaS aumentan las responsabilidades y controles del cliente.
La matriz que funciona: dominios de control + ownership + evidencias
Una Matriz de Responsabilidades “audit-proof” no es una tabla genérica. Debe responder a tres preguntas:
- ¿Quién ejecuta la actividad? (Proveedor / Cliente / Compartido)
- ¿Quién aprueba o decide? (a menudo QA / Negocio)
- ¿Cuál es la evidencia? (informes, logs, SOPs, tickets, informes de auditoría, informes SOC, etc.)
Ejemplo de estructura (apta para CMS/Excel):
| Dominio | Ejecución | Aprobación | Evidencias típicas |
|---|---|---|---|
| Accesos y roles (RBAC) | Cliente | QA / Process Owner | matriz de roles, logs de acceso, SOP de cuentas |
| Audit trail | Proveedor (función) + Cliente (revisión) | QA | config. audit trail, SOP de revisión, registros |
| Backup/restore | Proveedor / Compartido | IT + QA | política de backup, informes, pruebas de restore, tickets |
| Cambios/actualizaciones | Proveedor (release) + Cliente (evaluación) | QA | release notes, change records, tests de regresión |
| Incidentes/RCA | Proveedor + Cliente | QA | RCA, desviación/CAPA, comunicaciones |
| Exportación/retención de datos | Compartido | QA/RA | pruebas de exportación, procedimientos, contrato |
Nota: los dominios y las evidencias deben ajustarse al modelo cloud (SaaS/IaaS) y a la criticidad del sistema.
Del workshop al documento: las preguntas “correctas” al proveedor
Una matriz sólida nace de un workshop con proveedor + QA + IT + negocio.
Ejemplos de preguntas de alto valor (y a menudo ignoradas):
- «¿Quién realiza el restore si un usuario borra datos por error: nosotros desde la interfaz o ustedes bajo solicitud?»
- «¿Quién garantiza que los backups funcionan y qué informes recibimos?»
- «¿Disponemos de un entorno sandbox/staging para probar nuevas releases antes de producción?»
La guía recomienda explícitamente aclarar estos puntos y reflejarlos después en la matriz y en el Quality Agreement.
Cómo convertir la matriz en gobernanza real (y no en “un PDF en un cajón”)
1) Quality Agreement (QA) / anexos contractuales
Aquí se fijan los compromisos:
- notificación de cambios (timing y contenido de las release notes),
- gestión de incidentes y RCA,
- propiedad, devolución y salida de datos,
- derechos de auditoría y acceso a evidencias (p. ej., informes SOC).
2) SOPs internas
Sin SOPs, la matriz no vive:
- SOP de gestión de cuentas y privilegios,
- SOP de revisión de audit trail,
- SOP de control de cambios en cloud (incluidas actualizaciones SaaS).
3) Evidencias operativas
En auditoría no basta con decir «tenemos la SOP»: hay que demostrar su aplicación:
- registros de revisión,
- change records cerrados con pruebas,
- registros de formación,
- revisiones periódicas.
Errores comunes (los que activan las preguntas del auditor)
- Matriz existente pero no alineada con contrato/QA
- «Todo es responsabilidad del proveedor» sin derechos de auditoría ni evidencias
- Roles y accesos sin segregación adecuada
- Falta de una regla clara para las actualizaciones SaaS (cómo y cuándo se aceptan)
Mini-checklist (lista para copiar en SOPs)
- Existe una Matriz de Responsabilidades para cada proveedor cloud GxP
- La matriz incluye ejecución, aprobación y evidencias
- Los puntos críticos (backup, audit trail, change, RCA) están cubiertos por el Quality Agreement
- Las SOPs internas reflejan el modelo cloud (no solo on-prem)
- El audit pack contiene pruebas de ejecución (registros, informes, logs)
¿Quieres una estructura completa con ejemplos, checklists y plantillas para definir roles y responsabilidades y presentarlos correctamente en auditoría? Compra la guía «SaaS & Cloud Validation: guía de implementación GxP» en guidegxp.com.