Soffid IRC

La segregación de funciones es el principio de que ninguna persona debería controlar, ella sola, todas las fases de un proceso crítico (por ejemplo, crear un proveedor y aprobar su pago, o crear un usuario y auditar los accesos), porque eso abre la puerta al fraude o al error sin que nadie más lo detecte. No haber tenido un incidente no significa que el riesgo no exista: mientras la organización era pequeña, es probable que estos conflictos de permisos existieran igualmente pero nadie los hubiera puesto encima de la mesa. El auditor lo exige porque forma parte de marcos de control ampliamente reconocidos (SOX, ENS, ISO 27001), y su ausencia es una de las debilidades de control interno más fáciles de detectar y más citadas en informes de auditoría.

Una matriz de SoD en Excel puede documentar qué combinaciones de permisos están prohibidas, pero no detecta por sí sola cuándo una persona real acumula esa combinación de accesos en varios sistemas, porque eso exige cruzar continuamente los permisos efectivos de cada usuario contra la matriz de reglas, algo poco viable a mano más allá de un puñado de aplicaciones. Es defendible ante un auditor mientras el número de reglas, sistemas y usuarios sea pequeño y la revisión sea realmente periódica y documentada; deja de serlo en cuanto el cruce de permisos abarca varias aplicaciones y el auditor empieza a pedir evidencia de que ese cruce se ha hecho de forma sistemática, no puntual.

Un GRC genérico gestiona el riesgo a nivel de proceso de negocio y financiero-contable (controles, incidencias, cumplimiento normativo en sentido amplio), normalmente alimentado con información que alguien introduce manualmente. Una solución de riesgo de identidad como la de Soffid trabaja directamente sobre los datos reales de acceso de cada usuario en cada sistema, detectando conflictos de segregación de funciones y desviaciones de forma automática a partir de los permisos efectivamente asignados, no de un cuestionario o una carga manual de datos. Muchas organizaciones necesitan ambas, pero para el riesgo específico de "quién tiene acceso a qué y si eso genera un conflicto de control", el GRC genérico no sustituye a una plataforma que vea los permisos reales de los sistemas.

El ENS incluye medidas explícitas de la familia de control de acceso y de identificación y autenticación que se traducen directamente en capacidades de IAM: control de quién accede a qué, autenticación reforzada (obligatoria en nivel alto), trazabilidad de las acciones de cada usuario y gestión diferenciada de cuentas con privilegios. No basta con tenerlo documentado en un procedimiento: el ENS exige que esas medidas estén realmente implementadas y que se pueda demostrar con evidencia (registros, trazas, revisiones periódicas), por lo que en la práctica sí requiere herramientas de IAM/IRC capaces de generar esa evidencia, y no solo un documento de política interna.