Por qué el RACI es importante en entornos regulados
Los marcos regulatorios — incluyendo DORA, NIS2 e ISO 27001 — comparten una expectativa común: las organizaciones deben demostrar una responsabilidad clara en las decisiones de seguridad. Cuando un regulador o auditor pregunta «¿quién aprobó esta excepción?» o «¿quién es responsable de garantizar que se apliquen los controles de seguridad del pipeline?», la respuesta no puede ser vaga ni distribuida entre equipos sin nombre.
Una matriz RACI (Responsable, Aprobador, Consultado, Informado) es el instrumento de gobernanza establecido para mapear actividades con roles. En un contexto de DevSecOps, sirve para un doble propósito: estructura la toma de decisiones interna y proporciona a los auditores un único documento que evidencia el diseño de la responsabilidad.
Sin una RACI documentada, las organizaciones se enfrentan a varios riesgos regulatorios:
- Incapacidad para demostrar quién aprobó excepciones de seguridad o aceptaciones de riesgo
- Caminos de escalada poco claros cuando las puertas de seguridad fallan o se eluden
- Hallazgos de auditoría relacionados con violaciones de segregación de funciones
- Sanciones regulatorias en virtud del Artículo 5 de DORA (responsabilidad del órgano de dirección) o del Artículo 20 de NIS2 (gobernanza y responsabilidad)
RACI explicado para partes interesadas no técnicas
Antes de aplicar la matriz, es esencial que todas las partes interesadas — especialmente los responsables de cumplimiento y los propietarios de riesgo — comprendan las cuatro designaciones:
| Letra | Rol | Significado | Pregunta clave |
|---|---|---|---|
| R | Responsable | La persona o equipo que realiza el trabajo | ¿Quién hace la tarea? |
| A | Aprobador | La única persona que es en última instancia responsable — aprueba o da el visto bueno | ¿Quién responde ante el regulador? |
| C | Consultado | Aquellos cuya opinión se solicita antes de tomar una decisión o acción | ¿De quién se necesita la experiencia? |
| I | Informado | Aquellos que son notificados después de tomar una decisión o acción | ¿Quién necesita saberlo? |
Regla crítica de gobernanza: Debe haber exactamente un «A» por actividad. Si la responsabilidad se comparte, se diluye — y la responsabilidad diluida es, en términos regulatorios, ninguna responsabilidad en absoluto.
Matriz RACI completa para actividades de DevSecOps
La siguiente matriz mapea catorce actividades centrales de DevSecOps a ocho roles organizacionales. Debe adaptarse a la estructura de su organización, pero proporciona un punto de partida sólido para entornos regulados.
| Actividad | CISO | Arquitecto de seguridad | Responsable de DevSecOps | Equipo de plataforma / CI-CD | Responsable del equipo de desarrollo | Desarrollador | Responsable de cumplimiento | Propietario del riesgo |
|---|---|---|---|---|---|---|---|---|
| Definición de la política de seguridad | A | C | C | I | I | I | C | C |
| Configuración de seguridad del pipeline | I | C | A | R | C | I | I | I |
| Gestión de herramientas SAST/DAST/SCA | I | C | A | R | I | I | I | I |
| Clasificación de vulnerabilidades | I | C | A | I | R | C | I | I |
| Ejecución de la remediación | I | C | I | I | A | R | I | I |
| Aprobación de excepciones/supresiones | I | C | C | I | I | I | C | A |
| Configuración de puertas de seguridad | I | R | A | R | C | I | C | I |
| Gestión de control de acceso | A | C | R | R | C | I | C | I |
| Gestión de secretos | I | A | R | R | C | C | I | I |
| Respuesta a incidentes | A | C | R | R | C | C | I | I |
| Preparación para auditorías | I | C | R | C | C | I | A | I |
| Informes de métricas | I | I | R | C | C | I | A | I |
| Evaluación de riesgos de terceros | I | C | C | I | I | I | C | A |
| Formación en seguridad | A | C | R | I | C | R | I | I |
Notas de gobernanza: Responsabilidad y escalada
Responsabilidad final por la seguridad del pipeline
En la matriz anterior, el Responsable de DevSecOps es responsable de la configuración técnica y la aplicación de la seguridad del pipeline. Sin embargo, el CISO mantiene la responsabilidad última sobre la política de seguridad y su eficacia. Esta responsabilidad de dos niveles debe estar claramente documentada.
En virtud de DORA, el órgano de dirección (normalmente el consejo de administración o el comité de alta dirección) es responsable del marco general de riesgo ICT. El CISO actúa como su delegado para las operaciones de seguridad. Esta delegación debe estar formalmente documentada y revisada periódicamente.
Camino de escalada
Cuando surgen conflictos — por ejemplo, un equipo de desarrollo impugna una puerta de seguridad que bloquea un lanzamiento — el camino de escalada debe seguir un procedimiento documentado:
- Primer nivel: El Responsable de DevSecOps y el Responsable del equipo de desarrollo intentan resolver el problema
- Segundo nivel: El Arquitecto de seguridad proporciona una resolución técnica
- Tercer nivel: El Propietario del riesgo y el Responsable de cumplimiento evalúan la aceptación del riesgo
- Nivel final: El CISO toma la decisión vinculante, documentada en el registro de riesgos
Cada escalada debe registrarse. Los auditores buscarán evidencia de que se siguió el camino de escalada — no solo de que existe en el papel.
Adaptación del RACI al tamaño de la organización
Empresa (separación completa de roles)
Las grandes organizaciones reguladas — bancos, aseguradoras, operadores de infraestructuras críticas — deben mantener la separación completa de roles como se muestra en la matriz anterior. Cada rol lo ocupa un individuo o equipo distinto. Esto proporciona la mayor segregación de funciones y el camino de auditoría más claro.
Requisitos clave a esta escala:
- Equipo de DevSecOps dedicado, separado del desarrollo y las operaciones
- Rol de Arquitecto de seguridad distinto del Responsable de DevSecOps
- Participación formal del Responsable de cumplimiento en las aprobaciones de excepciones
- Propietario del riesgo designado por línea de negocio o cartera de aplicaciones
Tamaño mediano (roles combinados)
Las organizaciones con 200 a 1.000 empleados pueden necesitar combinar ciertos roles. Las combinaciones aceptables incluyen:
- Arquitecto de seguridad + Responsable de DevSecOps (una persona, rol dual documentado)
- Responsable de cumplimiento + Propietario del riesgo (si no hay conflicto de intereses directo)
- Equipo de plataforma + equipo de DevSecOps (con responsabilidades de seguridad documentadas)
Combinaciones inaceptables:
- Desarrollador + Aprobador de excepciones (la autoaprobación viola la segregación de funciones)
- Responsable de DevSecOps + único Clasificador de vulnerabilidades + único Aprobador de excepciones (sin revisión independiente)
Pequeña (separación mínima viable)
Las empresas reguladas más pequeñas aún deben demostrar responsabilidad. Como mínimo:
- Una persona designada responsable de la política de seguridad (aunque sea a tiempo parcial)
- Las aprobaciones de excepciones requieren la firma de alguien distinto al solicitante
- Las responsabilidades de preparación para auditorías asignadas a un individuo nombrado
- El consejo de administración o el comité de dirección recibe informes periódicos de seguridad
Documente explícitamente dónde se combinan los roles y qué controles compensatorios existen (por ejemplo, revisión por pares, auditoría externa, controles automatizados).
Qué deben verificar los auditores
Al evaluar el RACI de DevSecOps de una organización, los auditores deben buscar evidencia en tres dimensiones:
1. Documentación
- ¿Existe una matriz RACI formalmente aprobada que cubra las actividades de DevSecOps?
- ¿Está bajo control de versiones y se revisa al menos anualmente?
- ¿Cubre todas las actividades críticas de seguridad, no solo un subconjunto?
- ¿Son claras las definiciones de roles y están mapeadas a individuos o equipos nombrados?
2. Evidencia de responsabilidad en la práctica
- Muestrear aprobaciones de excepciones: ¿quién las aprobó realmente? ¿Coincide con el RACI?
- Registros de elusión de puertas de seguridad: ¿participó la parte responsable?
- Registros de respuesta a incidentes: ¿participaron los roles designados como se definió?
- Permisos de acceso: ¿se alinean los derechos de acceso al sistema con las asignaciones del RACI?
3. Alineación entre el RACI y los permisos del sistema
- Solo aquellos designados como Responsables o Aprobadores para la gestión del control de acceso deben tener privilegios administrativos en las plataformas CI/CD
- Los flujos de trabajo de aprobación de excepciones deben aplicar la cadena de aprobación definida en el RACI
- El acceso a los registros de auditoría debe estar restringido a aquellos con roles de Responsable o Aprobador para la preparación de auditorías
Señales de alerta para auditores y responsables de cumplimiento
| Señal de alerta | Por qué importa | Implicación regulatoria |
|---|---|---|
| Sin RACI documentado para DevSecOps | No se puede demostrar la responsabilidad | DORA Art. 5, ISO 27001 A.5.2 |
| Desarrolladores que autoaprueban excepciones de seguridad | Violación de segregación de funciones | PCI DSS Req. 6, SOC 2 CC6.1 |
| El equipo de seguridad no es consultado sobre los cambios del pipeline | Los controles de seguridad pueden debilitarse sin supervisión | NIS2 Art. 21, ISO 27001 A.8.32 |
| El CISO no es informado de las aceptaciones de riesgo | Deficiencia en la supervisión del órgano de dirección | DORA Art. 5(4), NIS2 Art. 20 |
| Múltiples personas listadas como Aprobadores para la misma actividad | Responsabilidad diluida — sin único punto de propiedad | Debilidad general de gobernanza |
| RACI no actualizado tras cambios organizacionales | La matriz no refleja la realidad | ISO 27001 A.5.4 |
| Sin evidencia de uso del camino de escalada | Sugiere que los conflictos se resuelven informalmente sin gobernanza | Deficiencia en el rastro de auditoría |
Próximos pasos
Una matriz RACI de DevSecOps bien gobernada es un documento de control fundamental. Sustenta todas las demás actividades de gobernanza — desde el diseño del programa DevSecOps hasta la preparación para auditorías y gobernanza.
Las organizaciones deben:
- Redactar o revisar su RACI de DevSecOps comparándolo con la plantilla anterior
- Validar que los permisos de acceso al sistema se alinean con la matriz
- Probar el camino de escalada con un ejercicio de simulación
- Programar la revisión anual, alineada con la gestión de cambios organizacionales
- Conservar copias con versiones como evidencia de auditoría
Relacionado para auditores
- Glosario — Definiciones en lenguaje sencillo de términos técnicos
- Informe ejecutivo de auditoría
- Cómo los auditores revisan CI/CD
- Controles de seguridad principales de CI/CD
¿Nuevo en la auditoría de CI/CD? Comience con nuestra Guía para auditores.
