Access requests can contribute to one or more potential SoD violations. If approval is required for potential SoD violations (as specified in the SoD policy or through a global poliscy), the access request items that contribute to the potential SoD violation will not advance to their next phase (approval or fulfillment) until each potential SoD violation they contribute to has been either resolved or approved by SoD policy owners or SoD administrators.
If a potential SoD violation requires multiple approvers (as designated by an SoD approval policy configured to use the “four-eyes” principle), the violation is not approved until all specified approvers complete their respective approval steps. An approval step must be completed before Identity Governance notifies the approvers specified in the following approval step of their approval task. If an approver does not complete their SoD approval step by the expiration interval defined in the SoD approval policy, the approval step is assigned to the escalation approvers defined in the approval step.
NOTE:Any of the step approvers may resolve the violation as their step action.
All request items that contribute to the potential SoD violation must either be approved or denied to clear the potential violation. Denying request items might cause the potential SoD violation to be resolved. A potential SoD violation is considered to be resolved if it would no longer exist after denying one or more of the request items that contribute to it. No further action is required if a potential SoD violation is resolved.
If, on the other hand, the potential SoD violation still exists, and all approval steps are complete, the potential SoD violation is considered preapproved. Identity Governance will prompt the SoD policy owner or SoD administrator to provide the following information that will be used to automatically approve the actual SoD violation if the potential SoD violation becomes an actual SoD violation:
Preapproval expiration period. If the potential SoD violation is detected as an actual SoD violation within this period, the SoD violation will be automatically approved. If the SoD violation is detected after this period, it is not automatically approved and must be resolved or approved manually by the SoD policy owner or the SoD administrator.
NOTE:The actual SoD violation could be the result of someone fulfilling these specific requests, or because of other provisioning actions that were taken by users. Regardless of the reason, if the SoD violation occurs, preapproval will be given if the SoD violation occurred in the specified preapproval time period.
Reason for SoD approval. Justification for approving a potential SoD violation.
Approval control period (days). If the preapproved violation is detected before the expiration period, the violation will be approved for the number of days specified here.
(Optional) Compensating Control. If compensating controls were specified in the SoD policy, the selection here indicates which compensating controls apply to the preapproval.
IMPORTANT:Identity Governance prevents preapproval of potential toxic SoD policy violations. For more information see Creating an SoD Approval Policy for Toxic SoD Violations.
NOTE:If an SoD policy changes its conditions, is deactivated, or is deleted, all potential SoD violation approval tasks associated with the SoD policy will be automatically finalized and submitted. Request items that were tentatively approved will be marked approved, items that were tentatively denied will be marked denied, and items where no decision was made will be marked as cleared. Items that were marked approved or cleared and were not associated with other potential SoD violation approval tasks will be advanced to their next phase (approval or fulfillment). For more information about viewing request status, see Section 22.2, Requesting Access.