Identity Lifecycle Management

A key part of securing an organization’s infrastructure is to ensure that user identities are properly created, changed, and disabled when employees join the company, move departments, get promoted, and leave the company. Identity lifecycle management processes enable the granting of access rights according to
defined roles, rules and policies to ensure employees have the right access levels at any given point in time.

The task of ensuring the right user access may sound simple, but as illustrated in the figure below, this easily gets complex quickly. The figure shows the lifecycle of an individual who joined the company as a contractor, became an employee, moved to another department, got promoted, left on maternity leave, and eventually retired. At each stage of the person’s employment, the job role requires access to different resources within the company.

Why Identity Lifecycle Management is important

As part of Omada IdentityPROCESS+, an identity governance framework focusing on best practice processes, there are several key components to Identity Lifecycle Management. These are critical to follow best practices, to ensure that business efficiency is optimized, security is tight, and compliance is met.

Managing the Identity Lifecycle

Identity Lifecycle Management processes include all the processes associated with the entire employment of an individual. Automated processes ensure that when joining a company, employees have access to all the systems, applications and file systems required to do their job, so they can be productive from day one.

As employees change job roles or get promoted, their access to existing systems may increase in line with the responsibilities of the new role. Likewise, a change to a different department, may require different access to systems or access to new systems. Finally, it may also be necessary, and is certainly a best practice, to remove any access to systems that the employee used in their previous job role, but is no longer required in the new role, so access rights do not accumulate over time. Failure to remove access systematically may result in violations of security regulations and compliance policies such as segregation of duty. This off-boarding of access rights is also handled by the Identity Lifecycle Management process area.

Extend security defenses

Handling on-boarding, changes, and off-boarding processes not only ensures that an employee can fulfill their job role, it also has the benefit that if a user account is compromised, an intruder will only have limited access to systems. The security boundary that these processes create is seen as adding further security to traditional security defenses such as firewalls and intrusion prevention systems and is referred to as the “identity perimeter”.

Identity lifecycle management not only focuses on employees as the actual environment is often more complex because companies typically also need to manage third parties such as contractors, seasonal workers, or business partners, who need access to company resources to work effectively with the company. If this complete lifecycle was to be managed manually, it would take a significant amount of IT resources to provision and de-provision individual accounts. Manual processing is also prone to human error which could leave the company exposed to unnecessary security and compliance risks. Instead, IdentityPROCESS+ automates the set of processes that manage all aspects of identity lifecycle management which are listed below.

The processes under the Identity Lifecycle Management process area are known as the joiner-mover-leaver processes. This is because the process area enables organizations to on-board, change, and off-board identities belonging to employees or contractors.

Common to all the processes, is that triggering any of them results in identities being updated in accordance with security levels, business policies, job role, organizational hierarchy, and context.

The full Identity Lifecycle Management process area includes the following process groups with subordinate processes:

1. Onboard identity (Process group)
   • Onboard employee (subordinate process)
   • Onboard contractor
   • Onboard technical identity
2. Change identity
   • Intra-organizational transfer process
   • Master data change process
3. Off-board identity
   • Termination

Onboard Identity

Automates the creation of identities for employees and contractors when they join the company and allows technical identities to be created to manage business systems.

Onboard Employee

The process ensures that the new employee is productive from day one with correct access to required systems for them to do their jobs.

Process description. The onboard identity process generates a new identity automatically when a new employee record is created in the master HR system. The identity will be assigned pre-defined access rights which will not only give access to the resources that all employees are granted initially, such as Active Directory, email, relevant shared drives, and the company benefits system, but will also allow specialist applications, such as the purchasing application or developer tools, to be used based on role or context.

Best practice IGA system functionality. The new identity is made up of a unique user name and is imported and processed in the IGA system automatically. An approval task for the person in charge of the new identity such as the manager or administrator is created so they can confirm and approve the onboarding. The identity is set to inactive in the system until the ‘Valid from Date’. The identity is automatically set to active when the Valid from Date is reached.

Technical process flow:

1. When onboarding a new employee, HR creates an identity record in an authoritative source, for example, an HR-management system.
2. The identity record is automatically imported into the IGA system.
3. The workflow steps are executed automatically.
4. The IGA system reads the identity record and processes it according to predefined assignment policies.

Onboard Contractor

Contractors and other temporary workers are an important part of business operations. Managing their identities has the same benefit as for fulltime employees – getting them working from day one with access to the right systems and resources.

Process description. The process is similar to the onboard employee process described previously. The manager responsible for the contractor creates a new identity and specifies which systems and resources the contractor should have access to. An important part of this process that is different than for managing permanent employees is to indicate the start and end date for the contractor to ensure that the identity only has access to relevant data during the contract period. Once approved, the contractor will have access to relevant data during their contract with the company.

Best practice IGA system functionality. The onboard contractor process is started manually by department managers when a new contractor is hired. The identity can also be created in the HR system if contractors are managed here. Otherwise, the identity can be created directly in the IGA system. The IGA
system automatically detects if an identity with similar master data already exists due to a contractor having previously worked with the company. If a similar identity already exists, the manager is given the opportunity to either create a new identity or update the existing one. If start and end dates are specified, the IGA system automatically activates and terminates access on the appropriate dates. During the identity’s active period, the contractor can request additional access rights directly in the IGA system which would be subject to approval by the manager.

Technical process flow:

1. A user with suitable rights manually triggers the onboard contractor process by filling out an online form with the contractor’s personal data
2. The user submits the form and the IGA system checks for conflicts or duplicates
3. If an identity with similar master data, such as name or email address, exists, the user has the option to create a new identity, update an existing identity, or terminate the process
4. The request is submitted for approval

Onboard Technical Identity

To eliminate the need to grant members of the IT team administrator access to systems from their personal identities, technical identities are used. As technical identities have privileged access rights and are used by several IT users, they need to be assigned an ultimate owner who is responsible for the governance of the account.

Process description. To ensure that these powerful technical identities are managed properly, the onboard technical identity process allows system owners to create the account and assign its responsibility to an actual user referred to as the primary identity. This assignment ensures that tight governance is maintained as the primary identity is responsible for the resource even though many other users may access the system and use the same account.

Best practice IGA system functionality. The system owner completes a technical request form in the IGA system which then creates the technical identity default properties. The technical identity is then mapped to an owner (the primary identity) who has the responsibility for the account. Once this mapping is complete, the technical identity is ready, and users can request access to use the technical identity to access the system for administration purposes.

Technical process flow:

1. The system owner requests new technical identities for their systems using the request technical identity form
2. The technical identity is created, and the default properties are assigned
3. The technical identity is mapped to the owner (the primary identity)
4. The technical identity is ready for users to request access

Change Identity

Manages the access rights of employees and contractors as they change jobs or departments within a company and manages changes to employee personal data.

Intra-Organizational Transfer

When an employee or contractor moves within an organization, such as when they change department or are promoted, their user access rights need to be reviewed and updated to ensure the employee only has access to the appropriate systems. This safeguards against certain combinations of access rights that are prohibited by business policies, such as segregation of duties, being granted during the change.

Process description. When an employee or contractor moves from one organizational unit to another or is promoted within their department, the intra-organizational transfer process revokes the access rights for the old role and adds assignments for their new role. Once this change occurs, it is approved by the individual’s manager who can remove any direct resource assignments if necessary.

Best practice IGA system functionality. The process is initiated when an employee transfer or promotion is entered into the HR-system (the authoritative source). This event triggers the IGA system to clarify which new rules should be added or removed to an employee’s account. Once this is complete, the account is ready for approval or further modification by the department manager. The manager has the option to add or remove access according to the job role. Access rights are automatically provisioned and de-provisioned in the systems. By default, removed access rights are maintained for a predefined number of days enabling the user to access and hand over work assignments.

Technical process flow:

1. A job role change is entered in the HR-system / authoritative source
2. New access rights according to rules and policies for the new job role are automatically applied to the employee’s account
3. The manager receives a notification to modify access rights to the employee’s account
4. After manager approval new access rights are applied to the employee’s account
5. After a pre-defined number of days, the user loses all access rights not recertified by the new manager

Master Data Change

Master data is stored in a central repository which is sourced from one or more systems. Gathering, updating, and managing master data across systems can be a difficult task. It is important to maintain good master data governance by ensuring that data changes are reviewed by managers and that changes are made in all systems.

Process description. The master data change process streamlines the requested changes, updates, and additions to an organization’s master data and ensures that the change is copied to systems connected to the IGA system.

Best practice IGA system functionality. Users can change their data records through a data update request, which must be approved by the identity’s manager. When the IGA system detects a change in master data records, the change process is initiated to gather the modified data and update it in the IGA solution according to predefined data-mapping rules. Any modification to an identity’s master data is then automatically propagated to connected systems based on previously defined provisioning rules.

Technical process flow:

1. An employee makes changes to his/her personal data
2. The change triggers an event to the manager who is responsible for the specific employee’s data change
3. The manager rejects or approves the change request before it is executed in systems and sub-systems

Off-Board Identity

Manages the off-boarding of employees when they resign or are dismissed so that they no longer have access to business systems once they leave the company.

Termination

Organizations need to ensure that employees and contractors do not have access to systems after they have left the company on a temporarily or permanent basis.

Process description. The termination process covers both the immediate off-boarding of an employee or contractor, as well as planned permanent off-boarding which is implemented when a user has resigned and needs access to systems during their notice period. The process automates the terminating of access rights or disables applications in the systems ensuring these are properly de-provisioned and the user cannot access data after they have left the organization.

Best practice IGA system functionality. The process is triggered when:

1. The valid to date in the identity record of the HR system or your IGA solution has been reached. That happens for example to contractors who have pre-defined end-dates
2. The identity record is no longer delivered by the source system. This happens if the data record is deleted after an employee has left the company

In either scenario and when the process is voluntarily or involuntarily triggered, the identity is terminated, all its accounts are disabled, and access revoked.

Once an account is deleted, the transfer ownership process begins to start moving the responsibility for resources owned by the deleted account to other users.

Technical process flow:

1. The valid to date or value in the identity record of the HR system or the IGA solution is reached, or a missing data set triggers the process in the IGA solution
2. Identity status is set to Terminated
3. The identity is terminated, all associated accounts are disabled, and access is revoked
4. The transfer ownership process is triggered by the IGA system to ensure that all resources previously owned by the terminated identity are re-allocated

Process Stakeholders

As the definition and implementation of the identity lifecycle management process involves many different departments, it is important to ensure that the relevant stakeholders are included and informed of their duties early in the project. Communication of these expectations will ensure that all parts of the process are covered which will result in the smooth implementation of the identity lifecycle management processes. The table below shows a list of the key stakeholders in the Identity Lifecycle Management process area along with their involvement, responsibilities and tasks they are expected to perform pre- and post-implementation.

1. Human Resources (HR)
   • HR is involved at the start of the project and is continuously involved throughout the entire IGA project. HR’s work touches all aspects of identity lifecycle management as HR data is key to the operation of all processes.
2. IGA Team
   • The IGA team starts working with HR early in an IGA project as they must ensure the data integrity in the authoritative source (the HR system) before it is uploaded into the IGA system. The IGA team has no direct involvement in the identity lifecycle management processes.
3. Line Managers
   • Line managers’ involvement starts once the HR data has been loaded into the IGA system. Regarding identity lifecycle management, they are involved in approving onboarding of employees, contractors, intra-organizational transfers, master data changes, and termination of user identities.
4. End Users
   • Once the IGA system has been implemented, end users can be involved in any of the identity lifecycle management processes. In some cases (onboard employee, onboard contractor, intraorganizational transfer, and termination), they are indirectly involved as their manager interacts with a process on their behalf while in others (master data change), they interact with the process directly.
5. Business System Owners
   • Once the HR data has been loaded into the IGA system, business system owners start working with the IGA team to onboard business systems into the IGA system. Regarding entity lifecycle management, Business System Owners create technical identities for the systems they are responsible for using the onboard technical identity process.

Key Best Practice Recommendations

Below are a set of key best practice recommendations that should be taken into consideration when implementing the identity lifecycle management processes in IdentityPROCESS+.

Data Management

Define data quality

As employee and contractor data is critical to the success of an IGA project, rules governing data quality must be defined. This includes identifying the interfaces to the business systems and how the data transfers between them and the IGA system are to be optimized for quality.

Determine the master data sources for personnel records

Every IGA system relies on personnel records to implement the processes in the IdentityPROCESS+ framework such as assigning access rights to an identified role or routing access requests to an employee’s manager for approval. To ensure that these processes run effectively, it is important that the right data is imported into the IGA system.

However, this situation may be complicated due to there being many different sources of personnel records. The data required could be:

1. Stored in multiple, independent systems across the organization, or
2. Duplicated across different systems in the network

If employee data is held in multiple, independent systems then connectors need to be used to transfer data between each system with the IGA system. However, if data is duplicated – either because some is held in the HR system with some being stored within Active Directory, or because a redundant system has been set up to improve system performance – then the organization needs to decide which source should provide the master data for attributes.

This decision then needs to be implemented in the IGA system, so that each piece of information comes from one defined source. For complex environments, this could result in a lot of logic being required.

This decision is one of the first considerations for an organization looking to deploy an IGA solution as without clean data, the IGA system cannot function
properly. In addition, as the sources of employee and contractor data can be very complex, the definitions of the master data sources need to be done by the organization itself as this cannot be carried out solely by an IGA vendor or thirdparty integrator. However, IGA vendors will work with the organization to ensure that the data meets the necessary requirements.

Load master data before implementing processes

All the master data should be loaded into the IGA system before work is started on implementing any processes. If this is not done, processes like recertification will have to be carried out after each data load which wastes time and resources.

Determine the frequency of data imports from authoritative sources

HR system data changes frequently due to employees joining the company, getting promoted, or leaving. As a result, data needs to be regularly imported from the HR database (or other authoritative source) into the IGA system. The import frequency depends on business requirements. Typically, once per day is adequate for most organizations. However, for organizations where employees need to be onboarded the same day, it may be necessary to import data every two to four hours.

Identities

Ensure that rules are in place to create unique identities

It is critical that all identities in the IGA system are unique. If no identity naming policy is in place, then it is necessary to create one. Also, it is a good idea to have the naming policy explicitly written down for the entire organization.

Do not tie user IDs to identity data

This ensures a seamless change in the event of, for example, a user changing their name as there is no need to change the actual identity.

Do not reuse user IDs for returning employees or contractors

If an individual leaves the company and rejoins later, it is recommended that a different user ID is created regardless of whether it is an employee or contractor. By doing so, the organization can be confident that there is a separation in logs and historical records showing the requests and changes of access rights. The new user ID makes it easier to analyze the different employment periods during company audits.

Governance and Standards

Consider optimizing business processes to reduce complexity

The current business processes, if any, need to be assessed. If they are not fixed due to a regulatory framework that must be adhered to, it is recommended that the organization consider the possibilities of refreshing outdated processes and reducing any complexity. It should be noted that if there are different processes across the organization, such as one process for bank traders not being the same as for other employees, standardization will be difficult. In these cases, process optimization must be considered.

Review processes

The implementation of an IGA solution is a good time to review processes across the organization to ensure that they are all appropriate to support the business going forward.

It is often possible to significantly reduce complexity and increase overall efficiency by removing outdated processes as well as automating others. An example of this might be that in the past, managers had to request access to systems on behalf of their direct reports as this was the only way to work in their old IGA system. With the introduction of self-service capabilities, employees can request their own access to business systems which reduces the manager’s workload.

Ensure documented standards are compliant with current and expected future legislation requirements

Having documented standards is important from a compliance perspective and helps prove to auditors that the organization understands regulatory requirements. As part of the analysis of the existing standards in the organization, it is recommended to include analysis of future compliance requirements to prevent additional work whenever new legislation comes into force.

Business Recommendations

Involving business managers early in the project

Many decisions associated with defining the parameters for identity lifecycle management need input from individuals who understand the business requirements. These requirements could include legal and compliance needs to ensure, for example, that data is kept for a given period, as well as individual requirements for different countries and industries. It is therefore recommended that stakeholders from across the organization are brought into an IGA project early so that business requirements can be built into the processes at an early stage instead of trying to retrofit them after the deployment.

Manage contractors to ensure compliance

To ensure good governance, organizations should ensure that a legal contract is completed before onboarding a contractor into the IGA system. Having a contract in place helps ensure that the contractor will abide by the rules and regulations of the company and will satisfy audit requirements. It is also recommended that access rights for contractors are limited to a finite time such as 3 or 6 months. This is particularly relevant if the organization is governed by strict regulations. Failure to do so could result in user access being forgotten and an ex-contractor having access to business systems long after they have left. Time limitations of how long access should be valid must be defined – preferably by HR.

Maintain a written IGA policy

Many areas of running the identity lifecycle management processes involve making decisions that are outside of the IGA system. These include determining how long contractors should be granted access to business systems before their access needs to be recertified, the use of non-personal technical identities, and grace periods when access is transferred from one employee to another. To prevent ad hoc decisions on policy from being made which could result in governance violations, it is recommended that a formal written policy is put in place. Without a written policy, the granting of access could become non-compliant, there will be a lack of consistency across different divisions, or significant amounts of time will be wasted on discussions for each individual case.

Summary

Identity lifecycle management encompasses all the processes of an identity lifecycle from starting as an employee or contractor all the way through to termination of employment. This includes all the steps throughout the employee’s work life including name changes, temporary maternity leaves, leaving and rejoining the organization, and more.

In an adaptable identity lifecycle management solution, business functions can be matched according to changing business needs. This includes processes for IT and business collaboration, segregation of duties (SoD), and industry specific role and policy models allowing any arbitrary levels of roles, role types, and classifications.

Modern lifecycle management models integrate multiple applications and systems (some identity parts managed within an application like ERP and some in identity stores like Microsoft AD) into logical business applications management for easy application and system resource onboarding, self-service access request, and governance reporting.