Auditoría SAP: lo que nadie revisa en las evidencias (y que termina generando hallazgos)
16 de abril de 2026
7 errores en roles y autorizaciones SAP que generan riesgos
21 de mayo de 2026
Cuando el control mitigante pasa del diseño a la realidad
Hay algo curioso con los controles mitigantes en entornos SAP: en diseño casi siempre tienen sentido, pero en operación muchas veces no terminan de funcionar como deberían.
Sobre el papel, el modelo de SAP Access Control está bien construido. Se definen riesgos, se identifican acciones críticas, se asignan usuarios, se establecen controles mitigantes y se nombran monitores y aprobadores. Todo encaja. Si te quedas en ese nivel, da la sensación de que el sistema está bastante cerrado.
El problema aparece cuando alguien tiene que ejecutar ese control de verdad.
Porque en ese momento la pregunta es muy simple: ¿qué tengo que revisar exactamente? Y muchas veces no hay una respuesta concreta.
Lo habitual es encontrarse con definiciones del tipo “revisar la actividad del usuario mitigado de forma periódica”. Suena bien, pero en la práctica significa abrir varios reportes, cruzar información y tratar de decidir qué es relevante y qué no. Si el volumen es alto, se convierte rápidamente en algo difícil de manejar.No es que el modelo esté mal. Es que se queda corto en el último paso. SAP GRC trabaja, con bastante lógica, desde el punto de vista de las acciones: qué se puede hacer, quién lo puede hacer y cuándo se ha hecho. Los reportes estándar ayudan a entender eso y a acotar el riesgo.
El salto entre acciones y documentos
Cerrar el último tramo del control
Para llegar ahí, normalmente hay que apoyarse en el backend: un reporte del módulo, una CDS, una query, BW o incluso un desarrollo específico. No es algo que venga resuelto directamente. Es una pieza que hay que construir.
Cuando esa pieza existe, el control se vuelve mucho más claro. El monitor no tiene que interpretar ni buscar. Recibe directamente los casos que entran dentro del control: documentos concretos, con su contexto, dentro de un periodo definido.
La diferencia es bastante evidente. No es lo mismo pedir “revisar actividad” que pedir “revisar todos los pagos manuales, cambios de datos bancarios y altas de proveedor realizados por usuarios con riesgo mitigado en la última semana, dejando evidencia de cada revisión”. En el segundo caso, el control se puede ejecutar sin ambigüedades.
El estándar de GRC no llega hasta ese nivel porque no está pensado para trabajar con números de documento. Está centrado en riesgos y acciones, que es donde aporta valor. Pero eso deja un hueco que, si no se cubre, termina afectando a la calidad real del control.
Soluciones como RCMM nacen precisamente para cerrar ese último tramo. La lógica es directa: partir de los usuarios con riesgo aprobado, identificar qué operaciones han realizado y trasladar al revisor los documentos concretos que tiene que analizar, dentro de un flujo estructurado de revisión.El cambio no es tanto técnico como práctico. Se pasa de una revisión abierta, donde cada uno decide por dónde empezar, a una lista cerrada de casos sobre la que trabajar.
En entornos con volumen, eso se nota. La revisión es más ágil, el alcance está claro desde el principio y la evidencia queda definida de forma consistente. Además, permite mantener una trazabilidad completa entre el riesgo, la operación ejecutada, el documento generado y la revisión realizada.La diferencia entre definir un control y poder ejecutarlo
Al final, la diferencia no está en tener un control definido, sino en poder ejecutarlo sin fricción.
