What Is IdAM Implementation?

We have studied different sections so far during the course, and we’re trying to pull together all of that knowledge now to look at how, practically, we could implement an identity and access management solution, and organizationally, what that would mean, what that would require. And this covers a variety of elements from the people and the technologies.

So, worthwhile recognizing that we have an identity and access management implementation. Whether we recognize it or not, we have one. It may not be documented. It may not be very good. It may not be best practise. But we are doing something that collectively constitutes identity and access management. We can use capability maturity models to help recognize where we are at the moment in terms of our organizational maturity and also where we need to be. So these can provide a good way of recognizing the target state but also baselining our current position. During this, we have some discovery phases that can help identify where we are, what technologies we have, what processes we have.

We can aggregate this and then we can baseline it. So understanding what we do at the moment is important before we can look at developing anything else. We need to know where we are. So the discovery phase is typically an area that suffers from underinvestment. It’s more exciting to go and buy something, to start implementing something new. The best thing we can do, the best investment we can make early on, is to understand where we are. Some aspects of identity and access management have very low visibility, a very low level of understanding. Small line of business systems may not have a good corporate awareness. And so spending time investigating these, their capabilities, what information they store, is important.

So we need to aggregate this and report back. And this will ultimately perform part of the baseline that we can approve, and then communicate, and share. While we’re looking at implementation, this requires a considered, structured approach. This is in effect a project. This is a project-based approach. We want to treat this like a project. It’s also a team-based approach. One of the big dangers we have with identity and access management implementations is that we treat this as an IT project or an IT security project and we do not have the buy in or the mandate.

We want to make sure that we establish our stakeholders, we understand who they are, and that we communicate effectively with them, and also with the senior management team that we’re working for, that we’re supporting. We also need to understand our approach to resource planning and scheduling. As part of our project plan, we should typically have a good outline of what resources we require and where they’re scheduled, and any technical implications, including the design and also subsequent architecture. So when forming a baseline, we need to understand where we are currently.

We need to audit our existing identity and access management technologies and capabilities, including the hardware, the software services, but also the people and the skills, the skills we have, the people we have. This lets us understand the local, regional, and corporate context, and any business requirements that we need to meet, we need to include within this. And again, we can assess this using a capability maturity model. We can examine the maturity of our processes, of our as-is state and our to-be state. We can look at how rigorously those processes are implied, how comprehensive the processes are in terms of their breadth and their depth. Do we use them in an ad hoc capability? Or are they systematically applied?

Or are they enforced? So business requirements, we need to understand what the organization wants. We’re here to support the business. And this can only be achieved through stakeholder analysis. Stakeholders from our senior management team, stakeholders from different aspects of our organization. This is key to the individuals, this is key, and we must involve relevant individuals within the project. This may include the technical needs for specialist areas, security and governance leads, but also the business leads, people actually at the rockface doing the work. They have the best understanding of what we currently have and also can help us understand what would practically work for us within the organization. So we can consult system owners, people who manage individual systems.

Business owners, owners of business processes and business functions, board level representatives, chief information officers, chief finance officers, and similar. We can talk to suppliers and vendors. If we have customers, if we have suppliers into our organization, if we’re implementing a new identity and access management system, how will this impact them and the way they work? Do we need them to change the way they work with us? Any other partner agencies we’d also want to include in terms of establishing those requirements?