Segregation of Duties (SoD)

Segregation of Duties (SoD) is a security principle. It ensures that no single person can perform two conflicting tasks within the same process. This reduces risks such as fraud, human error, and lack of control.

To enforce SoD in practice, Memority helps you prevent risky access combinations. For example:

• A user doesn’t have both a data entry role and a validation role in a sensitive process like payroll or purchasing.

• A user doesn’t have access to two applications that are marked as incompatible.

• A user doesn’t hold roles from two different role categories, such as “System Admin” and “Internal Audit”.

Memority gives you a powerful SoD cockpit to help you define, detect, and manage risks:

• You can create SoD rules based on different policy types: roles, applications, role dimensions (like region or department), or role and application categories.

• You can configure a SoD mode to Forbid or Warn depending on your security need

• The system checks SoD violations in real time, during both the role search and final validation steps of an access request.

• You can manage exceptions, set up automated recertifications, and run periodic controls to review or fix existing violations.

• You can delegate rule management to application owners while keeping full visibility through scoped reports.

• You can also link SoD violations to compensating controls to track mitigation efforts over time.

SoD rules modeling

In Memority, SoD rules are based on a SoD policy. That policy lets you define which conflicts to detect and the attributes the system must use.

You can create rules to define which:

• Roles are incompatible.

• Applications are incompatible.

• Application or role categories are incompatible.

• Role dimensions are incompatible, such as region, department, or project.

You can build a flexible SoD model using policies and role templates. This model gives functional administrators a structured way to create and manage SoD rules in the cockpit.

For each rule, you can:

• Customize the rule model with additional information to match your needs (category, criticality, responsible…).

• Define an enforcement mode:

• Define a scope to apply the rule only in specific parts of the organization.

• Classify rules according to your business needs (importance, scope, impact). The classification allows to sort and filter rules but also to create dedicated reports.

• Manage its lifecycle (activate, deactivate, or suspend a SoD rule).

Super Roles

Given a SoD rule defined between roleA and roleB, and two super-roles — superRoleA (which includes roleA) and superRoleB (which includes roleB) — three conflict scenarios may occur:

• Assigning superRoleA together with superRoleB creates a SoD conflict.

• Assigning superRoleA together with roleB creates a SoD conflict.

• Assigning roleA together with superRoleB creates a SoD conflict.

When resolving such conflicts, it is not possible to deselect the implied roles (roleA or roleB) since they are inherited from their respective super-roles. However, it is possible to deselect the super-role itself in order to resolve the conflict.

Delegate rule management

Only authorized end-users, usually the security or access governance team, can create SoD rules.

However, the SoD rule matrix allows to delegate rule management to scale access control without losing visibility.

Delegated administrators, like application owners or group security managers, can:

• Create and manage SoD rules only for their assigned applications or business areas.

• View violation reports limited to their scope.

Assign and request roles

Memority lets users assign or request one or more roles with a form.

The system checks for conflicts with the user’s current roles. The rules may also depend on where or how the role applies (for example, two roles may be allowed separately, but not in the same location).

Based on the rule mode, the system may block the request or show a warning and notify users about the conflicts with visual information and explanatory messages.

Conflict	Icon	Description
Major conflict		Users can’t select the role (FORBID mode). A message describes the rule and role that conflict with the requested role.
Minor conflict		User can select the role (WARN mode). A message describes the rule and role that conflict with the requested role.

Users can request several roles at once using the shopping cart mode. Hence, the real-time evaluation checks for conflicts:

• With the roles users already have.

• Among roles requested in the cart.

When the system detects conflicts, it shows an additional step to users to help them manage these conflicts before final submission.

If there are major conflicts, the system blocks the request and shows a message explaining the conflicts.

If there are minor conflicts, the system shows a message explaining the conflicts. Users can choose to remove conflicting roles before submitting their request or proceed despite the warning.

SoD and Workflows

If the role request needs workflow approval:

• The approver sees all conflicts.

• The approver can adjust the role’s dimension (for example, changing the organization or location).

• Real-time evaluation takes additional information into account to help the approver validate or reject the request based on the new context.

Monitor and Remediate SoD violations

Memority helps you track SoD violations and manage them over time.

You can access detailed violation reports in real time or export them to CSV or XLS files when needed.

Reports show:

• Who is involved in the violation.

• Which roles or applications caused the violation.

• The violation enforcement mode: SIMULATE, FORBID or WARN.

• When the violation happened (the violation start date).

Reports can be global or focused on specific criteria like rule type, criticality, application, organization, role, or business unit.

What’s more, if you delegate rule management, you can limit report data to each admin’s scope

For example:

• An application manager sees violations related to their roles.

• A domain manager sees violations related to the identities in their scope.

The system runs automated checks in real time to detect violations, and updates the reports. When administrators create or update SoD rules, the system scans all existing access to detect new violations.

These reports are the starting point for managing SoD risks over time. Functional administrators can:

• Start a certification for a specific access directly from the report.

• Configure automatic recertifications based on rule criteria, like criticality or scope.

This helps your company monitor violations, take action, and prove that SoD risks are under control.

If a violation is necessary for business reasons, the system helps you manage the associated risk with compensating controls. Hence, you can:

• Link a user-risk ID to connect each violation with its control.

• Schedule periodic recertifications of these mitigated risks.

• Access updated reports that show new or resolved violations.

This ensures that accepted violations remain visible, documented, and regularly reviewed.

Benefits of SoD

• Prevent conflicts of interest by making sure that users don’t get conflicting roles.

• Reduce risk linked to human error or incorrect access.

• Simplify audits with clear reports of SoD violations.

• Give users and approvers real-time alerts about conflicting role requests.

• Test new rules before enforcing them.