EmpowerID offers different policies that help configure the type of access recertification to perform. The policy defines what information about the user's access needs to be recertified. E.g., the Group Membership policy recertifies a user's membership in the group. In contrast, the group validity policy recertifies the group's existence itself.
EmpowerID generates business request items or tasks for each access to recertify the access and routes these requests to the auditors. The Items are grouped or bundled into a Business Request to simplify the recertification process and enable auditors to review and approve multiple access recertification items at once. Based on the type of policy, the bundling is done based on Object, Responsible party, and Fallback Assigne attributes.
The table below explains the various types of policies and the logic of grouping business request items into a single request.
Key Information
The Responsible party and Fallback Assigne are important persons in access recertification. A responsible party is a person who is responsible for managing and maintaining IT resources. Responsible parties are special assignments that can reported on and used during the termination/leaver process to maintain and transfer governance oversight and be included in compliance and recertification policies. The responsible party can be configured according to the instructions provided here. On the other hand, the Fallback Group By Assignee is specified when an audit is created and serves as the default assignee for recertification requests for that specific audit.
Type | Purpose | Business Requests & Decesions |
|---|---|---|
Account Validity | The account Validity recertification policy collects and presents information to recertify the accounts owned by the users. Auditors can then review this information and determine whether a user's account is still necessary and should be certified. This process helps organizations ensure that only valid accounts exist as per compliance. | Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each item or account. In cases where an account has no responsible party assigned, the engine attempts to set the Account's Manager as the Responsible Party and groups the recertification items based on it. Lastly, the fallback is grouping the business items by Fallback Group By Assignee. When an account has neither Responsible Party nor the Manager, the engine groups the accounts into business requests based on the Fallback Group By Assigne The possible decisions for the business requests generated during the recertification process are certify, disable, or delete. |
Business Role and Location Membership | The purpose of the Business Role and Location Membership Recertification policy is to certify users' access or membership to a business role and location. Auditors review the membership information and determine whether a person's membership is still necessary and should be certified. This policy helps organizations ensure that only valid persons are members of the particular Business Role and Location.
| For the Business Role and Location Membership policy, the engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the business role and location are the bundles for the business requests, and its members are items. |
Direct Reports | The Direct Reports recertification policy collects and presents information to recertify the managers and their direct reports. Auditors can then review the information about who reports to whom and if it should be certified. This process helps organizations ensure that each user reports to the right person as per compliance. | For the Business Role and Location Membership policy, the engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the managers are the bundles for the business requests, and the users reporting to the managers are items. |
Group Membership | The purpose of the Group Membership policy is to certify users' membership in a group. Auditors review the membership information and determine whether a person's membership is still necessary and should be certified. This policy helps organizations ensure that only valid persons are members of the Group. | The engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the group is the business requests, and its members are items bundled into the request. The possible decisions are generally set to certify or revoke the group membership. |
Group Owner | The Group Owner policy collects and presents access information to recertify whether an account as a group owner is still required. Auditors review the information and certify whether an account should own a group. This policy type allows recertification of the inventoried native owners for groups as assigned in their external systems (e.g., Azure Teams owners). | For the Group Owner policy, the engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the group owner is the bundle for the business requests, and the groups the owner owns are the items. |
Group Validity | The purpose of Group Validity is to determine whether a group is still required. Auditors review the membership information and determine whether the group existence is valid in terms of compliance and should be certified. This policy helps organizations ensure that only valid Groups continue to exist.
| Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each group. In cases where a Group has no responsible party assigned, the engine groups the items by Fallback Group By Assignee. Possible decisions for the auditors during the recertification process for Group validity are to certify, disable, or delete. |
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 required. Auditors review the information and certify whether people's access to resources by their assignment to the Management Role complies with organization policies. This policy type allows recertification of the inventoried native owners for groups as assigned in their external systems (e.g., Azure Teams owners). | For the Management Role Access Assignment policy, the engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the management role is the bundle for the business requests, and the resource roles are the items.
|
Management Role Membership | The purpose of the Management Role Membership policy is to certify users' membership in a Management Role. Auditors review the membership information and determine whether a person's membership is still necessary to be in the management role and should be certified. This policy helps organizations ensure that only valid persons are members of the Group. | The engine bundles the recertification items into business requests based on the object itself. Therefore in this case the management role is the bundle for the business requests and its members are items. The possible decisions are generally set to certify or revoke the management role membership. |
Management Role Validity | The Management Role Validity policy collects and presents information to recertify whether a management role is still required. Auditors review the information and certify whether the management role should exist as per compliance.
| Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each management role. In cases where the management role has no responsible party assigned, the engine groups the management role items by Fallback Group By Assignee. Possible decisions for the auditors during the recertification process are certify, disable or delete. |
Person Access Summary | The purpose of the Person Access Summary is to recertify the Person with all types of access assignments currently granted to that Person. Auditors review the Person's access, the level of access granted, and any special privileges or permissions they may have and certify it. This policy helps organizations ensure that the persons only have the required permission. The person access summary recertifies
| For the Management Role Access Assignment policy, the engine bundles the recertification items into business requests based on the object itself. Therefore, in this case, the Person is the bundle for the business requests; each access the user has are the business request item.
|
Person Validity | The Person Validity policy collects and presents information to recertify whether a Person object in EmpowerID is still required. Auditors review the information, certify whether the person should exist, and access IT resources as per compliance.
| Recertification engine groups recertification items into a business request based on the Responsible Party assigned to each item or person. In cases where 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 based on it. Lastly, the fallback is grouping the business items by Fallback Group By Assignee. When a Person has neither Responsible Party nor the Manager, the engine groups the person objects into business requests based on the Fallback Group By Assigne The possible decisions for the business requests are generally set as certify, disable, or delete. |