Access Reviews Managers Actually Complete

Monday, 08:40, at Bluewater Bank. Hannah runs a desk of five and has the auditor's letter from last year open beside the thing that caused it. The letter says "user access reviews not evidenced". The thing is a spreadsheet of forty pages, with every group membership in the directory listed by account name. Her predecessor exported it one morning and sent it to all nineteen managers with the subject line "Access review, please check and confirm". Two managers replied. One wrote "looks fine". The other asked what a group called GRP-FIN-RW-L2 was. Nobody answered, because nobody on the desk knew either. The remaining seventeen never opened it. Hannah does not blame them. She has just tried to read page twelve, and it is a wall of codes with no people in it. The next review is due this quarter, and this time it has to be one that people finish.

An access review is a periodic check, by the person who manages someone or owns something, that the access a person has is still needed. It is answered with one word: keep, or remove. One that managers actually complete is designed backwards from the manager's desk. The list is short, the names are plain, the question is one question, and the deadline is real. The chasing is the desk's job and not the manager's conscience. This article is part of our Access & Permission Requests series. It is about that design. The request, the approval and the tangle it tidies are in the articles before it. The review is where the loop they describe comes round to close.

It covers why the last review did not complete. Then it covers the one question, keep or remove; the list sized to be finished; and the quarterly rhythm and the chase. Next come the movers and leavers it catches, service accounts, and acting on the answers. The review sized for a small organisation as a worked example in hours follows. A short war story and the access review sheet to copy come last, in that order.

Why the Last Review Did Not Complete

The forty-page review failed for five reasons, and every failed review I have seen failed for some of the same five. It was the wrong unit: every membership in the directory, rather than the people one manager is responsible for. It was in the wrong language: group codes rather than the names of folders and systems the manager would recognise. It asked the wrong question: "please check and confirm", which invites "looks fine" and nothing else, rather than a decision per line. It had no deadline, so there was no day on which not having done it became a problem. And it had no chase, so the seventeen managers who did nothing were never asked again. They learned that the review was a thing that could be ignored at no cost. Each of the five is fixed by design, and none of them is fixed by sending the spreadsheet again with "URGENT" in the subject.

The review also failed for a reason that is harder to design away. It asked managers to do the desk's work. Translating GRP-FIN-RW-L2 into "the finance reporting folder, edit" is a job for the people who created the group. Sending the raw export sends the translation job to nineteen people who cannot do it. Everything that can be prepared is prepared by the desk. That way, what reaches the manager is a page they can read in a lunch break, decide on in minutes, and send back by replying. The manager's share of the work is the decision. Everything else is the desk's.

There is a quieter failure too: a review that completes without catching anything. A list of nineteen "looks fine" replies is evidence that a review happened and evidence of nothing else. An auditor who reads it will ask what was removed. A good review removes things. If the first properly designed review at an organisation removes nothing, it was not read. In that case, the desk should treat it as not completed rather than filing it as a success. (Removing nothing is the one outcome that is never true.)

One Question: Keep or Remove

The review asks one question per line, and the line is one person and one piece of access: "Priya, finance reporting folder, edit: keep or remove?" There is no third option, no "justify", no "comment", no "needs discussion". A manager who does not know whether Priya still needs it answers remove. That is because access nobody can vouch for is access nobody needs. If Priya does need it, she will say so within a day. In that case, a request restores it in minutes. That default is the whole discipline of the review. A review with a "not sure" column is a review where everything is not sure. The column fills while the remove column stays empty.

Two people can answer the question for any line. One is the manager of the person, who knows what the person does. The other is the owner of the resource, who knows what the resource holds. Ask the manager by default, because managers have fewer people than owners have members and the review stays short. Ask the owner only for the handful of resources sensitive enough that the owner should see every name on them each quarter. These are payroll, personnel, the customer database, the administrative groups. Those owners get a second, shorter list of their own. The register from Shared Folders and the Permission Tangle is where the sensitive ones are marked. Everyone else's access is reviewed once, by their manager, and once is enough.

The question is per line because "is this person's access correct?" is unanswerable and "does this person still need the finance folder?" is not. A manager presented with a person and a list of eight items will read the eight. A manager presented with a person and "confirm access is appropriate" will confirm. Write the review so that the manager cannot complete it without having read each line. In practice, that means a keep-or-remove box beside each line and no box at the bottom. The sheet at the end of this article has no box at the bottom. That is deliberate.

The List, Sized to Be Finished

A manager's list has their direct reports on it and nothing else, grouped by person. Each person's access is written in the names the manager uses: the finance reporting folder, the invoicing application's approver role, the claims mailbox. The desk translates every group and role into those names once, keeps the translation in the register, and never sends a code to a manager again. A manager with six reports and an average of seven items each has a list of about forty lines. That is a page and a half and ten to twenty minutes of reading. And that is the size at which the review completes. A manager with forty lines completes it; a manager with four hundred files it.

Leave off everything that everyone has. The base access every account gets, mail, the intranet, the shared drive everyone reads, is not reviewed per person. No manager will ever answer "remove" to it. And every line of it is a line the manager has to read past to reach the ones that matter. The role bundle from Role Profiles and Standard Kits is shown as one line, "standard claims handler access", with the bundle's contents on a separate reference page. That way, the manager's decision is "is this person still a claims handler?" rather than nine decisions about what a claims handler is. The bundle's own contents are reviewed once a year by its owners, as the approval article sets out. What is left on the manager's list is the access that was requested specifically, which is exactly the access most likely to have outlived its reason.

Put the reason beside each line where the desk has one. That is because "finance reporting folder, edit, granted for the budget project, until the project closes" is a line a manager can answer in two seconds. And "finance reporting folder, edit" is a line they have to think about. The reason comes from the original ticket, which is why the request article insists on a one-sentence why. A line with no reason on it is a line the desk could not trace. That is worth marking so that the manager knows the desk does not know either. Lines with no traceable reason are removed more often than any other kind. That is the review working.

The Quarterly Rhythm and the Chase

The review runs on a fixed day each quarter, with a deadline two working weeks later. Both dates are the same every quarter so that managers learn them the way they learn month-end. Quarterly is often enough for a small organisation to catch a mover within a few months of moving. It is seldom enough that the review does not become a background noise managers tune out. A desk that cannot manage quarterly should do it twice a year properly rather than quarterly badly. A desk whose auditor wants more frequent reviews of a few sensitive systems can run those on a shorter cycle without touching the rest. Whatever the cycle, it is the same every time, and it is in the calendar before the quarter starts.

Each manager gets a ticket of their own, with their sheet attached or pasted in and the deadline in the first sentence. The chase runs on the ticket like any other waiting-on-someone ticket. There is a reminder at the end of the first week. A second goes out with the manager's manager copied two days before the deadline. Then there is a note to the manager's manager on the day after the deadline, saying the review for their team is incomplete and naming the manager. The chase is factual and short, and it is the desk's, not the manager's conscience. The craft of a reminder that gets a reply rather than a filing is in Follow-Up Messages That Get Replies. A manager who learns in the first quarter that silence reaches their own manager completes the second quarter's review in the first week. I have watched this happen at every organisation that tried it, and at none where the chase stopped at a second e-mail.

Silence is reported, not acted on. A manager who never answers has not said remove. The desk does not remove on a manager's silence. That is because the person whose access vanished will find out on Monday morning and the desk will have no decision to point to. What the desk does with silence is write it down. The quarter's report says which managers completed and which did not. That line reaches the people the managers report to, which is the subject of The Quarterly Review. The one exception is time-boxed access whose end date has already passed. That is removed on its own ticket whether or not the review was answered, because the decision to remove it was made on the day it was granted.

The Movers and Leavers It Catches

The access review's main catch is the mover. This is the person who changed role, kept everything from the old role, and gained everything from the new one. So after two moves they can see what three jobs can see. Nobody removes access on a move, because the move is announced as good news and good news does not come with a ticket. Another reason is that the old manager has stopped thinking about the person and the new manager never knew what they had. The review puts the person's full list in front of the new manager. The manager reads "regional pricing folder, edit" beside the name of someone who now works in compliance and answers remove. That is the decision nobody was asked to make at the time of the move.

Leavers are a different catch with a different tool. The leaver audit, in Finding the Accounts Nobody Disabled, reconciles the directory's enabled accounts against the list of people who have left. It finds accounts that should not exist at all. The access review assumes the accounts on it belong to people who are still here. It asks whether each piece of their access should still exist. The two reviews can share a quarter, and the leaver audit should run first, so that the manager's sheet does not carry the name of someone who left in May. A sheet with a leaver on it is a sheet the manager will stop trusting at that line.

The third thing the review catches is the access nobody requested. This is the entry on a folder that arrived through an untangling, a migration or a well-meant copy, with no ticket behind it. Those lines carry "no record of a request" as their reason. Managers remove them at a higher rate than any other kind. That is a small embarrassment for the desk and a large improvement in the organisation's exposure. Count them, by quarter, as one of the numbers in the report. A falling count of untraceable lines is the review and the request process working together.

Service Accounts and Shared Accounts

A service account is an account that a system uses rather than a person. The system uses it to run a scheduled task, connect one application to another or back up a database. It is on the review because it has access, often a great deal of it, and no manager. Every service account has an owner, a named person responsible for the system it serves, recorded on the register. The owner's review question is three questions instead of one: is this account still needed, is it still being used, and who holds its credential. The desk does not ask what the credential is, and the review sheet has no field for it. The question is whether the owner knows where it is kept and who can reach it, which is a different and safer question.

Service accounts tied to a person are the ones to find. That is because a scheduled task that runs under a departed administrator's own account stops when the leaver audit disables them, usually at month-end, usually at two in the morning. The offboarding series covers that discovery as part of the leaver work. The access review is where the remaining ones surface. Any account on an owner's list that is actually a person's account doing a system's job gets a line that says so. It also gets a ticket to replace it with a proper service account before the next quarter. Owners are generally surprised to learn how many of these they have. The scheduled tasks are not surprised at all; they have been running under a person's name for years and would carry on happily until the person left.

Shared accounts, where several people know one login, are reviewed the same way. The additional question is whether the sharing is still necessary or whether the system has since grown a way to give each person their own. The answer to the second is usually yes and usually nobody had checked. A shared account whose owner cannot say who knows the password is an account whose password is changed that week. That is not a punishment. It is the only way to make the next answer to the question true.

Acting on the Answers

Every remove becomes a removal within a week of the reply. The manager is told when it is done. That is because a review whose removals happen a month later teaches managers that their answers do not matter. One ticket per manager holds the reply. The removals are made as a batch against that ticket. Each removal is recorded in the ticket as the exact group or role taken from the exact account. That way, the evidence for the quarter is a set of tickets, one per manager, each carrying the manager's own words and the desk's actions beneath them. If you run QuerySolv, the ticket's complete event history holds the sheet going out, the manager's reply and each removal in order. In QuerySolv, the per-manager tickets link to one parent ticket for the quarter. That way, the auditor's question "show me the review" is answered by opening one ticket and following the links. In any tool, the test is the same: the evidence is the reply on the record, not a folder in somebody's mailbox.

Some removals break something. The desk should expect two or three a quarter and treat them as the review working rather than the review failing. A manager removes a folder their report turns out to use weekly. The report raises a ticket on Thursday. The desk restores it as an ordinary request with the five questions answered and a reason the next review will show. Nothing has been lost but a morning, and the access now has a record where it had none. The removal that breaks something was access nobody could explain; the restoration is access somebody can. The alternative, leaving everything in place in case it is used, is how the forty-page list was built.

Keep the reply even when it is all keep. A manager who read forty lines and kept all forty has made forty decisions. The reply that says so, on the ticket, is the evidence that the review was done. That is what the auditor's letter asked for in the first place. The quarter's parent ticket closes when the last manager's ticket does. Its closing note has four numbers on it: managers asked, managers completed, lines reviewed, lines removed. Those four numbers, next to last quarter's, are the report line. The sixth article in this series puts them beside the rest of the access numbers.

Sized for a Small Organisation: A Worked Example in Hours

The hours below are Bluewater's, from Hannah's first properly designed quarter. They are a worked example from one fictional organisation of about a hundred and forty staff, nineteen managers, thirty top-level shares and a dozen applications with roles. Your numbers will differ, and the shape is what to copy. Preparation took the desk between six and eight hours the first time. That involved building the translation from groups to plain names, pulling each manager's reports and their access, writing the reason beside each line from the tickets, and leaving off the base access and the bundles. The second quarter the same preparation took three to four hours, because the translation was already in the register and only the changes needed adding.

The managers' time was between a quarter of an hour and half an hour each, for lists of between twenty and sixty lines. The two managers with more than a hundred lines each took closer to an hour. Both asked, reasonably, whether some of their lines could become a bundle, which they could and did. Chasing took the desk about an hour across the quarter, in short messages on a fixed day. Removals took between four and six hours in the first quarter, for a little over a hundred and twenty lines removed from about seven hundred reviewed. Removals took about two hours in the second, for forty from the same seven hundred. The first quarter's total for the desk was somewhere between twelve and sixteen hours. The second was between six and eight. That is a day and a half a quarter to answer the auditor's letter and to know that a hundred and twenty pieces of access nobody needed were gone.

The number that fell fastest was the untraceable line. Ninety lines in the first quarter carried "no record of a request", and seventy of those were removed. In the second quarter there were eleven, because the request process had been running in between and the review had cleaned the backlog. The hours are modest and the ranges are honest. A larger organisation scales the manager count and not much else, and a smaller one with five managers can run the whole thing in an afternoon. What does not scale is skipping the preparation: a review sent raw is forty pages, and forty pages is nineteen managers doing nothing.

A Short War Story: The Looks-Fine Review at Oakhill Veterinary Group

At Oakhill Veterinary Group, six practices under one management company, the annual access review was a spreadsheet export sent to each practice manager. A practice manager called Deborah, who had eleven pages and a waiting room, replied "looks fine" without opening it, as she had the year before. On page seven was a locum vet called Stefan, who had covered the practice for six weeks a year earlier. His account had never been disabled because the locum agency and not the practice had ended the contract. His membership of the clinical records group had therefore never been questioned by anyone. Stefan, now in a permanent post at a competing practice, discovered eleven months after leaving that his old login still worked. To his credit, he telephoned Oakhill to say so. The management company spent about fifty hours establishing what had been accessed, which was nothing. It notified its regulator anyway, and rebuilt the review from a one-page, keep-or-remove sheet per practice that could not be completed without a decision on every line. Deborah's first sheet under the new design had fourteen lines and took her twelve minutes, and she removed three. A review that can be completed without reading it will be, and "looks fine" is not a decision; it is a signature on a page that was never turned.

The Access Review Sheet

The sheet below is the one Hannah sent to each of the nineteen managers, prepared by the desk and sent on a ticket of its own with the deadline in the first line. The first block is the three-line instruction, which is all the manager reads before the list. The second is the list, one person at a time. Each line is a piece of access in plain words with the reason it was granted and a keep-or-remove box. The third is the service and shared accounts for owners, with their three questions. And the last is the desk's record of what was done with the answers. There is no box at the bottom that confirms the whole page. Managers reply to the ticket with the sheet marked, or with a sentence naming the lines to remove, and either is a completed review.

ACCESS REVIEW — ONE SHEET PER MANAGER
Quarter: ________   Manager: ______________   Sent: ________   Reply by: ________
Ticket: ________

HOW TO COMPLETE THIS (three lines)
  For each line, mark KEEP or REMOVE. Not sure means REMOVE; it can be restored in minutes.
  Standard access for the person's role is one line; the role's contents are on the reference page.
  Reply to this ticket with the sheet marked, or with "all keep except lines __".

PERSON: ______________________   Role: ______________________
  #  Access (in plain words)                     Level    Granted for (reason / date)         KEEP  REMOVE
  1  ________________________________________   ______   ______________________________      [ ]   [ ]
  2  ________________________________________   ______   ______________________________      [ ]   [ ]
  3  ________________________________________   ______   no record of a request               [ ]   [ ]
  4  Standard access for role: ______________   —        role bundle, reviewed by its owners   [ ]   [ ]

PERSON: ______________________   Role: ______________________
  #  Access (in plain words)                     Level    Granted for (reason / date)         KEEP  REMOVE
  1  ________________________________________   ______   ______________________________      [ ]   [ ]
  2  ________________________________________   ______   ______________________________      [ ]   [ ]

(repeat for each direct report)

SERVICE AND SHARED ACCOUNTS YOU OWN (owners only)
  Account: ______________   System it serves: ______________
     Still needed?  [ ] yes  [ ] no      Still used?  [ ] yes  [ ] no  [ ] unknown
     Who can reach its credential, and where it is kept: ______________________
     Runs under a person's own account?  [ ] no  [ ] yes: replace by ________

DESK USE — AFTER THE REPLY
  Reply received on: ________   Lines reviewed: ____   Lines removed: ____
  Removals made on: ________   By: __________   Each recorded on this ticket:  [ ]
  Manager told removals are done:  [ ]      Linked to the quarter's parent ticket:  [ ]
  Lines restored by request within the quarter: ____  (each on its own ticket with a reason)

Seventeen of the nineteen managers replied inside the two weeks, one after the reminder, and one after a conversation with his own manager that Hannah did not have to attend. A hundred and twenty-three lines came off. Three went back on within the week with reasons. The auditor, the following year, read one parent ticket and nineteen linked ones and wrote a different letter. The forty-page spreadsheet is still in a folder somewhere, unopened, which is the most anyone ever did with it.

Frequently Asked Questions