CONTROL DE RIESGOS SoD

El mejor momento para detectar un conflicto es antes de introducirlo en el modelo

Integramos el análisis de segregación de funciones en el diseño, modificación y asignación de roles para evaluar el impacto del cambio antes de trasladarlo al entorno productivo.

Diseñar. Validar. Ajustar. Aplicar.
EL PROBLEMA

Un rol puede resolver una necesidad y crear otra exposición

Un cambio aparentemente sencillo puede incorporar una transacción incompatible, ampliar una autorización o generar un conflicto cuando se combina con otros accesos que el usuario ya tiene.

Si el análisis SoD se realiza únicamente después de asignar el rol, el riesgo ya forma parte del modelo. El enfoque preventivo permite evaluar ese impacto mientras todavía existe margen para modificar la decisión.

DÓNDE APARECE EL RIESGO

Un conflicto puede nacer en el rol o aparecer al combinarlo

Por eso el control debe acompañar tanto el diseño del modelo como las decisiones posteriores de asignación.

DISEÑO DEL ROL

Riesgo dentro del propio diseño

Una función, tarea o rol puede contener transacciones o autorizaciones que entren en conflicto entre sí.

Validarlo durante la construcción permite ajustar el modelo antes de considerarlo definitivo.

ASIGNACIÓN

Riesgo por combinación de accesos

Un rol puede ser válido de forma aislada y generar una incompatibilidad cuando se combina con los accesos que el usuario ya tiene.

La asignación necesita evaluarse contra la matriz antes de trasladar el cambio al modelo efectivo.

QUÉ VALIDAMOS

Analizar el riesgo antes de aplicar el cambio

01

Roles

Revisamos si el contenido de un rol incorpora funciones incompatibles o accesos críticos.

02

Usuarios

Evaluamos el riesgo efectivo que tendría una nueva asignación sobre los accesos que ya posee el usuario.

03

Perfiles

Incorporamos al análisis perfiles que puedan modificar la exposición efectiva de roles y usuarios.

04

Asignaciones

Contrastamos nuevas relaciones usuario–rol antes de incorporarlas al entorno productivo.

NUESTRO ENFOQUE

Introducir el control SoD dentro del propio cambio

El análisis deja de ser una revisión posterior y se convierte en una validación integrada en el diseño y evolución del modelo.

04

Decidir

Si el riesgo no puede eliminarse, se analiza su tratamiento antes de continuar.

05

Aplicar

El cambio se traslada al modelo una vez completadas las validaciones correspondientes.

ANTE UN CONFLICTO

Detectar el riesgo antes permite decidir qué hacer mientras todavía se puede cambiar el modelo

El resultado del análisis puede llevar a revisar el diseño, modificar una asignación, separar funciones o, cuando existe una necesidad operativa justificada, trasladar el riesgo a un proceso de aprobación y control.

01

Ajustar el diseño

Revisar funciones, tareas, transacciones o autorizaciones cuando el riesgo está contenido en el propio modelo.

02

Revisar la asignación

Evaluar si el conflicto procede de combinar el nuevo acceso con otros permisos existentes del usuario.

03

Tratar la excepción

Cuando existe una necesidad justificada, documentar la decisión y definir el tratamiento posterior del riesgo.

TECNOLOGÍA PROPIA

Validar el riesgo a lo largo de la evolución del acceso

Distintas soluciones de APLIRH SUITE permiten incorporar el análisis SoD desde la construcción del rol hasta su asignación dentro de la organización.

Cuando un riesgo necesita ser autorizado, los flujos de aprobación y su tratamiento posterior pueden integrarse dentro del modelo de gobierno.

Explorar APLIRH SUITE →
CUÁNDO ACTUAR

Cuando corregir después cuesta más que validar antes

El control preventivo tiene especial sentido cuando el modelo está cambiando y todavía existe margen para evitar trasladar nuevas incompatibilidades a productivo.

01 Durante una reingeniería o remediación del modelo de roles.
02 Antes de una migración a S/4HANA o RISE.
03 Cuando los nuevos roles se validan únicamente después de llegar a productivo.
04 Cuando los usuarios acumulan roles y los conflictos aparecen por combinación de accesos.
05 Cuando los hallazgos SoD reaparecen después de cada cambio importante del modelo.
El control SoD no debería empezar después de conceder el acceso.
Debería formar parte de la decisión que lo crea.
HABLEMOS

¿Cuándo detectáis hoy un conflicto SoD: antes o después del cambio?

Cuéntanos cómo validáis actualmente roles y asignaciones y podremos valorar contigo cómo incorporar el análisis preventivo al modelo de autorizaciones.

Hablar con APLIRH →