Audits of access controls follow a familiar routine. The auditor asks for a list of every access change in the period, picks a sample, and for each one asks four questions: who asked, who approved it and on what basis, what exactly was granted, and when and how was it removed? The organisation then spends days reconstructing answers from tickets, chat threads, cloud logs and the memories of people who have since moved teams.
This post describes what a complete access record looks like when it is produced as a side effect of granting access rather than reconstructed afterwards. It walks one sampled change from the demo organisation, Northwind Labs, through the evidence an auditor would ask for, and maps the record to the access controls in SOC 2, ISO/IEC 27001 and PCI DSS. It is written for the executives who own those audits and the teams who prepare for them.
In short
- Auditors test four things per sampled change. The request, the approval, the grant as made, and the removal. Missing any one is a finding.
- The record should be written as the work happens. Every request, approval, grant, revoke, signed instruction and agent action is in the audit trail in words, with who and when.
- Time-limited grants make removal evidence automatic. Every grant has an expiry, and the broker’s revocation is recorded like the grant was.
- Reviews produce their own evidence. Each line’s usage, recommendation, decision and resulting revoke, with a CSV export.
- Grants and reviews export to InsightAssure as evidence for access-control controls. The mapping below is a guide; confirm control wording and testing approach with your auditor.
What auditors actually test
Whatever the framework, access-control testing has the same shape. The auditor wants to see that access is granted only with authorisation, limited to what the job needs, protected by strong authentication where it is privileged, removed when no longer needed, and reviewed periodically. They test it by sampling: a set of access changes from the period, a set of leavers, a set of privileged accounts, and the periodic reviews.
For each sampled access change the questions are predictable:
| Auditor’s question | Evidence usually requested | Where it usually lives today |
|---|---|---|
| Who asked, and why? | The request with a business reason or ticket | A ticket, sometimes a chat message |
| Who approved it, and were they allowed to? | Approver identity, time, and the policy that made them an approver | Ticket comments; approver authority rarely documented |
| What exactly was granted? | The permission as provisioned, not as requested | Cloud console or a provisioning log, if kept |
| Was it removed when no longer needed? | Removal date and evidence it happened | Often missing; reconstructed from current state |
| Is privileged access reviewed? | Review records with decisions and follow-up removals | Spreadsheets returned by email |
The most common gap is the last two rows. Granting access leaves a trail because someone needed it. Removing access often does not, because nobody was waiting for it.
Walking one sampled change
Suppose the auditor samples AR-0004 from Northwind’s production access in the period. Sam, an engineer, needed to correct one invoice status in the payments database. Here is the evidence, in the order the auditor would ask for it.
The request. Sam wrote: “write access to fix one invoice status in the
payments database for 30 minutes, OPS-219.” The record keeps the sentence, the ticket
reference OPS-219, the resource it was matched to in the catalogue (payments-db
(Postgres)), the level (Write) and the duration (30 minutes).
Least privilege, with its basis. The Write entitlement’s ceiling was DELETE,
INSERT, SELECT and UPDATE on every table. The least-privilege scoper narrowed it to INSERT, SELECT
and UPDATE on billing.invoices, and that narrowing is recorded as an agent action with
the before and after.
The approval, and why that approver. The risk score was 62, High: production +30, critical +20, write +12, sensitive data +8, 30 minutes −3, first time +5, narrow scope −10. Flow #20, “Write access: the owner approves”, routes to the resource owner, payments.lead. Because the score was over 55, Sam first had to pass a step-up second factor, verified with an authenticator app. The record shows the flow that applied, the score with every factor, the step-up and, once payments.lead decides, the decision with its time.
The grant as made. The grant is executed by the broker, the service Northwind
runs in its own network. For PostgreSQL it creates a login role for this grant alone with
VALID UNTIL set to the expiry and table-level privileges. The signed instruction sent
to the broker and the broker’s confirmation are both in the audit trail. The same pattern is
visible on AR-0008, Priya’s read on the same table during an incident, whose grant detail shows
the Postgres login and SELECT on billing.invoices.
The removal. When the 30 minutes are up, the broker revokes: it terminates the login’s sessions and removes the role. It does this on its own clock, from a local ledger of what it granted, so removal does not depend on the control plane being reachable. The revocation is recorded as an event with its time. If the person finishes early, they can revoke it themselves: Priya revoked AR-0002 early with the note “done — latency is back to normal”, and that is in the record too.
agent:scoper with a timestamp, beside the request, the instruction to the broker and the grant.Each event is recorded as it happens; nothing is reconstructed for the audit.
Mapping the record to the frameworks
The table below shows which parts of the record are typically relevant to the access controls in three common frameworks. It is a guide for preparing evidence, not a statement that any control is met: that is the auditor’s judgement, based on your whole control environment.
| Framework and control | What it is about | Records that typically support it |
|---|---|---|
| SOC 2 CC6.1 | Logical access security over protected information assets | Catalogue with owners and ceilings; flows; broker local policy; no standing admin by design |
| SOC 2 CC6.2 | Registering and authorising users before access is granted; removing access when no longer required | Request, approval and approver authority per grant; expiry and revocation events |
| SOC 2 CC6.3 | Authorising, modifying and removing access based on roles, responsibilities and least privilege | Scoped permission against the ceiling; access reviews with decisions and revokes |
| ISO/IEC 27001:2022 A.5.15 | Access control rules based on business and security requirements | Access flows, routing thresholds, risk weights, ceilings |
| ISO/IEC 27001:2022 A.5.18 | Provision, review, modification and removal of access rights | Grant lifecycle records; quarterly reviews; removals through the broker |
| ISO/IEC 27001:2022 A.8.2 | Restriction and management of privileged access rights | Admin flows (two people, step-up, 1 hour); standing admin discovery and conversion |
| PCI DSS v4.0 requirement 7 | Restrict access to system components and cardholder data by business need to know | Least-privilege scoping per grant; resources holding payment data flagged in the catalogue |
| PCI DSS v4.0 requirement 7.2.4 | Review user accounts and access privileges at least once every six months | Access review campaigns, each line’s decision, CSV export |
| PCI DSS v4.0 requirement 8 | Identify users and authenticate access to system components | Individual identity on every grant (no shared credentials); step-up second factor; sign-in MFA via the identity provider |
Confirm with your auditor
Control wording and testing approaches differ between auditors, QSAs and certification bodies, and between versions of each framework. Use the mapping above to organise your evidence, then agree with your auditor which records they will accept for which control and what sample sizes they will use. InsightKeys produces records; it does not certify compliance.
Reviews and privileged access
Two other tests come up in almost every access audit: periodic reviews and privileged accounts. Both produce their own evidence here.
Northwind’s Q4 production access review has ten lines, each pre-filled with last use, uses
in 90 days and a recommendation; the agent recommends removing six and keeping four. The named
reviewer, security@northwind-labs.com, decides each line before the due date of
23 November 2026. Each removal is a revoke through the broker, recorded like any other. The review
exports to CSV, so the auditor gets the lines, the evidence, the decisions and who made them.
For privileged access, the evidence is the absence of standing admin and the record of how admin is granted when needed. Discovery lists standing administrators and escalation paths; in the demo, four standing admins and one escalation path. Each is either converted to on-request access or accepted with a reason. Admin in production goes through flow #30: two named approvers, never the requester, a ticket, step-up, one hour at most. Break-glass under flow #5 is immediate after step-up, tells security, and is reviewed afterwards.
Into the compliance programme
Most organisations do not want access evidence in yet another tool. Grants and reviews export to InsightAssure, VerticalServe’s compliance product, as evidence for access-control controls, so they sit beside the rest of the control evidence the compliance team manages. For teams that do not use InsightAssure, the audit trail and the review CSV export can be provided to auditors directly.
Walk through one request record, one review and the audit trail with the auditor before fieldwork. Agree which records cover which controls.
Requests and grants in the period, standing access found by discovery, and review campaigns. State which systems are in scope.
For each sampled grant: the request, scope, risk, approval, grant and revocation are on one page and in the trail.
Export each campaign to CSV; show removals as broker revocations.
Accepted standing access with its reasons; break-glass grants with their after-the-fact reviews.
Send grants and reviews as evidence for the access-control controls in the compliance programme.
Honest limits
The record covers access that goes through InsightKeys: AWS, PostgreSQL and Kubernetes today, with Google Cloud, Azure, MySQL, Snowflake and others on the roadmap. Access granted outside it is not in the record, so the audit population must say what is in scope. Ticket references are recorded but not yet validated against Jira or ServiceNow (planned). Session recording for SSH and kubectl is on the roadmap; today session watch works from activity logs such as CloudTrail, database activity and Kubernetes audit.
For the CISO
Access audits become a review of records that already exist, not a reconstruction exercise.
Removal, the usual gap, is evidenced for every grant because every grant expires.
For the platform lead
No one rebuilds a quarter’s access history from tickets and chat before fieldwork.
Agent actions are sampled exactly like human ones, with the same detail.
For the board
Fewer access findings, and less senior time spent explaining them.
A clear line from each control to the record that supports it, held in the compliance programme.
The best audit evidence is written at the moment access changes, not the week before fieldwork.
Record the request, the scope, the approval, the grant and the removal as they happen, in words, with who and when, and hand the auditor the record rather than a reconstruction.