Origin
A compliance lead at a fintech customer walked Pranay, one of our founders, through a quarterly access review from her side of it. Nobody involved believed the output meant anything. She also couldn't name one thing she'd do differently with the tooling she had.
The spreadsheet arrives on a Tuesday. Four hundred rows. Employee name, application, permission level, date granted. Thirty managers get it with a note from compliance asking them to review their team's access and confirm or flag by end of week.
Five business days.
Most managers approve every row, and it isn't because they're careless.
Look at what they were handed. The sheet tells them what access exists. It doesn't say what that access does. Half the permission values are strings like prod-rw or Admin_2 that mean something to the person who configured the app and nothing to a sales manager. There's no last-used date. No note on who else holds the same grant. No indication of whether the permission was part of a role template or requested for a project that ended in 2024.
Approving is one click. Questioning is a meeting. To question a row, the manager has to find the original request, work out the scope of the permission, pull in IT to investigate, then make a call that might break someone's Thursday. All of it inside five days, during a week that already has a roadmap review and a hiring decision in it.
Under those conditions, approving everything is the correct move. It's the only option that can't be wrong today.
This gets framed as a discipline problem. It's an incentive problem, and the incentives are working exactly as designed.
The reviewer who approves a bad row faces no consequence this quarter. The reviewer who revokes a good one gets an angry message and a broken workflow with their name attached. Nobody rubber-stamps because they're lazy. They do it because the sheet gives them no way to be right and every way to be blamed.
The review was built to produce a timestamp. It produces one, reliably, every quarter.
The auditor receives the completed sheet. Review: conducted. Evidence: on file. Finding: compliant. Every permission that existed before the review exists after it.
The second problem is scope, and it's structural.
The sheet covers the applications the identity system can see, which is the SSO-connected subset. Everything else is absent. Not marked as an exception, not flagged as out of scope. Absent, in a way that reads as clean. The dashboards, the repos on a standard plan, the tool the product team adopted last year that doesn't do SCIM, the IAM roles outside your federation, the service accounts with nobody's name on them.
A review that covers the apps you happened to be able to include isn't a review of your access posture. It's a review of your integrations.
What a review is nominally there to catch is drift. Drift is close to invisible on a sheet like this one.
Somebody moves from support into a revenue role. They get the new permissions on day one because someone had to unblock them. The support tooling access stays, because nothing takes it away and it isn't anyone's job to notice. Two moves and two years later they hold the union of every role they've ever had, and each individual grant in that union was approved by a reasonable person for a reason that was good at the time.
The sheet shows the union. It doesn't show the history, so nothing about it looks wrong. The manager isn't staring at an anomaly. They're reading a list of items that all sound plausible, because each one separately was.
A review that can actually find something wrong looks different in one specific way: every row carries its own evidence.
What the permission grants, in words a manager can read. When it was last used. Who else has it. What breaks if it comes off. With that on the row, the manager can be right, and the question stops being please confirm and becomes this hasn't been used in ninety days, still needed. Unused defaults to revoke, so nobody has to volunteer for the argument. And the review runs by exception across the whole population rather than as a full sweep of the part that was easy to export.
That last one is where the honest limit sits. Attaching last-used data and ownership is straightforward. Getting what breaks if you remove this right, across a few hundred apps, is not, and we're partway through it rather than finished.
An auditor will accept either version. The timestamp is identical, the finding reads the same, the evidence file is about the same size. The only thing that differs is whether any access came off at the end, and there's no field on the form for that.
So ask your own team what the last review removed. If the answer is nothing, the environment isn't clean. The review just couldn't have found anything.
We'd run one review cycle on your stack with the evidence attached, and you can compare it to your last one. No deck. Just the product.