Skip to main content

Guide

Identity and access management that survives an audit

Auditors do not ask whether you have an IAM platform. They ask you to prove that a specific person lost a specific access on a specific day, and that is where most programmes come apart.

Threatsys GRC practice2026-05-22

Identity is where the majority of the findings land in the assessments we run, and almost never because an organisation lacks tooling. The tooling is usually fine. What fails is the join between the tooling and the way people actually arrive, move and leave.

Here is the question that separates a programme that works from one that looks like it works. Pick someone who left three months ago. Show, from system evidence rather than a ticket, every access they held on their last day and the timestamp at which each one was removed.

Most organisations cannot answer that in under a week. Several cannot answer it at all.

Why leavers are the honest test

Joiners get attention because somebody is waiting to work. Movers and leavers get attention only when a process forces it, and the process is usually a ticket that HR raises and IT closes.

That ticket covers the directory. It rarely covers the SaaS tool a department bought on a card, the vendor portal with a shared login, the production database with local accounts that predate single sign on, or the service account created for a migration in 2023 that still has write access to the payments schema.

Accumulated access is the finding underneath most privilege findings. Someone who has moved twice inside your organisation holds three roles' worth of entitlement, and nothing in your process ever took the first two away.

What an auditor will actually ask for

Under ISO 27001:2022 the relevant controls are A.5.15 through A.5.18, and the evidence request is consistent: the access register, the review records, and proof of removal. Under RBI's Master Direction on IT Governance the emphasis falls harder on privileged access and on the segregation between the person requesting access and the person granting it. SEBI's CSCRF asks similar questions with a market infrastructure lens.

The common thread is that none of them accept a screenshot of your IAM console. They want to see a decision, who made it, when, and what changed as a result.

The four things worth fixing first

Reconcile your identity source with reality. Export every account from every system that holds one, match against the HR record, and look at what does not match. This exercise is dull, takes about a fortnight for a mid sized estate, and reliably finds accounts belonging to people who left years ago.

Get privileged access out of standing grants. If your administrators hold admin rights permanently, every phishing email against them is a domain compromise waiting to happen. Just in time elevation with an approval and a session recording turns that into a contained incident. This is the single highest value change on the list.

Make service accounts owned. Every non human account needs a named human owner, a documented purpose and a review date. Unowned service accounts with excessive rights are how a foothold becomes a breach, because nobody is watching an account nobody remembers creating.

Run the review quarterly and make it mean something. An access review where managers approve everything in one click is worse than no review, because it manufactures evidence that a control operates when it does not. Give the reviewer the last used date next to each entitlement and watch the approval rate drop.

On single sign on

Consolidating onto SSO is the right direction and it is also where a specific risk concentrates. When every application trusts one identity provider, that provider is the whole estate. Conditional access policies, phishing resistant factors for administrators, and monitoring of the identity provider's own audit log stop being nice to have.

We test this directly. If we can compromise one identity and reach production without meeting a second control, the SSO consolidation has moved the risk rather than reduced it.

The sequence that works

Reconcile first, because you cannot govern access you have not enumerated. Then privileged access, because it carries the most blast radius per account. Then service accounts. Then the review process.

Organisations that start with the review process, which is the common instinct because it is the thing the auditor asked about, end up reviewing an inaccurate register carefully. That is a lot of work for evidence that does not hold.

Back to the blog

Not sure where to start?

Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.