Skip to content
AuthMantraPraxis
authmantra.com ↗Start free trial

ComplianceSecurity operations

Access reviews that auditors accept

AuthMantra Team5 min readPractical

Short version: headings, key sentences, diagrams and callouts.
A manual access review cycleExport whohas whatOwnersconfirmRemoveexcessFile theevidence

An access review is a simple idea: at regular intervals, someone who knows the business confirms that each person still needs the access they have. Auditors ask for the evidence, and that is where many reviews fall apart.

A spreadsheet emailed to forty managers, with half the replies missing and no record of what was removed, proves very little.

This article describes a review that holds up when somebody independent reads the evidence a year later.

Be honest about what a review is

A review is a control, and a control needs three properties for an auditor to rely on it:

  1. Complete. It covered the whole defined population, not a convenient part of it.
  2. Independent. The reviewer is not simply approving their own access or their team's access by default.
  3. Acted on. Findings led to changes, and you can show them.

Everything below serves one of those three.

Tip

Name a deputy for every reviewer, so leave and absence do not stall the review.

Step 1: Define scope

Write down which systems and which people are in scope, and why. A defensible scope is risk-based:

  • Tier 1, quarterly: privileged and administrator access, finance and payroll systems, production infrastructure, anything holding personal data at volume.
  • Tier 2, twice a year: line-of-business applications with sensitive data.
  • Tier 3, annually: everything else.

Include non-human and non-employee identities. Contractors, vendor accounts, shared mailboxes and service accounts are what auditors find forgotten. See service accounts and API keys for the inventory side.

Record the scope document with a date and an approver. If it changes, version it.

Step 2: Produce a clean extract

The review is only as good as the list you start from.

  • Pull the extract directly from the system or from an audit log export, not from someone's memory or a hand-edited file.
  • Include for each account: the person, their role or group, their manager, last sign-in date, account creation date, and the specific entitlement.
  • Stamp the extract with the date and time it was generated, and who generated it. Keep the original untouched.
  • Reconcile the count against the source. If the system shows 412 accounts and the sheet has 405, resolve the difference before anyone starts.

Last sign-in is especially valuable. An account that has not been used in 90 days is a strong candidate for removal and spares reviewers a judgement call.

Step 3: Choose reviewers sensibly

Who reviews matters as much as how.

  • Manager review is good for "does this person need this role for their job?"
  • Application or data owner review is better for "should anyone in this role have this much access?"
  • Do both for Tier 1: the owner reviews the entitlements, and managers review their team.
  • Nobody reviews their own access. Where that would happen, route to their manager or to the owner's deputy.
  • Name a deputy for every reviewer, so leave and absence do not stall the campaign.

Step 4: Give clear decisions, not open questions

Reviewers should pick one of a few labelled outcomes for each line:

  • Keep: access is still needed.
  • Remove: access should be revoked.
  • Reduce: needs a lesser role. State the new role.
  • Query: cannot decide, escalates to the owner.

"No reply" must never count as approval. Set a deadline, send reminders, and escalate unanswered lines to the reviewer's manager. A review with a silent default of "keep" is exactly the kind an auditor will challenge.

Step 5: Full population or sample

Do you review every account, or a sample?

ApproachBest forCaveat
Full reviewPrivileged access, small populations, high-risk systemsMore effort, but strongest evidence
SampleLarge, low-risk populationsSample must be defined and documented

If you sample, say how: the size, the method (random, risk-weighted) and why that size is reasonable. Do not let reviewers choose which accounts to look at.

Also remember that your auditor will draw their own sample from your population, regardless of what you reviewed, so the whole population extract must be available.

For access that matters, full review is the safer habit.

Step 6: Close the loop

This is the step most often missing. For each "Remove" or "Reduce":

  1. Create a ticket or change record.
  2. Perform the change within an agreed time, for example five working days for Tier 1.
  3. Capture evidence that it was done: a later export showing the account or role is gone, or the log entry for the revocation.
  4. Record completion date and who did it.

Then rerun the extract after the changes and compare. Any "Remove" that still appears is an open finding.

Step 7: Keep evidence with timestamps

Assemble a single folder per campaign, containing:

  • The scope document and approval.
  • The original extract with generation timestamp.
  • The reviewers' decisions with the time each was recorded.
  • Reminder and escalation messages.
  • The remediation tickets and their completion evidence.
  • The post-remediation extract.
  • A short sign-off summary: population size, number reviewed, number removed or reduced, number still open, and the sign-off by a named senior person.

Timestamps matter. They show the review happened in the period it claims, and the order of events: extract, decisions, changes, verification.

Retain the folder for as long as your own retention policy and your regulator's guidance require; check with your compliance counsel on the period.

Separation of duties

Auditors also look for conflicting combinations. Define a short list of toxic pairs and check them in every review:

  • Creating a vendor and approving payments to that vendor.
  • Developing code and deploying it to production alone.
  • Granting administrator roles and reviewing the log of those grants.

Anyone holding both sides of a pair is a finding unless a compensating control is documented. The reviewer of administrative actions should not be the administrator who performed them.

What tooling can and cannot do

AuthMantra provides audit log export and an auditor role with read access, so the evidence can be pulled and inspected by someone independent.

It does not run review campaigns for you: the scope, extracts, reviewer assignments, reminders and remediation tracking are a process you run, with a spreadsheet or whatever workflow tool you already use.

If you operate under a financial, insurance or other sector regulator, review your regulator's cyber-security guidance and speak to your compliance counsel about the expected review frequency.

For related reading, see audit and DPDP readiness and the joiner-mover-leaver checklist, since many review findings are really missed leaver or mover steps.

What to do this week

  • Pick one Tier 1 system and write its scope in a paragraph.
  • Pull an extract, stamp it, and reconcile the count against the source.
  • Name reviewers and deputies, and check no one reviews themselves.
  • Set the deadline, and decide that no reply means escalation, not approval.
  • Create the evidence folder before you start, not after.

Try it

Audit logSIEMProvisioning