EmpowerID offers several types of Recertification policies for configuring the specific access recertification requirements for users. These policies determine the type of access information that needs to be reviewed and validated for each user. For example, the Group Membership policy focuses on recertifying a user's group membership, while the Group Validity policy verifies the ongoing validity of a group.
The table below explains the various types of policies and the logic of grouping business request items into a single request.
Key Information
In access recertification, the responsible party and fallback assignee are crucial roles. The responsible party is responsible for managing and maintaining IT resources. This role can be reported on and used during the termination/leaver process to maintain and transfer governance oversight. It can also be included in compliance and recertification policies. You can configure the responsible party by following the instructions provided here. The fallback assignee is specified when an audit is created and serves as the default assignee for recertification requests for that specific audit.
If the default decisions provided by EmpowerID are not enough, you can configure additional decisions. For more information on this, refer to the Configure Custom Decision for Business Requests topic.
Type | Purpose | Business Requests and Decesions |
|---|---|---|
Account Validity | The Account Validity Recertification policy is designed to collect and present information about the accounts owned by users, making it easier for auditors to review and determine which accounts are still necessary and should be certified. This policy is crucial in ensuring that only valid accounts exist in an organization in compliance with regulatory requirements. By using the Account Validity recertification policy, organizations can verify that user accounts are still required and actively being used. This helps in the elimination of redundant or outdated accounts, which could pose a security risk. | The recertification engine groups recertification items into a business request based on the Responsible Party assigned to each account or item. If no Responsible Party is assigned to an account, the engine will attempt to set the account's manager as the Responsible Party and group the recertification items accordingly. In cases where an account does not have a Responsible Party or a manager, the engine groups the accounts into business requests based on the Fallback Group By Assignee. During the recertification process, auditors have the option to make decisions such as certifying, disabling, or deleting the business requests generated by the engine. |
Business Role and Location Membership | The Business Role and Location Membership Recertification policy serves to certify a user's access or membership to a specific Business Role and Location. Auditors review the membership information provided by this policy to determine whether a person's membership is still necessary and should be certified. By doing so, this policy helps organizations ensure that only valid individuals are members of the relevant Business Role and Location. By using the Business Role and Location Membership Recertification policy, organizations can verify that individuals continue to require access to specific Business Roles and Locations. This helps in eliminating access to those who no longer require it, reducing the risk of unauthorized access. | In the Business Role and Location Membership policy, the recertification engine groups recertification items into business requests based on the target Business Role and Location. These objects serve as the bundles for the requests, with the members of the Business Role and Location being the items that require recertification. Possible decisions for the auditors during the recertification process for business roles and location memberships are to either certify or revoke them. |
Direct Reports | The Direct Reports Recertification policy is designed to collect and present information about managers and their direct reports, making it easier for auditors to review and determine if the reporting structure is correct and should be certified. This policy is crucial in ensuring that each user reports to the appropriate person in compliance with regulatory requirements. | In the Business Role and Location Membership policy, the recertification engine bundles the recertification items into business requests based on the object itself. This means that in this policy, the managers serve as the bundles for the business requests, and the users reporting to the managers are the individual items that require recertification. |
Group Membership | The Group Membership policy is intended to certify a user's membership in a specific group. Auditors review the membership information provided by this policy to determine whether a person's membership is still necessary and should be certified. By doing so, this policy helps organizations ensure that only valid individuals are members of the group. | In the Group Membership policy, the recertification engine bundles the recertification items into business requests based on the object itself. This means that in this policy, the group itself serves as the business request, while its members are the items that are bundled into the request. During the recertification process, auditors typically have the option to make decisions such as certify or revoke the group membership. |
Group Owner | The Group Owner policy collects and presents access information to recertify whether an account should continue to serve as a group owner. Auditors review the information provided by this policy to determine whether an account should continue to own a group. This policy type allows for the recertification of the native owners for groups as assigned in external systems, such as Azure Teams owners. | In the Group Owner policy, the recertification engine bundles the recertification items into business requests based on the object itself. As a result, in this policy, the group owner serves as the bundle for the business requests, with the groups owned by the group owner being the individual items that require recertification. |
Group Validity | The Group Validity policy serves to determine whether a group is still necessary and should continue to exist. Auditors review the membership information provided by this policy to determine whether the group's existence is valid in terms of compliance and should be certified. This policy is crucial in ensuring that only valid groups continue to exist in the organization.
| The recertification engine groups recertification items into a business request based on the Responsible Party assigned to each group in the Group Validity policy. If a group has no Responsible Party assigned, the engine groups the items by Fallback Group By Assignee. During the recertification process for Group Validity, auditors can make decisions such as certify, disable, or delete the group. |
Management Role Access Assignment | The Management Role Access Assignment policy collects and presents access information to recertify whether the current Resource Roles assigned to a Management Role are still necessary. Auditors review the information provided by this policy to determine whether people's access to resources by their assignment to the Management Role complies with organization policies. | In the Management Role Access Assignment policy, the recertification engine groups recertification items into business requests based on the object itself, which means that the Management Role is used as the bundle for the business requests. Within each bundle, the Resource Roles assigned to the Management Role are the individual items that require recertification.
|
Management Role Membership | The Management Role Membership policy serves to certify a user's membership in a specific Management Role. Auditors review the membership information provided by this policy to determine whether a person's membership is still necessary and should be certified. This policy is crucial in ensuring that only valid individuals are members of the Management Role. By using the Management Role Membership policy, organizations can verify that individuals continue to require membership in the specific Management Role. This helps in eliminating membership to those who no longer require it, reducing the risk of unauthorized access. | In the case of the Management Role Membership policy, the recertification engine bundles the recertification items into business requests based on the object itself. Therefore, in this policy, the Management Role is the bundle for the business requests, and its members are the items. Possible decisions for auditors during the recertification process are typically set to certify or revoke the management role membership. |
Management Role Validity | The Management Role Validity policy is designed to collect and present information about a Management Role to determine whether it is still necessary and should continue to exist. Auditors review the information provided by this policy to determine whether the Management Role's existence is valid in terms of compliance and should be certified. By using the Management Role Validity policy, organizations can verify that only necessary Management Roles continue to exist, reducing the risk of outdated or redundant Management Roles.
| The Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each management role. If the management role has no responsible party assigned, the engine groups the management role items by Fallback Group By Assignee. During the recertification process, auditors have the option to make decisions such as certify, disable, or delete for the recertification items. |
Person Access Summary | The Person Access Summary policy is designed to recertify a person's access to all access assignments currently granted to them. Auditors review the person's access, level of access, and any special privileges or permissions they may have and certify it. This policy helps organizations ensure that individuals only have the necessary permissions. The policy recertifies:
| In the case of the Management Role Access Assignment policy, the recertification engine bundles the recertification items into business requests based on the object itself. Therefore, in this policy, the Person is the business request bundle, and each access assignment the user has is the business request item. Possible decisions for business requests are typically set as certify, disable, or delete. |
Person Validity | The Person Validity policy is designed to collect and present information about a person object in EmpowerID to determine whether it is still necessary and should continue to exist. Auditors review the information provided by this policy to determine whether the person's existence is valid in terms of compliance and should be certified. Additionally, the policy helps ensure that the person has appropriate access to IT resources. By using the Person Validity policy, organizations can verify that only necessary persons continue to exist in EmpowerID. | The Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each item or person. If a person has no Responsible Party assigned, the engine attempts to set the person's Manager as the Responsible Party and groups the recertification items accordingly. In cases where neither Responsible Party nor Manager is assigned, the engine groups the person objects into business requests based on the Fallback Assignee. Possible decisions for business requests are typically set as certify, disable, or delete. |
EmpowerID offers a real-time risk-based recertification feature that enables monitoring of group membership changes as they occur. This feature can be enabled on a per Account Store basis and is designed to monitor only those groups that are defined in a Query-Based Collection per Account Store.
For more detailed information on this feature, please see Continuous Group Membership Change Recertifications.