Control policy
Control policies allow Omada Identity data administrators to detect and rectify possible problems with master data and access rights that may have an impact on the correct functioning of processes.
Control policies define a negative control data set, i.e., the set containing undesired data. This data set can either defined as a set of data objects or as an SQL query that can be mapped to data objects. If a control data set is defined with an SQL query, the query result must be mappable to data objects.
If a control policy detects a data problem, a survey is created and assigned to an admin in order to remedy the problem.
There are three modes Control Policies can work in:
- Preventive
- Detective
- Corrective
It is possible to define more than one mode for a given policy. The following combinations are possible:
- Detective
- Preventive
- Detective + Preventive
- Detective + Corrective
- Detective + Preventive + Corrective
Preventive policies
When a data object is saved, and a Control Policy is triggered, the system evaluates if this object violates a control policy that has the Preventive mode. If it does, an error is shown, and the object is not saved. No exception data objects are created, as the change is prevented from happening.
Detective
When a detective policy is evaluated (either ad-hoc or via a schedule) and a violation is detected, an exception data object is created, and the survey for managing exceptions is launched (if a survey instance already exists, the new exception object is added to the running survey).
If the policy is also corrective, then the corrective action is executed on the data object, that is in violation.
Detective policies must have a schedule defined; the schedule refers to a Timer object which determines when the policy should be evaluated.
For the detective policies, the data set type is possible to be either a Data object query or an SQL query. In contrast to policies based on Data object which require an SQL Data set view based policies require a Data set data source defined.
Corrective
A corrective action is always also a detective one. If a control policy has the Corrective mode, then it must refer a copy rule object in the Corrective Action property. The copy rule must have the same source-object and the destination-object type, and that object type must be the one selected for the policy.
The intention is to use corrective actions to fix simple data issues such as systems not having an owner or identities having a manager which is inactive.
The changes made by the corrective action are added to the discussion-log field of the control policy's exception data object.
If the violation is solved after the performed changes, the status on the exception data object is automatically set to solved. The solution of the violation is determined by re-evaluating the policy. The solved status is also added to the discussion-log field, that is, Automatically solved due to corrective action.
Corrective actions are not executed as part of the evaluation of a preventive policy. It is because the problem in that case is avoided (has been prevented).
Policy exceptions
As Control policies detect problems with master data and access rights, any such detected problems are called Policy exceptions. You can find Policy exceptions under Setup > Operations > Policy Exceptions.
The Policy Exceptions screen presents the list of all detected exceptions, regardless of the exception status. The ellipsis menu (...) for each of the exception allows you to edit this exception by changing the Status or the Compensating control, as well as, add comments to the exception.
Please remember that the Policy Exception screen does not serve to resolve any exceptions. Exceptions to any policies can be resolved from My data > My tasks screen section of the Omada Identity interface.