The Auditor Who Has to Be an Administrator
An external auditor asks for read access to the audit log. The smallest permission that opens it also opens settings administration — so granting the narrow thing they asked for means granting a great deal they did not.
The short version
The audit log here is properly protected and there is exactly one key to it, and that key is a broad administrative grant. If somebody needs to read the log and nothing else — an auditor, a compliance officer, a board member, an investigator — there is no way to give them that today without also giving them settings administration. Two permissions built for precisely this purpose sit in the role editor and govern nothing.
Least privilege is the easiest security principle to state and the hardest to actually implement, and the reason is almost never the principle. It is that permissions get attached to doors at the moment the door is built, by whoever is building it, using whatever grant is nearest to hand.
Nobody decides that reading an audit log should require the ability to change system settings. It simply ends up that way, and then it stays that way, because nothing about it looks wrong from the inside.
What the audit log is, and what it is worth
It is the record of who did what. It has three actions — read it, export it, and verify it — and that third one is worth pausing on, because it is unusual.
Verifying means checking the log against itself: each entry is chained to the one before, so an entry removed or altered in the middle breaks the chain and the check reports it. That is a genuine integrity control and most systems do not have one.
It is worth being precise about what it is not, since we have written about that elsewhere: the log is protected by access control and by that chain rather than by being physically unwritable, and the data-erasure routine deliberately rewrites actor names when somebody exercises a deletion right. So it is a strong record, not a tamper-proof one, and we would rather say that than let "audit log" imply more than it should.
Three actions, one key, and the key is the wrong size.
Why the grant is the problem
All three actions are governed by the permission that covers settings administration. Hold it and you can read the log, export it and verify it. Hold anything else, whatever else it is, and you cannot.
Which produces a choice nobody wants to make when an auditor arrives and asks for exactly the narrow thing an auditor should ask for.
You grant settings administration
They can read the log — and administer settings
The auditor now holds a grant far wider than their engagement. In a controls review this is itself a finding, and it is a finding you created in order to satisfy the review.
You withhold it
They cannot read the log at all
So somebody internal runs the export and hands it over. Which works, and means the evidence reaches the auditor through the very team whose actions it records.
Neither is satisfactory, and the second one is the one everybody actually does. It is also the one that quietly weakens the evidence: an audit trail extracted and passed on by an interested party is a weaker artefact than one the auditor pulled themselves, and any auditor worth the fee will say so.
The part that makes it clearly an oversight
Two permissions already exist for this. They are named for reading logs, they appear in the role editor, they can be granted, withheld, saved and reported on — and no code anywhere consults either of them. They were defined when the area was designed and never wired to the door.
So an administrator building a read-only auditor role will find exactly the checkboxes they were looking for, tick them, save, and hand over an account that cannot open the audit log. Nothing tells them. We have written separately about that pattern and how widespread it is — five permissions on one screen and one of them working — and this is the instance of it with the sharpest consequence, because the whole point of an audit log is that somebody outside the operation can read it.
What to do about it now
-
Decide who genuinely needs standing access
Usually one or two people, and usually people who already hold administrative rights for other reasons. For them the current arrangement costs nothing, and that is worth establishing before you treat this as urgent.
-
For an engagement, export rather than grant
Run the export yourself, verify the chain while you are there, and hand over both. The verification result is the part that answers "how do we know this is complete", and it travels with the file.
-
Record who exported it and when
In your own engagement notes. It is the fact an auditor will ask for and the one the handover method makes least visible.
-
Ask for the narrow grant before you need it
A read-only audit permission is a small, well-defined change. It is much easier to arrange in the quiet month before a review than in the week of one.
Four questions for any system you will be audited on
Can I give somebody read-only access to the audit log?
What you will hear
Yes, and it is usually believed.
How to read it
Ask them to build the role in front of you and log in as it. This is a five-minute test and it is the only one that distinguishes a permission that exists from a permission that works.
What is the smallest grant that opens the audit log?
What you will hear
A specific permission name.
How to read it
Then ask what else that permission opens. That second question is the whole of least privilege and almost nobody asks it, because the first answer sounds complete.
Can the log be checked for completeness?
What you will hear
Often not.
How to read it
A chain or signature that can be verified is a real control and worth a lot in a review. Ours has one, and it is governed by the same oversized key as everything else here.
Who can delete or alter an entry?
What you will hear
Nobody, usually.
How to read it
Press on the erasure path specifically. Most systems that must honour deletion rights alter audit records somewhere, and the honest ones can tell you exactly where and why.
What AWRA OpsHub does today
- A record of who did what, readable, exportable, and covering the actions across the modules.
- A verification action checking the log against its own chain, so an entry removed or altered from the middle is reported rather than assumed away.
- Access behind a real permission, enforced on reading, exporting and verifying alike, with no path that skips it.
- A record of report exports and views alongside it, so the act of extracting evidence is itself evidenced.
More we can add to your workspace
- A read-only audit permission, so an auditor or compliance officer can be given the log and nothing else. The two permissions named for this are in the role editor waiting to be wired to the door.
- Export as a separate grant from reading, so somebody can review the log on screen without being able to take a copy away.
- Time-boxed access for an engagement, lapsing on a stated date rather than on somebody remembering to remove it.
- A scope on audit access, limiting a reviewer to one module, one project or one date range.
Where we point you to a specialist
- The audit log stays behind a permission and we would argue against any arrangement that opens it more widely to solve this. The answer is a smaller key, and a log readable by everybody would end the problem by removing the control.
- What your auditor is entitled to see is a matter for your engagement letter and your data-protection obligations. We would build the scoping you specify and would decline to decide on your behalf which records a reviewer may read.
- We will keep saying that the log is protected by access control and a verification chain rather than by being physically unwritable, because the difference matters to anybody relying on it as evidence, and "audit log" is a phrase that invites people to assume the stronger thing.
A read-only audit permission, export as a separate grant, and time-boxed reviewer access are one small piece of work we can scope and quote on.
Three, and the first is genuinely half a day
The permissions already exist in the role editor. What has to change is which permission the door asks for.
A read-only audit grant
Wire the existing read permission to the log so an auditor role can be built that opens the log and nothing else. The smallest change on this page and the one with the largest effect on a controls review.
Export split from reading
Reading a log on screen and taking a copy off the premises are different acts with different risk, and today one grant covers both.
Access that expires
A grant with an end date, for the engagement rather than forever. This is the control that stops last year's auditor still having access this year, which is the finding that turns up in every second access review.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. If you have an audit, a certification or a lender review coming, the first item is the one to raise and it is small.
Talk to us about access controlBuild the auditor role today
In whatever system holds your records. Create it, grant only what a reviewer should have, sign in as it, and try to open the audit log. Whatever happens next is worth knowing before somebody external asks you for exactly that.
Talk to us about audit and compliance