Everyone Who Could Sign on the Thirty-First

The request arrives on the second morning of fieldwork, typed into the shared list between “bank confirmations” and “fixed asset additions”. Please provide a list of all users able to approve payments, create or amend suppliers, change supplier bank details or post journals, as at the thirty-first of December. Please also provide all changes to user roles and permissions during the year, with who made each change; a list of leavers with their leaving date and the date their system access was removed; any shared or generic accounts; and a record of any access by your software provider’s support staff.

It is the eleventh of February. The role editor shows who can approve payments today, which is not the question. Two people have changed roles since January, one held payment approval for a fortnight of holiday cover, and nobody is sure when the warehouse leaver’s login stopped working.

This post is about answering it with evidence rather than a spreadsheet assembled from memory: what each part asks for, what AWRA OpsHub records, what nobody can quietly alter afterwards, and what to do in the last week of December so the answer already exists.

Five questions hiding in one request

An access request reads as one task. It is five, and they need different evidence because they ask about different moments in time.

The first question is the one people usually get wrong, and the reason is timing. A list of who holds what, printed in February, describes February. To describe the thirty-first of December you need something written down on that day that nobody has touched since.

Take the snapshot on the day, not after it

In AWRA an access review is a campaign that starts with a snapshot. When someone with the access review permission starts one, the system works out every in-scope person’s effective access at that moment — their permanent role, any temporary role still running, the permissions those roles carry within your plan, and any risky pairs of permissions they hold together — and writes it into the review. From then on the review is a record of what was true when it started. Change a role tomorrow and the review still says what it said.

1. Start the review on the balance sheet date

   Open Access Reviews, name it for the year-end, and choose its scope: all active users, or everyone holding one role. Choosing a role also brings in anyone holding that role temporarily on the day. Set a due date for the decisions.

2. Read each line

   Every person appears with their roles, any temporary role and when it ends, the full list of permissions on screen, the risky pairs they hold, and their last sign-in on the web. Filter to the lines with conflicts first.

3. Decide keep or revoke

   Keep changes nothing; the decision and any note are the evidence. Revoke needs a note and ends the person’s access at once: account deactivated, signed out of every browser and device, temporary roles ended. Nobody decides their own line.

4. Let it close itself

   Decisions are final once made. When the last line is decided the review marks itself complete. A completed review refuses further changes.

5. Export it for the file

   The export is a spreadsheet with one row per person: the review, its scope, who started it and when, the person, their roles and temporary roles, permission count, conflicts, last sign-in, the decision, the note, and who decided it when. The export itself is written to the audit trail.

Who could approve a payment, specifically

The auditor’s list names actions and the review lists permissions, so map one to the other once; how to design the roles themselves is in Roles & Permissions: Deciding Who Can See What. In the role editor the relevant grants are worded much as the auditor words them: approving payment runs, adding and editing suppliers, creating and approving journal entries. Supplier bank details are edited with the supplier; a workspace can require a second person to apply any change to them, and the supplier is emailed whenever they change.

Two features shorten the job. The first is the review scope: start one review for the role that carries payment approval and you have, as at the date, exactly the people who held it, temporary holders included. The second is Access Conflicts, which lists every role and every person holding one of twelve risky pairs — raise a purchase order and approve it, create a supplier and approve a payment run, capture a bill and approve it, edit employees and run payroll, edit roles and approve payment runs, and others. Conflicts warn rather than block, because a five-person finance team often cannot separate these duties at all.

An auditor does not expect a small team to have no overlap. They expect the overlap to have been seen, decided by someone else, and written down on the day.

Every change in the year, and who made it

Every change a signed-in person makes, on the web or through the mobile app, is written to the audit trail with who did it, when, from which address and device, on which screen, and which record it touched. Changes to users and roles land under the Users & Access module, review decisions under Access Governance, and sign-ins under Auth. The audit trail can be filtered by module, action, person and date range and exported as a spreadsheet or JSON, and the export itself is recorded.

What makes that trail worth handing to an auditor is that your own administrators cannot rewrite it. There is no delete button for audit entries, and each entry carries a fingerprint chained to the one before it, so an edited, removed or inserted row shows up when the chain is verified — which anyone with access to the audit log can do from the same screen, and which is itself recorded. We explained the mechanism in An Audit Trail Nobody Can Delete.

Read the middle column carefully, because it decides how you prepare. The trail proves that a person’s user record was changed on a date by a named colleague. It does not spell out “from Storekeeper to Accounts Payable”. The fix is cheap: run access reviews quarterly. Two snapshots read side by side show what each person gained and lost, and the trail says who made each change and when.

Temporary access is the exception, and the best-documented change in the system. A temporary role needs a reason, an end date within 180 days and someone other than the recipient to grant it; it ends by itself, and the grant, the end and why it ended are all recorded. It is the right tool for holiday cover, as The Approver on Leave describes, rather than a role change you meant to undo.

Leavers: the date that matters is the gap

For a leaver the auditor wants two dates and the distance between them. In AWRA the link is direct: when an employee is saved as terminated or archived — from the HR form, an import or the API — the login linked to that employee is closed in the same step. The account is deactivated, every browser session and mobile token is ended, and a remembered sign-in stops working. Reinstating the employee later does not restore the login; that stays a deliberate act on the user screen.

So the access-ended date is the date HR recorded the termination, and the gap the auditor is testing is the delay between the person’s last day and that entry. Two things close it. Record terminations on the day. And where the last day is known in advance, give the login an access end date so it lapses on schedule, as Scheduling an Exit Before the Last Day explains.

Before year-end, open Access Control in HR. It lists employees who have left but still hold an active login, active employees whose login is switched off, and employees who could be given one. Clear the first list before the snapshot, not after.

Accounts that belong to nobody

Shared and generic accounts — “stores”, “finance”, the login the external accountant uses — are where traceability ends, because the audit trail can only name the account. The same Access Control screen has a list for exactly these: active logins with no employee record behind them, with accounts that have never signed in shown first and the rest ordered by how long they have been quiet. Contractors, auditors and administrators created straight on the user screen all appear here, because nothing in HR will ever close them.

Each line is one of three things: a person who should be linked to an employee record, an outsider who should carry an access end date, or a shared login to replace with individual ones. An account shared by three people produces one name in the trail, so it fails the auditor’s question even when everyone behaved perfectly.

Machines count too. API keys are listed under integrations with their scopes, status and last use; each can carry an expiry of up to two years, be rotated or revoked, and creating one is recorded in the audit trail. Keys sit outside the access review, so list them separately.

When support signed in as one of your users

Only our platform team can start a support session, and every request made during one is logged separately: which member of our staff, as which of your users, which screen, from where, when, and a fingerprint of anything submitted. A Hash Is Not a Transcript covers what that log holds and why it keeps a fingerprint rather than a copy.

One thing to know before the auditor reads your own trail: during a support session, your workspace’s audit trail records the session’s sign-in and its changes under the name of the user being assisted. The support log is what tells them apart, and our platform team holds it, so ask us for your workspace’s entries for the year and put them in the file beside the export. A marker on those entries in your own trail is in the list of things we can add, below.

Frequently asked questions