In the previous chapter, we explained what Identity Governance and Administration (IGA) is, and 

how IGA platforms can help organizations stay on top of managing access for their users. We also 

discussed how many organizations start off with a homegrown approach to IGA using a combination 

of spreadsheets, helpdesk tickets and manual intervention.  

 

Whilst a homegrown approach can work for small organizations with a small number of users, as the 

organization grows it rapidly becomes problematic – generating issues with efficiency and security. 

This is particularly true for any organization which faces regulatory compliance requirements, such as 

PCI-DSS, HIPPA or PSD2. 

 

In this chapter we will walk through the steps involved in a homegrown approach to managing access 

for a user during their association with the organization – known as the ‘identity lifecycle’, 

highlighting the potential issues and risks involved at each step. 

 

The image below shows the steps involved in a typical identity lifecycle – in this case for an 

employee. Lifecycles for different types of users vary somewhat – but the core principles remain the 

same. The identity lifecycle covers every action that has to take place from the moment the 

individual joins the organization until the moment they leave, including all of the inevitable change 

that takes place between these two events.

 

1)New User Joins the Organization 

The identity lifecycle starts when a new user joins the organization. Typically, for an employee, this 

means that a record is created for the individual in the HR system, maybe on receipt of an offer 

acceptance letter. This record, usually created and managed by the HR department, will include key 

information about the individual including start and end dates, contact information and their job title 

and department. Usually the HR system has no concept of what access to applications and systems 

 an individual should have, which is where the challenges start. 

 

In order to start managing access, the first thing the IT department needs is notification about the 

new user which in many cases relies on someone in HR sending an email, and on someone in IT 

picking up the email and reacting promptly. In some cases this might work smoothly, but in many 

other cases there may be delays or the notification may be not send or missed completely. This can 

result in a new starter being unable to work for some time after joining the organization, which is a 

poor user experience and has a cost in terms of lost productivity. 

 

2)Digital Identity Created 

Once IT has been notified about the new starter, someone has to create a digital identity for the new 

user. At its simplest this is a username and password to enable the user to log in – in many cases this 

means an Active Directory account needs to be created, a username assigned and the users initial 

password created and communicated.  

 

This process is not trivial, and can take up to half an hour per user – this maybe seems insignificant 

but in the context of a busy IT department, if there are a large number of users to manage the 

overhead quickly builds up. On top of that, if the process is manual then issues can develop over 

time in terms of standardization – is a common username format being used, are users being placed 

in the right OU in Active Directory etc. Further, communicating the initial password to the new user 

can be problematic – doing it in person is inefficient, but there are security issues inherent in 

emailing out a password to a manager or to the individual – ideally no one should ever know a 

password other than the individual. 

 

3)Create Accounts for All Systems the individual will need 

Of course, it’s not enough to simply create one AD account for new users. Typically users need access 

to multiple applications in order to do their job. This presents a couple of problems.  

 

Firstly - how do you know which applications they need access to? Unless you have tightly defined 

access rules, how is someone from the IT department meant to know what access someone from the 

Engineering team needs? Often, organizations make a ‘best guess’, or copy the access from another 

user from the same department. This can be a dangerous approach leading to users gaining more 

access than they should, particularly if there are poor controls governing access. 

 

Secondly – creating all of these accounts takes time. Typically, different administrators are involved to 

create accounts in each application. This means a lot of emails need to be sent, or Helpdesk tickets 

need to be raised – leading to a lot of delays before a user’s access is fully provisioned. 

All of this adds up to costs in terms of lost productivity. 

 

4)The user’s role changes 

The one thing we can be certain of is that once provisioned, a user’s access will need to change. This 

could be due to a change in role, or maybe a temporary project assignment. Whatever the reason, if 

a role changes, then access must change with it. 

 

This presents the same challenges as above – all over again. How does the IT department know what 

access the user needs in their new role? And crucially, how do they know what access is no longer 

required and should be removed?  

 

There is also the question of authorization – how does the IT department know who authorized the 

change? Presumably there will be an email or helpdesk ticket raised, but if not then the IT 

administrator is relying on trust alone. In either case, there is no audit trail showing how a user came to have their access. 

 

5)Create Accounts for the New Systems that the User Needs 

Once again, multiple individuals might be involved in modifying all of this access and creating or 

removing accounts across multiple applications – so again there could be a delay, during which time 

the user potentially has unauthorized access. 

 

6)Provide the auditor with proof 

At some point, sooner rather than later for companies with regulatory compliance requirements, it is 

very likely that the auditor is going to ask for proof that users have the right access to applications 

and systems. With DIY IGA, this is extremely difficult to provide – partly down to the logistical 

problem of identifying all of the relevant application owners and managers to perform the validation, 

identifying all of the users to be validated, and moving spreadsheets around to collect the 

information. But the problems get even harder in the absence of a central IGA system which 

understands the relationships between user accounts across different applications. For example, 

there may be multiple users called Jane Smith working for the company. One application may have a 

user account for jsmith, and another for j.smith. Which Jane Smith do they relate to? Or do they 

actually relate to another individual altogether – John Smith? Working through these matching and 

correlation issues is extremely time consuming and error prone, and at the end it is highly likely that 

the auditor will not be satisfied with the output. Ultimately this could affect the organization's ability 

to conform with regulations, and in some cases can impact the ability to win new contracts. 

 

7)The user leaves the organization 

The end of the lifecycle occurs when the user leaves or ends their relationship with the organization. 

Unfortunately, whereas human beings are very good at granting access when it is needed, in order to 

get a job done, they are very poor at following process to remove access when it is no longer 

needed, as removing access has no tangible effect on pressing day-to-day business. This means that 

in many cases there is a long delay between someone leaving the organization and their access being 

disabled or removed – and in many cases their access may never be removed. This is particularly true 

for contractors – employees are usually removed from the payroll system before the next pay day, so 

there is a trigger to remove access, but there is no such event when a contractor stops working for 

the organization. In this case, the relevant manager must remember and take the time to advise IT 

that the account is no longer needed, which in many cases does not happen.  

 

The outcome is a build up of accounts and access for individuals who no longer work for the 

organization, which creates a very large security and commercial risk. 

 

8)Disable the user’s access 

When the user leaves, we need to disable all of their access – not just their Active Directory account. 

However, if there are no clear rules governing what access someone should have according to their 

rules, and no central location to lookup the access that they actually have, it is very hard to be sure 

that all access to all systems has been removed or disabled. Therefore, when a user leaves the 

building for the last time, there organization cannot be sure that some institutional data may be 

going with them. This poses a significant commercial and security risk. 

 

Doing it yourself, can work for some organizations, for a time. But ultimately the issues that it creates 

in terms of inefficiency and more importantly security and compliance mean that it rapidly becomes 

a non-viable approach. This is where Identity Governance and Administration platforms come in. 

 

In our next blog, we will explore the core features that you should expect from an IGA platform to 

help address the issues identified in this blog. 

 

 

 

Comments

0 comments

Please sign in to leave a comment.