Revisar accesos una vez al año no frena el drift de roles
Por qué la recertificación anual de accesos llega tarde al true-up de RISE with SAP y cómo pasar a un control proactivo del drift de autorizaciones.
· 12 min de lectura
Entre la firma que cierra una revisión de accesos y la firma que cierra la siguiente pasan doce meses. Para el expediente de auditoría, ese intervalo es un punto. Para una distribuidora eléctrica, es un año operativo completo: cuadrillas que rotan de zona, contratistas estacionales de toma de lecturas que entran y salen, reemplazos por incapacidad médica, accesos abiertos de urgencia durante un corte masivo, la energización de una subestación nueva, el cierre de un proyecto de integración AMI que deja a media docena de consultores todavía dados de alta.
Ninguno de esos eventos consulta el calendario de auditoría. Todos dejan autorizaciones sedimentadas. Y ese sedimento es exactamente lo que el contrato de suscripción termina contando.
Esta pieza no discute si hay que recertificar accesos —hay que hacerlo— sino con qué cadencia. Porque el drift de roles no es un problema de rigor: casi todas las revisiones anuales que hemos visto están bien ejecutadas. Es un problema de frecuencia. Un control que corre una vez al año no puede sostener un estado que cambia todas las semanas.
Doce meses no es un intervalo: es la excepción convertida en norma
Una utility en su primer o segundo año post-go-live sobre RISE with SAP tiene un agravante adicional: el diseño de roles todavía está caliente. Los roles se ajustaron contra reloj durante el hipercuidado, se abrieron de más para no frenar la recaudación, y nadie los volvió a cerrar cuando la operación se estabilizó. La primera revisión anual encuentra ese estado y lo certifica como válido —porque, funcionalmente, lo es. El analista sí usa esa transacción. La pregunta que la revisión anual no hace es si necesita seguir teniéndola asignada el resto del año.
El resultado es un control que llega tarde por diseño. No falla: confirma. Certifica que el estado acumulado durante doce meses era razonable, en lugar de impedir que se acumulara.
Un control diseñado para el auditor, no para la cadencia operativa
Vale la pena recordar de dónde viene la periodicidad anual, porque no la eligió el área de operaciones. Las revisiones de acceso sirven principalmente a propósitos de auditoría y son exigidas por regulaciones como Sarbanes-Oxley, JSOX y GDPR, que obligan a las organizaciones a realizarlas de forma regular, típicamente una vez al año (Xiting, 2026). Su objetivo declarado es revisar las autorizaciones otorgadas al menos una vez al año para confirmar que el usuario del negocio todavía las necesita (Xiting, 2026).
“Al menos una vez al año” es un piso regulatorio, no un techo de gobierno. La confusión que cuesta dinero es tratarlo como si fuera el diseño completo del control en lugar de su requisito mínimo.
De cumplimiento reactivo a gestión proactiva del riesgo
Los objetivos clave de una revisión de accesos incluyen simular cambios de acceso, verificar la validez del acceso y minimizar el drift de autorizaciones; y para lograrlo se requiere un cambio de mentalidad desde un enfoque orientado al cumplimiento hacia uno de gestión proactiva del riesgo (Xiting, 2026). Esa frase, que suena a consultoría, tiene una traducción operativa exacta y muy poco abstracta: cambia el momento en que se toma la decisión.
El enfoque reactivo mira hacia atrás y certifica lo que ya se otorgó. El enfoque proactivo mira hacia adelante y simula el efecto de un acceso antes de otorgarlo. La diferencia no es de herramienta ni de presupuesto: es de secuencia. En el primero, el drift se descubre; en el segundo, no llega a ocurrir.
Hay un segundo ajuste, menos citado y más práctico para una utility. Xiting señala que abordar consideraciones técnicas como el diseño de roles, la metodología, la personalización del ruleset y el uso de herramientas simplifica el proceso de revisión, y que dividir las revisiones por contenido de rol mejora la eficiencia y la precisión del gobierno de accesos (Xiting, 2026). Separar la revisión de un rol de operación de campo de la de un rol de facturación permite que decida quien realmente entiende el contenido, en lugar de un jefe directo que aprueba una lista de nombres que no puede evaluar.
El acceso de emergencia ya resolvió el problema de cadencia
Vale la pena mirar el único acceso que casi ninguna utility gobierna por calendario: el de emergencia. En ese caso, un usuario autorizado recibe autorizaciones ampliadas de forma temporal mediante una cuenta Firefighter, activada únicamente durante la duración de la emergencia, con toda la actividad registrada y revisada después, y con la revocación del acceso al cierre del ciclo (Xiting, 2026). El concepto Firefighter define explícitamente el marco organizativo y técnico —solicitud, aprobación, restricción temporal, registro y revisión posterior de la sesión— para otorgar acceso privilegiado de corto plazo cumpliendo los controles internos (Xiting, 2026).
Nadie discute que ese acceso deba vencer solo. Nadie propone revisarlo en diciembre. El modelo de caducidad por diseño ya está aceptado, implementado y auditado para el caso excepcional. La propuesta de esta pieza es simple: extender esa misma lógica —acceso con vigencia, no acceso con recordatorio— al acceso ordinario que hoy vive indefinidamente hasta que alguien lo revise.
La cadencia que sí frena el drift
La revisión anual no desaparece: deja de ser el único control y pasa a ser la confirmación de un estado que ya se sostuvo durante el año. Lo que cambia es lo que ocurre entre una y otra:
- Disparar la recertificación por evento del ciclo de vida del empleado, no por fecha del calendario.
- Simular el impacto de clasificación de cada solicitud antes de aprobarla, no después del true-up.
- Asignar la revisión al dueño del contenido del rol, dividiendo los paquetes por dominio funcional.
- Tratar los accesos temporales como temporales por diseño, con vencimiento y no con recordatorio.
Por qué la cadencia termina en la línea del contrato
Todo lo anterior sería una discusión de higiene interna si el sistema midiera el uso. No lo hace: mide la asignación. SAP lo establece en su guía de medición de nube privada —la clasificación se basa en los objetos de autorización asignados a los usuarios, y por eso la clasificación manual no es el camino recomendado (SAP Support, 2026)—, y el Full Use Equivalent corresponde al número de individuos autorizados a acceder a capacidades específicas de la solución, asignados a distintos tipos de usuario con un factor de ponderación (SAP Support, 2026).
Ahí se cierra el circuito. Un analista comercial que abrió una transacción avanzada en marzo para cubrir una contingencia de facturación sigue pesando como avanzado en diciembre aunque no haya vuelto a entrar, y los factores publicados por SAP no perdonan la diferencia: un usuario de uso avanzado equivale a 1 FUE, cinco de uso core equivalen a 1 FUE, treinta de autoservicio equivalen a 1 FUE y un acceso de desarrollador consume 2 FUE (SAP Community, 2025). Hay un detalle de alcance que las utilities de la región suelen pasar por alto: solo los sistemas productivos y de desarrollo son relevantes para la medición de uso de licencia (SAP Support, 2026). El sandbox no cuenta; el ambiente de desarrollo sí — y ahí es donde quedan los consultores externos del proyecto: si conservan el tipo de usuario de acceso de desarrollador, cada uno pesa 2 FUE.
El diferencial no llega como una discusión técnica. Llega como una línea en dólares dentro de la renovación de la suscripción, sobre un presupuesto aprobado con supuestos de hace doce meses. Y aunque el análisis varía por organización, una firma de asesoría independiente en licenciamiento reporta, sobre su propio banco de entre 30 y 40 poblaciones de usuarios de nube SAP revisadas entre 2024 y 2025, reducciones del orden de 10 % a 25 % en el total ponderado de FUE al reclasificar usuarios al tipo que realmente corresponde (Redress Compliance, 2026). El punto no es la cifra: es que ese margen se pierde por cadencia, no por desconocimiento.
Una revisión al año certifica el pasado. Frenar el drift exige gobernar el presente.
En la próxima entrega vemos qué reportes muestran que un rol se está inflando antes de que el true-up lo cobre.
Fuentes
- Xiting — User Access Review (UAR) & Recertification, 2026: https://xiting.com/en/governance-risk-compliance/user-access-review-uar-recertification/
- Xiting — Emergency Access Management (EAM) in SAP, 2026: https://xiting.com/en/emergency-access-management/
- Xiting — SAP Firefighter Concept: Secure Emergency User Management, 2026: https://xiting.com/en/sap-knowledge/sap-firefighter-concept/
- SAP Support Portal — SAP Private Cloud Metering (User Types, FUE y clasificación por objetos de autorización), 2026: https://support.sap.com/en/my-support/systems-installations/glac/private-cloud-metering.html
- SAP Community — RISE with SAP Full Use Equivalent (FUE) concept, 2025: https://community.sap.com/t5/technology-blog-posts-by-sap/rise-with-sap-full-use-equivalent-fue-concept/ba-p/14054243
- SAP Community — S/4HANA Trusted Authorization Review (STAR), 2026: https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/s-4hana-trusted-authorization-review-star/ba-p/13537010
- Redress Compliance — SAP FUE Licensing: 2026 User Count Calculation, 2026: https://redresscompliance.com/sap-fue-licensing-explained-how-to-calculate-and-optimize-your-user-counts
¿Este análisis mapea un mercado donde ya operas o estás evaluando entrar?
Revisamos tu caso específico, mapeamos los riesgos que aplican, y te decimos honestamente si es oportunidad para ti —sin pitch comercial, solo discusión técnica y estratégica.
