· Yair Knijn
The access review that took six weeks of spreadsheet exports and still failed the audit
The GRC lead opens the access recertification ticket in January and treats it like every other year: a project. Pull the user list out of each app, drop it into a master sheet, send tabs to the right managers, chase signatures, file the result. Six weeks of CSV exports and follow-up emails later, the certification is signed. The wrong assumption is buried in the first step. Recertification is being run as a periodic assembly job instead of a query against a single record of who has access to what.
That is why the binder is thick and the audit still fails. The evidence is not wrong because access was wrong. It is wrong because nobody can reproduce how the evidence was built.
Why ISO 27001 5.18 and SOC 2 CC6.2 reviews collapse under app sprawl
ISO 27001 Annex A control 5.18 asks asset owners to review access rights regularly and at every role change and exit, against clear procedures for how rights are assigned, modified, and revoked. SOC 2 CC6.2 wants registration and authorization recorded before access is granted, and CC6.1 expects the whole least-privilege picture to hold together. None of those clauses say "do it once a year in a spreadsheet." They assume there is a system that knows who has access and why.
When identity lives in twelve apps that do not share a record, there is no such system. Each product has its own user table, its own role names, its own export format. The reviewer is reconciling a dozen disconnected lists by hand and hoping the joins are right. The control reads "regularly." The reality is "annually, manually, and approximately."
The stale-export problem: signed-off on data that changed last week
Here is the failure mode an auditor catches. You export the user list from each app on the first of the month. The manager reviews and signs on the twentieth. Between those dates someone offboarded, two people changed teams, a contractor's finance-admin role was added for a project. The signed certification describes a state that no longer exists. You attested to a snapshot, and the snapshot already moved.
A reviewer cannot reason about that. The sign-off is against a frozen export while the live system kept changing underneath it, and there is no timestamped link between what was reviewed and what was true on the day it was signed. That gap is where the finding gets written.
One identity record, one query, one reproducible certification
The fix is structural, not procedural. Stop assembling the review and start querying it. If every grant for a person hangs off one identity record across every product, the recertification is a single read: pull all access for this account, as of this date, with the role and the grant reason attached. Run it on the first, run it again on the twentieth, and the diff is the change you need to explain. That is what "reproducible" means.
- One record per identity, with every application grant attached to it instead of scattered across product tables.
- A point-in-time read, so the certification names the exact date and state it covers.
- A re-runnable query, so the same review run twice produces the same answer or a diff you can account for.
What an auditor actually wants to see in a recertification trail
An auditor is not impressed by volume. They want to know one thing: can you reproduce this on demand. Show me who had access to payroll on the review date, who approved each grant, when it was last touched, and prove the list I am holding is the list the system would generate today. If the answer is "let me re-export from six apps and merge it again," you have already lost, because that re-export will not match the binder.
Run access reviews against a single record instead of a stack of exports and the whole exercise changes shape. In Spot Suite, identity and entitlements for each Customer Environment hang off one record, so a recertification is a query you can run, re-run, and hand to an auditor unchanged, not a spreadsheet you rebuild and hope nobody diffs. See how the estate is structured on our security page.