Every quarter, somewhere in most organisations, a spreadsheet goes out. It lists who has access to what, extracted by hand from a dozen systems a week earlier. Managers are asked to tick Keep or Remove against names they half recognise and permissions they cannot interpret. Most tick Keep on everything, because removing access that turns out to be needed is the only way to get into trouble. The spreadsheet comes back, the review is marked complete, and very little changes.
This post walks through the alternative using the demo organisation, Northwind Labs, and its Q4 production access review: ten lines, each pre-filled with when it was last used, how often in the last 90 days, and an agent’s recommendation with its reason. The reviewer decides each line, removal goes straight to the broker, and the record is ready for the auditor.
In short
- Certification fatigue is a design problem. Reviewers keep everything when they lack evidence and removal is risky. Give them usage and make removal clean.
- Every line arrives pre-filled. Last use, uses in 90 days, whether it is standing or a time-limited grant, and Keep or Remove with a one-line reason.
- The person still decides. The access reviewer agent recommends; the named reviewer clicks Keep or Remove, line by line or by taking the recommendations.
- Remove means removed. A removal is a revoke instruction to the broker in your network, not a ticket to someone else.
- In the demo: 10 lines, 6 recommended for removal, 4 to keep. Four of the six are standing administrators nobody has used for weeks or months.
Why access reviews become rubber stamps
User-access reviews exist because every major control framework asks for them, and for a good reason: access accumulates. People change teams, projects end, a contractor’s role outlives the contract, an emergency account created for one weekend is still there two years later. Periodic review is the control that catches that drift.
data
Periodic review of access rights is an explicit requirement in the main frameworks. PCI DSS v4.0 requirement 7.2.4 asks that user accounts and their access privileges be reviewed at least once every six months; ISO/IEC 27001:2022 Annex A control 5.18 covers the provision, review, modification and removal of access rights; SOC 2 auditors test the logical-access criteria CC6.1 to CC6.3, which commonly include periodic access reviews. Confirm the exact wording and frequency with your own auditor or QSA.
Sources: PCI Security Standards Council, PCI DSS v4.0; ISO/IEC 27001:2022 Annex A; AICPA Trust Services Criteria (2017, revised points of focus 2022).
The control fails in practice for three reasons. The reviewer has no evidence: the line says “PowerUserAccess, prod-core” but not whether anyone has used it this year. Removal is expensive: ticking Remove creates a ticket for another team, which may take weeks and may break something. And the incentives are lopsided: keeping unneeded access has no visible cost to the reviewer, removing needed access has a very visible one. Put those together and Keep becomes the default answer, whatever the line says.
Names and role names, no usage, two weeks to complete. Remove raises a ticket for another team. Evidence is the returned spreadsheet.
Every line with last use, uses in 90 days and a recommendation. Remove revokes through the broker. Evidence is the campaign record and its export.
Setting up the campaign
A review campaign has a scope, a reviewer and a due date. Northwind’s security team created
the Q4 production access review with the scope “prod · standing · grants
90d”: all standing access to production resources, plus every time-limited grant from the
last 90 days. The reviewer is security@northwind-labs.com and the review is due on
23 November 2026.
Including the recent time-limited grants as well as standing access is deliberate. Grants are already short-lived, but reviewing them shows whether the flows are working: which grants were automatic, which were flagged, and whether anyone is repeatedly requesting the same access in a way that suggests a role should be redesigned.
The scope deserves thought. A review that covers everything every quarter recreates the spreadsheet problem with better data. A review that covers only production standing access and recent grants keeps the line count small enough that the reviewer can genuinely look at each one, and puts attention where the exposure is. Lower environments can be reviewed less often, or in a separate campaign with a different reviewer. The choice of reviewer matters too. A central security reviewer, as here, brings consistency; resource owners bring context about who still needs what. Many organisations use both: owners for their own resources, security for anything that is standing administrator access.
Every line, pre-filled
When the campaign opens, the access reviewer agent fills each line. It reads the discovered standing access, the grant history and the session activity, and writes three things: last use, uses in the last 90 days, and Keep or Remove with a reason in plain words. It runs at L3 by default, which here means it fills in recommendations and says so; it does not decide anything. The reviewer does.
Here are the lines in the demo, as the reviewer sees them:
| Who | Where | Access | Usage | Agent says |
|---|---|---|---|---|
| alex.ops | prod-payments | AdministratorAccess (standing) | Last used 14 Jul 2026; 0 uses in 90 days | Remove: standing admin unused for 118 days — request it when needed |
| breakglass-admin | prod-core | AdministratorAccess (standing) | Last used 23 Apr 2026; 0 in 90 days | Remove: standing admin unused for 200 days |
| insight | payments-db (Postgres) | SUPERUSER, BYPASSRLS, CREATEROLE (standing) | Never used | Remove: standing admin never used |
| jordan.dev | eks-prod/payments | cluster-admin via ClusterRoleBinding (standing) | Last used 25 Sep 2026; 0 in 90 days | Remove: standing admin unused for 45 days |
| legacy-migration | prod-core | s3-all (standing) | Never used | Remove: never used |
| priya.sre | prod-payments | read (time-limited grant) | Last used 5 minutes ago; 1 use in 90 days | Remove: active, with 1 flagged action |
| ci-deployer | prod-core | deploy (standing) | Used today | Keep: used 0 days ago |
| morgan.lead | prod-core | PowerUserAccess (standing) | Used 3 days ago | Keep: used 3 days ago |
| … two further lines | Keep |
Four of the six removals are standing administrators: an operations engineer’s admin on
the payments account, an old break-glass account, a developer’s cluster-admin, and a database
superuser role that has never logged in. Each is exactly what an attacker hopes to find. The fifth
is a migration role with access to every S3 bucket in prod-core that was never used. The sixth is
the interesting one: Priya’s current read grant on prod-payments, recommended for removal not
because it is unused but because session watch flagged a call during it — the
secretsmanager:GetSecretValue attempt on the payment provider’s key, which AWS
denied.
The reviewer decides
A pre-filled recommendation is not a decision, and it should not look like one. The reviewer has three ways to work.
10 lines, 0 decided, agent says remove 6. Filter to Undecided or to Remove to work in batches.
Priya’s flagged grant: talk to Priya, or check the session events, before removing. ci-deployer: kept on usage, but it is also on the standing-access list as an escalation path.
Click Keep or Remove on each line, or “Take 10 recommendations” to accept all ten agent suggestions at once and then change any you disagree with.
Each Remove becomes a revoke through the broker in Northwind’s network: the permission set assignment, the role, the database role or the RoleBinding is removed.
Mark the review complete. Export CSV for the evidence pack; send grants and reviews to InsightAssure if it is in use.
The second step matters more than the others. Usage is strong evidence that access is needed; it is not evidence that access is safe. The ci-deployer role is used every day, so the reviewer agent recommends Keep. But discovery also found that it can escalate to administrator by passing a role to a new Lambda function and invoking it. The right outcome is probably to keep the deployment capability and narrow the role, which is a standing-access cleanup proposal, not a review decision. A good reviewer reads both.
standing access"] --> L["Review lines"] G["Grant history
last 90 days"] --> L E["Session events
flags"] --> L L --> R["Access reviewer
pre-fills Keep or Remove"] R --> H{"Reviewer decides"} H -->|"Keep"| K["Kept, reason recorded"] H -->|"Remove"| B["Revoke through
the broker"] B --> V["Removal recorded
in the audit trail"] K --> X["CSV export and
InsightAssure evidence"] V --> X
From evidence to decision to removal to record, in one place.
Removal without a ticket
The biggest practical change is the last step. In most organisations, the reviewer’s Remove is the start of a second process: a ticket to the cloud team, another to the database team, a follow-up a month later to confirm. Auditors know this, which is why they test not just that a review happened but that the removals were carried out.
Here, Remove calls the broker. The broker is the small service Northwind runs in its own network; it holds the credentials that can change permissions, and it removes the access directly in AWS, PostgreSQL or Kubernetes. The removal is recorded in the audit trail beside the reviewer’s decision. Converting a standing admin to on-request access does not leave its owner stranded: the next time alex.ops needs admin on prod-payments, they ask, and flow #30 decides.
What it changes
The most visible change is time. A reviewer facing ten lines with usage and a reason already written can work through them in one sitting, spending real attention only on the two or three that need judgement. The less visible change matters more: removals actually happen. A review that removes four standing administrators in a quarter has reduced what a stolen credential could do in production. A review that keeps everything has produced a document.
The review also feeds the rest of the programme. Each standing admin removed is one fewer item on the standing-access list and one fewer on the board’s count. Each repeated grant to the same person for the same task is a hint that a flow or ceiling could be tuned. And each line where the reviewer overrode the agent is a signal about how well the recommendations fit the organisation.
| Spreadsheet review | Pre-filled review | |
|---|---|---|
| Preparation | Extract from each system by hand | Campaign scope set once; lines filled from discovery and grant records |
| Evidence per line | Name and role | Last use, uses in 90 days, standing or grant, flags, reason |
| Reviewer effort | Research each line or tick Keep | Read the recommendation, check the few that need judgement |
| Removal | Ticket to another team | Revoke through the broker, recorded |
| Audit evidence | The returned spreadsheet | Campaign record, decisions, revocations, CSV export, InsightAssure |
For the CISO
Reviews start removing access again, because the reviewer has evidence and removal is clean.
The record shows who decided each line, on what evidence, and when the broker removed it.
For the platform lead
No extraction scripts, no follow-up tickets, no chasing the database team to confirm.
Standing admins found in review feed straight into conversion to on-request access.
For the board
A control that is often a formality becomes one that measurably reduces standing privilege each quarter.
The number of lines removed and confirmed is a meaningful quarterly figure; the completion rate alone is not.
Where this stops
Lines come from what InsightKeys discovers and grants: AWS accounts and IAM, PostgreSQL, Kubernetes. Access in systems it does not yet cover — Google Cloud, Azure, Snowflake, GitHub and others are on the roadmap — still needs your existing process. The agent’s recommendation is driven mainly by usage and flags, so it can recommend keeping access that is used and still too broad, as with ci-deployer. Taking all recommendations in one click is efficient; your auditor may want to see that the reviewer looked at each line, so record a short reason where you differ from the agent.
A review is only a control if it removes something.
Give the reviewer the evidence, keep the decision with a named person, and make Remove mean removed — through the broker, on the record, the same afternoon.