Can You Run User Access Reviews Without a Dedicated Tool?

Welcome everyone to our webinar from Radiant Logic. Khadija and I will lead you through this webinar.

Today’s speakers will be me, David Johnson, and Khadija. I’m a Lead Consultant at iC Consult. From Radiant Logic, we have Khadija with us, so why don’t you introduce yourself?

Yes, thank you, David. Hi everybody. My name is Khadija, and I’m a Senior Technical Enablement Specialist at Radiant Logic. I’ve been working for Radiant Logic for the past three and a half years. Before that, during my first three years, I worked as a Professional Services Consultant for Radiant Logic before switching to full‑time training and enablement.

Thanks, Khadija. Let’s continue.

A few quick words about iC Consult. We’re a partner of Radiant Logic. To give you some numbers: we are now internationally a world‑leading consultancy and we do international work. We offer services in the US, in EMEA, and in Asia‑Pacific, including China, and we’re vendor‑independent. We work with many products and partner only with those we think make sense, and with whom we also do webinars.

So, welcome again to Radiant Logic, and thanks a lot for doing the webinar with us.

Thank you, David. A quick word about Radiant Logic: we’re a software company specializing in identity data management and identity analytics, with identity rationalization, compliance, and governance features around users’ access rights. Radiant Logic is almost thirty years old and has been named a Gartner Cool Vendor multiple times over the past fifteen years. We have quite a few multinational corporations as customers; you can see a sample of our logos on the slide, along with some of the accolades we have received. Most of our clients are in financial services, healthcare, and public/federal administration, and we also have customers in many other verticals. You can also go to the Gartner Peer Insights platform and check our customer ratings, which are an outstanding 4.8 out of 5. That should give you a good idea of the customer satisfaction we generate.

Thank you, Khadija.

Let’s start the webinar and look at why user access reviews are actually so important.

A common gap in identity strategy is that employees still retain access three months after departure. In your perfect IGA system, of course, you have processes, but there are other areas where proper offboarding is not done and access remains in the landscape that should have been removed after the employee left your organization. The same goes for identity breaches. It all starts with identities. The average number of identities per user is more than twenty. You may have one person but still twenty identities, which is already a lot for a smaller company. In larger companies this can go into the hundreds. If you have an identity in each of those systems, potentially there could be access to information somewhere that you should not have, and it’s a nightmare to maintain. The obvious point is that business processes rely on identity data: you can’t start any business process without considering identity.

Reviews should not be taken lightly. They have a real impact on risk, on responsibilities you have to manage, on improving governance, and on ensuring compliance. The overarching point is that you want to have a good review. You want to actually achieve those outcomes with your reviews. Often what happens is review fatigue, or reviews that are not done properly. Then all the points I just mentioned will not be solved by a review that is not done correctly.

This is why reviews are so painful. For campaign owners, you first need to find out who should actually review: who is leading a department now, who should do which part of the review. This is always changing because departments are reassigned, people move between departments, and new departments appear. It’s a nightmare to maintain without proper data and a system that assists you in those reviews. Otherwise you are always in catch‑up mode, especially as a campaign owner.

Then there is the manager problem. It’s time‑consuming, access‑right names are cryptic, and tool capabilities are limited. Anyone who has set up or performed an access review knows these are real pain points. Typically, you start a project, push the review to managers, and ask them to decide on permissions per identity in an application. The manager often has no idea what is going on and, worst case, just blindly accepts. The review is done, but you haven’t really achieved any of the outcomes mentioned earlier. So you did it, but was it accurate? Did you really complete it? Will you ever complete it? Managers who try to do it right may not finish the review because they don’t know what they are accepting and are not willing to do it. Then you have another problem: you have to get in contact, assist them, and try to get the review done within the set time so that, from an organizational point of view, you can say it is complete.

That’s the worst part. I’ve seen organizations that either gave up or are at the beginning, doing manual access reviews. We met one such larger company where you would expect access reviews to be done at least in an IGA tool. Instead, it was an odyssey: they started with a review journey that began for the whole company in one period of the year. They didn’t spread reviews for different departments across time; the entire company started and tried to finish at the same time. This doesn’t work. Support has to run, collect data, and at some point it becomes unbearable. Once you hit a certain size, it’s not maintainable and the workload will not be finished. That’s the worst kind of review you can do at scale.

Thank you, David.

After this worst‑case scenario of running user access review campaigns using Excel sheets, the natural next question is: can I trigger my user access review campaigns using my IAM or IGA platform?

Since many IAM/IGA vendors provide access‑related features, that seems like a natural assumption. But the issue appears very quickly in terms of scope and overview over users’ access rights. Often, as David can back up, corporations set up an IAM solution and interface it only with two, three, four, or five data sources, repositories, and business applications, and cannot go beyond those. That means that whenever you run an access‑review campaign, visibility that managers have on their users’ context, access rights, shared folders, and other components is very limited. The IAM “circle” does not encompass everything, and you end up with many blind spots.

For example, you might not have visibility into segregation‑of‑duties violations on applications that are not linked to your IAM platform. You might or might not have compliance controls. You might only see orphaned accounts on those two to five connected applications. You may not have access to lists of service accounts, local admin accounts on servers, databases, CyberArk vaults, etc. All these are blind spots that the IAM tool doesn’t see, and therefore it cannot give you visibility over them.

When it comes to decision‑making during a user access review, if the IAM is your only source of intelligence, the process relies on incomplete data and leads to risky decisions. A line manager might blindly approve all listed access rights, especially those with names that are not self‑explanatory (for example, AD groups like “R2_D57_8”). Accesses that carry IT or compliance risks would be kept over and over.

When a corporation switches to running access‑review campaigns with an Identity Analytics solution like ours, which is our recommendation, we provide full 360° visibility over a user’s access rights and identity context. We draw information from the IGA platform—so we work alongside it—and also from the blind spots: other applications not interfaced with your IGA platform.

We can draw this intelligence by ingesting flat files extracted from data sources (CSV, Excel, LDIF, XML, JSON, etc.) in a standalone process, or by creating connectors that periodically pull data from these repositories and IT assets. This lets us provide complete visibility over each user’s access rights, regardless of the technology, language, protocol, or whether the applications are connected to the IGA platform.

The purpose of an Identity Analytics tool is to draw data from all these sources, correlate it to offer a 360° profile of a user’s access rights, and consolidate this data from application, organizational, departmental, and other perspectives. It then offers intelligence, assessments, and compliance controls that help you determine whether an access right is risky, whether there are mitigation actions, and, using role‑mining capabilities, it can recommend access rights a user should have based on job function and the common access rights of teammates. This both ensures they can perform their duties and saves time and effort in granting access.

The impact of Identity Analytics on your decision‑making process in a user access review is that it comes before the IGA solution’s role. When you run campaigns with an Identity Analytics tool like ours, it provides insight and understanding on users’ access rights, then provides the decision‑making process and workflow to line managers so they can make rational decisions based on all available intelligence. The list of decisions is then handed over to your IGA platform, ITSM, or any other provisioning/deprovisioning system. You are able to bulk‑revoke access rights deemed risky across many systems: for connected applications via the IGA platform, and for non‑connected applications via ITSM systems like ServiceNow or Jira, or other deprovisioning systems.

We’re not the only ones recommending an Identity Analytics tool alongside an IGA platform. Gartner noted in 2019 that setting up an IGA platform together with an Identity Analytics solution can double the return on investment compared to installing an IGA platform alone. It helps with data qualification and cleaning that must happen before installing a new IGA solution or migrating between IGA platforms.

I can fully confirm this from project experience. If you don’t do analytics right from the beginning, you don’t know what you have or what you’re getting into. If you blindly start integrating an IGA system and forcing roles out without proper analytics, the project will take longer and it will take longer to gain user acceptance. It makes sense to do proper pre‑analysis and start analytics before full‑blown IGA implementation. This would have saved many projects in the past. It helps scope the project, understand complexity, see how quickly things can be controlled, plan the project accordingly, and get a smoother start.

Even before joining Radiant Logic, when I was an IGA consultant, I saw many corporations jump into implementing their IGA platform directly. Then, two or three years later, they were puzzled by the data‑quality issues in the IGA database and the difficulty of interfacing more applications because identity data inside the IGA already had quality issues. So I fully back this up.

When it comes to Identity Analytics tools, ours provides features for user‑access observability, intelligence, risk assessments, access review, and role mining. For our next release, coming in late spring 2024, we have a new announcement that will make user access reviews even faster: we are adding an AI‑based data assistant to our user‑access capabilities. We call this data assistant AIDA. AIDA will help line managers run their access‑review campaigns even faster.

Thanks to AIDA, we hope line managers will be able to perform their campaigns in minutes instead of hours or days. AIDA will guide line managers through understanding all their users’ access rights. You can imagine the back‑and‑forth that line managers usually have with application owners and previous managers: questions like “I see this user has this access right, but I don’t understand what it is,” or “This person came from your team and has an access no one else on my team has—what is it?” All this Q&A becomes less necessary because AIDA provides that insight directly to each line manager on their scope of data and suggests what decisions should be made about each access.

Because AIDA gives both insight and suggested decisions, managers can no longer blindly approve risky access rights and perpetuate risk. Each time an access right carries risk, AIDA will say: “You have these risky access rights within your team—what do you want to do about them? Maintain or revoke?” It becomes impossible for a line manager to bypass this and blindly approve everything; the information is brought to their attention.

These features will be available for all types of access‑review processes: application access rights, account reviews, service‑account reviews, privileged‑access reviews (for example, CyberArk vaults or local admin accounts). You can apply AIDA to all components submitted to an access review.

To give you a quick demo in words: first, you have our usual access‑rights review interface with a list of access rights a line manager must approve or revoke. On the top‑right of the screen, you see the AIDA assistant logo. When you click it, a section appears on the right. It starts by telling you about entries you reviewed previously and that have not changed, so you can approve them again and immediately approve a large portion of your scope in seconds. Then you move to the next part: AIDA introduces risky access rights that were identified either because they were already risky, or because the situation has changed (for example, leavers who still have active accounts). After presenting these, it gives you the possibility to investigate: filter the list to show only risky access rights, display bar charts and KPIs about these risks, and then decide whether to revoke or keep them. If you click revoke, AIDA bulk‑applies the decision to all listed entries, or you can manually process them.

I really like this part because it gives more human interaction. It not only points out compliance reasons (for example, removing leavers in time), but also adds context such as license usage and cost, helping to engage the manager and show why the review is important. Instead of being lectured about the importance of reviews, managers see concrete reasons inside the tool.

After handling risky items, AIDA moves to the remaining access rights. It switches to a pivot‑table mode, showing access rights commonly granted to groups of people and inconsistent ones held only by one person. It presents extracts block by block in clustered views. For example, you might see a block of permissions granted to people who all have the same job function (e.g., accountants). At first glance it looks consistent, so you can approve the whole block or decide to analyze it further if there are recent job‑function changes. AIDA gives this insight and it’s up to you to validate or refine it. After finalizing these block reviews, you’re done in a few minutes.

Even if it takes ten minutes, it would still be a world record if done properly for managers with hundreds of direct reports. That’s why we say: do you still want to do user access reviews without Identity Analytics?

We already have questions, and we agree with many of them.

One question: “Which platforms can be used as data sources?” From our perspective, an IGA platform such as SailPoint is one of the data sources. Input data we ingest is usually flat files—CSV, Excel, LDIF (for Active Directory and OpenLDAP), XML, JSON, and sometimes TXT. We handle all these file formats and you can create ingestion processes and parsing rules for each. You customize them to the extracts your IT teams and application owners can provide. Your SailPoint team can provide an IGA extract, and we craft the data‑ingestion process around that file. This means we’re agnostic. We also have a marketplace with pre‑packaged plugins that help parse and ingest files from common data sources. We have plugins to ingest data from Okta, any IAM solution running SCIM, Microsoft Active Directory, Azure AD, Google Cloud, Linux local admin accounts, etc. If something isn’t in the marketplace, you can develop your own.

This makes entry easy. Many projects start with CSV or flat files, and you can get extracts from almost any IGA tool nearly instantly. You can later automate it, but at a low level you can start quickly and start analyzing data right away. That’s why starting with analytics when you start an IGA project is so important: it makes things easier from day one, and also if you have an established solution.

Another question: “How is it typically deployed with common IGA tools like SailPoint or Saviynt? Do they work in tandem?” It’s possible to have a control loop between your IGA/ITSM platform and your Identity Analytics implementation. You feed Identity Analytics with flat files from Saviynt or SailPoint. Then we create interfaces for remediation or revocation requests (tickets) that come from our access‑review process or from our control browser (where you access permanent controls and trigger remediation). We can send remediation requests as tickets to ServiceNow, Jira, your IAM system, or any ticketing platform. This gives you a back‑and‑forth loop: you send revocation requests to your IGA or ServiceNow, they handle remediation, and when we ingest files the next week or month, we see whether the account was actually revoked. If not, that triggers a new risk and becomes part of the control plan again. We track this in a back‑and‑forth loop if you interface these systems.

You can also handle remediation manually or via mass emails to systems that are not ServiceNow or Jira (for example, a third‑party system). You send emails to a mailbox or group for an application, and it is handled separately. Then you track and update revocation requests in the Identity Analytics remediation section, marking tickets as completed or in progress. This is configurable. You can have different strategies for different applications: for example, use SailPoint integration for three IGA‑managed applications, and manual processes for an engineering application outside IGA scope, handled by the application owner.

Another question: “Can you ingest data from Okta?” Okta is part of our marketplace. We can pull files from Okta as an identity data source and also use Okta as an authentication platform to access the Identity Analytics web portal. The same goes for Active Directory or Azure AD, which can be used both as data sources and authentication providers.

Finally, a question on deployment: “How is it deployed with common IGA tools?” As explained, it typically works in tandem: the IGA platform is a data source and a remediation endpoint, while Identity Analytics provides visibility, intelligence, and decision‑making workflows, feeding back revocation or provisioning decisions into the IGA or ITSM systems.

That covers the main points we wanted to discuss about why user access reviews matter, why they are painful today, and how Identity Analytics and AIDA can transform them from a painful manual process into a fast, insightful, and effective one.