Access Review

Access is granted and abandoned under very different conditions. Granting it is an event: somebody asks, somebody approves, and a record exists. Losing the need for it is not an event at all. When a person moves to different work and stops opening a system, the account stays exactly as it was, and often the person themselves forgets they can still get in.

So as a company grows, access only accumulates. Someone who has moved through three teams in two years holds permissions from all three. A contractor who worked for two months still has repository access half a year later. None of this produces symptoms on an ordinary day. It shows up all at once when a single account is compromised, because the reach of that account is the size of the incident.

Temporary grants make it worse. Access to the production database "just for today" to look at an outage does not end that day. Nobody thinks to ask for it back, and the person who could remove it has no way of knowing whether it's still in use, so it stays.

An access review hands this work to the calendar instead of to memory. Rather than waiting for someone to report a stale permission, it pulls the full list every quarter and asks, line by line, whether each entry is still needed. What a review finds is not a breach but old access, and that's the point.

A single round moves through six steps.

1. Pick the scope — choose the systems for this round from the asset inventory, the table listing the systems and data the company has to protect. Anything missing from that table drops out of the review too, so the first check is whether the tools individual teams bought on a card are listed.
2. Pull the lists — export who currently holds which permission in each system. Tools behind single sign-on come out of one screen; tools people signed up for separately have to be exported by hand from each admin panel.
3. Send them for confirmation — the list goes to the person who owns that system, not to whoever runs the review. Only someone who understands billing work can say whether the billing analyst needs write access to the payments database.
4. Decide — every line gets one of three outcomes: keep, revoke, or downgrade. Downgrading means dropping write access to read-only, which fits the many cases where somebody needs to look at data but never to change it. Most rounds end up with more downgrades than revocations, because the usual finding is not that a person has no business in a system but that they no longer need to edit anything in it.
5. Revoke — actually remove what was marked for removal. Decisions often stall before they reach this step, so the date and the person who executed it get recorded alongside.
6. Note the exceptions — anything kept gets a written reason and a date to revisit. Entries that survive without a reason survive the next round for the same non-reason.

The records from each step double as evidence. When an auditor arrives for a security certification, what they ask for is this log rather than the policy document. A list showing twelve permissions revoked in the March round carries far more weight than a sentence claiming reviews happen quarterly.

A review needs three roles filled. Someone runs it, pulling lists and chasing deadlines. Someone who administers each system judges whether access is still in use. And a team lead supplies the human context. The coordinator collects judgments rather than making them. Without the system owners, the review becomes a list nobody can answer; without the team leads, permissions belonging to people whose jobs changed in last month's reorg pass straight through.

Timing comes in two forms. One is the calendar review. Quarterly is the common rhythm, tightened to monthly for systems holding customer personal data. The other attaches to events: resignations, reorgs, role changes, and the end of a vendor contract. Departures are usually covered because revoking access sits inside the offboarding checklist and happens on the last day. Role changes have no equivalent checklist, which is why the calendar review catches most of them.

Neither form is sufficient alone. Run only calendar reviews and a departed employee's account can live for three months. Run only event-driven ones and a quarter where nobody left produces nothing at all. The two are usually scheduled together, with the calendar round set a few weeks before whatever audit or certification renewal is coming up, so the evidence is fresh when somebody asks for it.

"The access review list for this quarter is out. Please confirm yours by Friday."

System owners are being asked to judge, and the round stalls until they answer.

"Any account that hasn't logged in for ninety days gets revoked, and people can request it again."

Proposing a default rule for the cases where individual judgment is hard.

"This one has an empty exception reason. We're revoking it this round."

Cleaning up entries that were kept last round without anyone saying why.

At Pagedeck, Grace opens the review in the first week of each quarter. At 45 people there is no dedicated security role, so the CEO runs the process while Theo and the other system owners make the calls. The longest item in the last round wasn't a departed employee but someone who had changed teams three times. Even she couldn't say with confidence which of her permissions her current work required, so she and her lead went through them one at a time and cleared six.

The second round took far less effort. Once the first pass clears out years of accumulated access, every round after that only has to look at what appeared in the last quarter.

Plenty of people read this as deleting the accounts of people who left. The incidents that make the news usually involve former employees, so the association is easy to form. In practice, most of what a review catches belongs to people still at the company. Permissions add up as roles shift and nobody subtracts, so a three-year employee ends up able to open four times as much as a new hire. Left alone, that state turns the principle of least privilege — give each person only the access their current work requires — into a line in a document.

The other misreading is that security should simply decide. It sits under security, so that feels natural. But a list shows account names and permission levels, not what any person does with them. A coordinator deciding alone ends up in one of two places: keeping everything out of uncertainty, or cutting boldly and breaking billing on Monday morning. Either outcome, once experienced, means nobody opens the review next quarter.