FAIRNESS
The access log nobody can edit
- Published 2026-08-27
- 4 min read
Every time a manager opens a conversation, searches the archive, views media or exports, WAOversight writes an access log entry before the data is returned. Nobody can edit a row, delete one, or switch the log off. Your workspace owner and your auditors read it, and your team is told the archive exists.
The hardest objection to workplace monitoring has never been legal. It is the sentence every manager hears in the rollout meeting: “so you can read everything we write, and we just have to trust you about when.” Most monitoring products have no answer, because the objection is accurate. The manager’s behaviour is the one thing the product does not record.
We built the product around recording it.
What gets logged
Every read of the archive: opening a conversation, running a search, viewing a photo or document, exporting anything. Each one writes a row saying who looked, at what, and when. There is no lighter-touch category of read that goes unrecorded, and export is not a way around it; an export is logged with its scope.
Why the write comes first
The order is the design. The log entry is written before the data is returned, and if the write fails, the read fails: the manager sees an error, not a conversation. That is a stronger claim than “we log access,” which in most products means an asynchronous, best-effort note that usually gets written. Here there is no gap in which someone reads first and the log catches up later, or doesn’t. The mechanics are on the security page; the property to remember is simple. A view without a log entry is not possible, rather than not supposed to happen.
Nobody can edit it
The log is append-only, by the same construction as the message archive itself. There is no setting that turns it off, no admin role that can delete an entry, and no support request that will quietly remove a row for you. Rows are chained, so a missing one is visible as a gap rather than as nothing at all.
That last part is what separates this from an audit trail in most software, where the person with the highest privileges is also the person who can tidy the record of what they did. Here the highest privilege available is the ability to read, and reading is the thing being recorded.
Who reads it
The workspace owner, and any auditor you give access to. It is their record of how the archive is being used: which manager opened which conversation, when, and the reason they gave for it. If someone is reading one rep’s conversations far more than anyone else’s, that pattern is in the log and the owner is the person placed to act on it.
Your reps do not read the log, and we are not going to claim otherwise. What they are told, in writing and before a single number is linked, is that the archive exists, which numbers it covers, and that every manager view of it is recorded. There is no hidden mode in this product and there is no version of it that hides from your team. Those are two different promises from “your reps audit their managers,” and only the first two are ours to make.
The log also outlives the messages: audit records are kept for 3 years, longer than most teams keep the messages themselves, on purpose. “Who was reading these conversations last spring?” is a question the record can still answer after the conversations are gone.
Why this decides the rollout
The rollout conversation changes shape when your own reading is on a record you cannot touch. Without that, “this is about the company’s numbers, not about distrusting you” is a claim your team is asked to take on faith, from the person acquiring the ability to read their messages. With it, the claim is checkable by the owner who signed the policy and by the auditor who reviews it, and your team can be told exactly that.
It belongs in the paperwork, not just the product. When you write your monitoring policy, put the log in as a clause: every view of these conversations is recorded, the record cannot be altered, and here is who reviews it. A fairness guarantee that lives only in a vendor’s feature list is one your team has no reason to believe survives the vendor.
In practice this is the difference between a rollout that produces 3 resignations and one that produces a shrug. We wrote a page for the people being monitored covering what is recorded and what is never touched, precisely so a manager can send it to the team before linking a single number. A product you can show the people it covers is a different product from one you have to explain carefully.
What the log is not
It is not a performance metric. Nobody should be scored on how often their conversations were reviewed, and the log exists to expose exactly that pattern if it appears. It is not optional, so it cannot quietly become optional under a future manager. And it is not a promise about us: it is enforced by the same append-only construction as the message archive, which means it binds everyone who touches the system, including the people who built it.
Ask any monitoring vendor two questions. Is every manager view of a conversation recorded, and can anyone at your company or theirs edit that record afterwards? If the answers are no and yes, the product’s design assumes nobody will ever need to check, and your team will price that in whether or not they say so in the meeting.
Find out what happened last week.
Fifteen minutes, your own numbers, no slides. If you don't see something that surprises you, we'll say so.
WAOversight is an independent product and is not affiliated with or endorsed by WhatsApp or Meta.