Access reviews simplified

Access reviews shouldn't take hundreds of thousands of hours. If they do, it's time to look at a better risk-based approach.

Access reviews have become a topic of fear-mongering:

• Do you know who has access to your hundreds of apps?
• Do you even know what all your apps are? 
• How much are you paying for licenses you’re not using? 

I’m yet to work with a company that can confidently answer those three questions. But before you throw a team at the task, try to automate it, or give up completely, let’s put it into perspective. 

If you’re a startup with less than 50 apps -> skip to the bottom to see how we manage our own access in 15 minutes per quarter. 

Access reviews are one part of the broader topic of access management. They are a check, often quarterly or annually, to confirm your access control is working correctly so the right people, have the right access, to the right systems. 

We’ve seen clients conduct access reviews and notice access rights that are wrong. They conclude they need to invest more time in those access reviews. But that’s missing the point of it. Instead, ask what went wrong to cause that incorrect access and fix it at the source. For example, why wasn’t that access removed when the person was terminated? Or modified when they changed roles? Or was it set up incorrectly when they were onboarded? Did they only need temporary access? 

If things are working well, the access review should just be confirming the access is correct. 

How to manage access effectively

Step 1: identify the purpose

As a starting point, be clear on what you’re trying to achieve. This is really important, otherwise you’ll waste your time and miss the point with the rest of it. 

• Are you trying to secure all your sensitive data? Which types?
• Do you have privacy obligations for personal data? 
• Do you want to achieve SOC 2 or another framework?
• Are you trying to keep a lid on licensing costs? 

The way you implement things from there can be very different. 

For example; if your immediate goal is to achieve SOC 2 - the scope of apps to focus on is usually between 3-15 total. That may be a very small subset of the total you actually use. That’s the ones your customers directly rely on and the critical infrastructure supporting those. If your goal was to reduce costs, you probably wouldn’t spend much time on the apps that don’t have licensing costs per user. 

Often it’s multi-purpose, but when you know what those goals are you can get better outcomes, with less effort. 

Step 2: catalog your systems 

Create a list of your apps. That may be focused solely on your purpose from step 1. Or if you’re  really diligent, go for a full list from the start. It’s probably going to make your life easier in the long run. But if you do go for a full list; highlight, classify, or rank those you’re immediately focused on so you get the best results from your efforts. 

It’s helpful to capture information that supports various access management processes and monitoring. Access reviews are one part of that. You might track: 

• Data types: personal, customer confidential, internal data. This can influence which systems are disclosed in your privacy policy, whether they need strong security practices (eg. MFA), and how they relate to your compliance scope that may be single or multi framework with varying requirements. 
• Authentication method: Higher risk cloud apps should have multi-factor authentication, but also tracking the method like Okta SSO, using a Google account, or just user name and password, influences how you would manage the access accordingly, including the method of access reviews. 
• A system owner: If you’re a larger company, it may be important to have one or more system owners that understand their respective systems and who should have access to those. They might be the approvers of new access, the ones who should review the access periodically to ensure it’s correct, but also the person to engage for license renewals, system issues, or whatever else. 

There are a lot of other details you might capture. But it’s important to be pragmatic and realistic about it. If you try to track everything for the sake of more data, you’ll probably end up with a messy, unreliable, and incomplete register of systems. Keep in mind how this will be maintained, and ensure the relevant processes are connected, like adding an item to this list when a new system is approved or used. 

Optional Step 3: Strategise and lay foundations

There’s different strategies you can take to support access management at scale. Whether they’re worthwhile will depend on your goals, your scale, and the way your team works. For us with 20 people and 15 material systems, we haven’t needed any of these (yet):

• System access role matrix: role based access is a good practice for Individual systems. An access role matrix is a level above that, where you say a developer, or a product manager, should have access to X, Y, Z, systems, and even the specific access levels or roles within those systems. This matrix means you can then set up, remove and periodically review user access rights knowing exactly what access each person should have. A danger with this approach is things often aren’t that simple in practice. Over reliance on this can cause things to be missed completely. 
• Data minimisation: reduces the information security risk by design. Do you need customer data sitting in your ClickUp or Confluence? Do you even need to collect it in the first place? The less data you have and the less places it’s stored, the less dependency on access management. In a risk-based access management process, that means saving time by more narrowly focusing on the systems that matter, and their specific risks. 
• Conducting risk assessments: helps narrow your focus for access management. That’s especially useful for access reviews. Looking at three system examples you can see the risk levels are quite different:
  • AWS hosts your product and its management console is the keys to your kingdom. That’s a “critical” or “high” risk.
  • Trello may be used for internal task management without any customer data, so it’s a “low-moderate” risk.
  • Uber Eats may be used to feed your team but needs an active company credit card, so the risk is insignificant.

Once you’ve classified those risks, you might say the access reviews should be monthly/quarterly for AWS, annual for Trello, and you don’t need to do them at all for Uber Eats. That can also influence whether you enforce MFA, review those providers’ SOC 2 reports, and various other security practices. 

As it relates to access reviews, you can go a step further if you’ve tracked the information above. If the systems are authenticated with Okta for example, it might reduce the need or frequency for access reviews, or just allow you to centrally complete those reviews within Okta. Same idea for systems where Google accounts have to be used, but that may have a dependency on your team setting it up that way individually. 

Step 4: Design your access management practices 

This is where the above steps come together into a practical method of access management. Firstly, set up good onboarding, role change, and terminations processes, as these are the best way to ensure access is correct at all times (not just retrospectively fixed in access reviews).

Then think about your access reviews. If you’ve classified the risks, think pragmatically about how to address those risks. 

One important consideration is contextualisation. That is conducting reviews where you’re focused on whats important and why you’re doing it. If you use Drata, for example, your connected infrastructure, code repository, and workspace software will have automated data feeds to monitor that access.

When that’s set up to know who your admins are, who should have developer access, and the full list of who’s employed, it can automatically test where user access varies from what’s expected. For example; when we gave our pen testers access to our environment, Drata flagged they’re not part of our organisation and aren’t supposed to have elevated access to our code repository. Of course then we can confirm they should, but only temporarily, which is important to track for that sort of higher risk access.

Contextualisation may be less important for your lower risk apps. If it’s a system that your whole company has access to, or there’s limited sensitive data in that system, you may only be checking that access is assigned to active employees. In that case you could simplify the review by a script that compares to your Active Directory, or even just check any employees terminated since the last access review no longer have access. 

If you’re spending a long time on access reviews, that’s where you may want to get more advanced with the risk based approach. As a rule of thumb, if your team are overwhelmed with it and lost in the user listings, it’s probably not going to be as effective. You can "tick and bash" user listings but human nature will result in oversights, so best to prioritise focus and efforts on the access that really matters.

Reduce the frequency for lower risk apps, or even de-scope them. Focus on specific goals like checking any terminated users have been removed, or reviewing only the higher levels of access like administration rights. Having different approaches for each system can add complexity, but if you “bucket” the systems and apply a clear strategy, it can save a lot of time without creating confusion. 

How we manage access in 15 minutes a quarter

If you’ve a list of less than 50 apps and less than 50 employees, the post above probably sounds like madness. It is. You can keep things really simple. 

We have a checklist of 15 apps that covers everything important for us; our Google Workspace, Airwallex expense cards, our product and development tools, our ESOP, and internal systems. That list is part of the onboarding checklist, exit checklist, and what we review on a quarterly basis. Each line in the checklist is linked to the access management page of the respective apps, so it takes an admin a minute to click into each system to add, remove, or scan the list, and confirm it’s all correct in each of those three processes.

If it’s not correct, figure out what went wrong and solve it from a process perspective. Remind your team how to set up or remove access correctly. Identify if there’s a process gap, where you might be providing ad-hoc access without a defined way of tracking that.

Summary

If access reviews are taking an obscene amount of time, or causing excessive pain for your teams, there's probably a better way. Hopefully this post prompts ideas that you can apply to your approach. If in doubt - get in touch. As an independent audit firm, we won't do it for you, but we can guide you, challenge your existing approach, and bring a fresh perspective.