Here's a question you've probably never asked an app: who, on your side of the company, has looked at my data?
Not "do you sell it." Not "is it encrypted." Those questions have become standard, and most privacy pages have rehearsed answers for both. This one is different, and quieter: of the people and systems with legitimate access — engineers, support staff, administrators, background jobs — who actually read my entries, and when, and would anyone know if the answer changed?
It's a question an app can only answer if it built the machinery that produces an answer — and the building is far from universal, not because vendors are hiding something, but because nothing forces the question. That machinery has a boring name: an audit log. This post is a plain-language tour of what one is, what ours records, and — just as important — what a log like this can't do. It's the fourth leg of a series on how to evaluate any app that holds sensitive writing: the questions to ask covered what to ask a vendor, redaction covered what leaves the building, and portability covered getting your data out. This one is about accountability: whether access leaves a mark.
The trust claim hiding in a boring sentence
"We write it down every time" doesn't sound like much of a promise. Compare it to the promises apps usually make — bank-level encryption, privacy by design, your data is yours. Those are adjectives. Logging is a mechanism.
The difference matters because adjectives ask for trust and mechanisms distribute it. A company that says "we take privacy seriously" is asking you to believe a disposition. A company that says "every read of your sensitive data writes a permanent record naming who, what, and when" is describing a system that works the same way on its worst day as on its best — including on the day someone inside the company is the problem.
That's the honest pitch for audit logging, and it's worth stating before the tour: an audit log is the difference between "trust us" and "check us." Not because you personally will ever read one — you probably won't — but because its existence changes what's possible inside the company. Questions like "did anyone open this user's journal last month?" stop being unanswerable. And unanswerable is where bad practice lives.
What an audit log actually records
An audit log is an append-only diary the software keeps about itself. Every time something sensitive happens — a record is read, created, changed, deleted — the system writes a line: who did it, what kind of thing they touched, which one, and when.
Ours is a table called, unimaginatively, audit_logs. Each row records four things worth naming in plain language:
Who. The account that performed the action — a user or an administrator. When you export your data, that's you. When an administrator reviews a message our moderation system flagged, that's them, by name, not "someone."
What. The action and the kind of record it touched: a read of a journal entry, an update to a goal, a search across your chat history, an export of your account. The verbs are few and blunt — read, create, update, delete, plus a handful of special ones like moderation flags.
When. A timestamp, indexed, so the question "what happened to this account in March?" is a query, not an archaeology project.
Context. The technical surroundings — where the request came from, and a metadata field describing the action. That last field follows a rule we treat as law: metadata only, never content. The log records that your journal was read, never what it said. A log that copied your sensitive text into itself would be a second copy of the very thing it's supposed to protect — so the rule is structural, and our internal reviews enforce it.
One more piece, and it's the one we'd most want you to steal as a question for other vendors: each row is chained to the previous one with a cryptographic signature. Every entry carries a fingerprint of the entry before it, signed. Change or delete a row in the middle and the chain stops matching. That's what "append-only" means when it's a mechanism instead of a promise: the log isn't just a diary, it's a diary that shows the torn-out page.
What a log can't do
Now the limits, because this is where most writing about security features goes quiet and we'd rather not.
A log doesn't prevent anything. It witnesses. If someone with legitimate administrative access reads something they had no business reading, the log doesn't stop them — it records them. Prevention lives elsewhere: in access rules about who can reach what at all, in encryption, in redaction before anything reaches an AI provider. The log is the layer that catches what those layers let through, which is precisely the access that looked legitimate.
That sounds weaker than prevention. In one specific way it's stronger: witnessing changes behavior before anything needs witnessing. People and companies act differently when access leaves a permanent, attributable mark. The point of the diary is mostly that everyone knows it's being kept.
A log is only as good as the coverage. If sensitive reads happen through a path that doesn't write a line, the log has a blind spot and no way to tell you. Coverage is a discipline, not a feature you ship once — our own rule is that any code path reading private content writes an audit line, and our reviews treat a missing one as a bug, not a style preference.
And a log someone can quietly edit is theater. Hence the chaining above. If a vendor tells you they log access, the follow-up question is whether anything would show if the log were altered. "It's append-only" should have machinery behind it, not just a policy document.
The one question to add to your list
The seven questions we suggested asking any wellness app covered encryption, sharing, AI use, deletion, and exit. Here's the eighth, in a form you can paste into a support ticket:
"Do you keep an access log of who on your side reads user content, and has it ever been used to answer that question?"
The second half is the live part. Plenty of systems technically log things nobody ever looks at. What you're listening for in the answer is whether the log is part of how the company actually operates — whether "who accessed this?" is a question they can and do answer — or whether it's a compliance artifact. A vendor who answers concretely ("yes, reads of user content are logged with the acting account, and administrators review flagged-content access") is describing a practice. A vendor who answers "all our data is encrypted" answered a different question, and that tells you something too. You don't need to be an engineer to run this test. The shape of the answer is the result.
While you're at it, this pairs well with reading the privacy policy properly — a policy that mentions internal access controls and logging is rarer than it should be, and its absence is informative.
The tell in every breach notice
There's a place you've already seen the difference between logged and unlogged systems, even if you didn't clock it at the time: breach notifications.
Read a few and a pattern emerges. Some companies write, "the affected data was limited to the following twelve accounts, accessed between these two dates." Others write, "we cannot rule out that additional information may have been accessed." Those are not two writing styles. They're two states of knowledge. The first company had records and could scope the damage; the second is telling you, in lawyer-reviewed language, that nobody wrote anything down, so the honest answer to "what was taken?" is a shrug with letterhead.
The uncomfortable part is that both companies may have had identical security up to the moment of failure. The log didn't prevent either incident. What it changed was everything after: whether the company could tell affected people the truth, specifically, or had to notify everyone of everything because it couldn't tell who was touched. If you ever receive a breach notice, "we cannot rule out" is the sentence to notice. It's the sound of a diary that was never kept.
Where ours honestly stands
Time to point the instrument at ourselves, because a post like this earns its keep with the awkward paragraph.
What we have: across the sensitive paths — journal entries read and written, goals created and changed, chat, searches, exports, and our own moderation reviews — an audit line records the acting account, the action, the record type, and the time. Coverage follows the discipline described above, and we treat a sensitive path found writing no line as a bug; a handful of lower-stakes operations don't log today, which is what that discipline is for. The log is append-only with the hash chain described above. The metadata-only rule means your words never appear in it. When our own administrators review content our moderation system flagged, that review itself writes a read-record naming exactly which items were exposed — the watchers are watched by the same table.
What we don't have yet, stated plainly. You can't currently see your own audit trail — the log is internal, used by administrators and our own reviews, not exposed as a user-facing page. And your data export doesn't currently include your audit history. Both are honest gaps between "we keep the diary" and "you can read the diary about you," and closing them is a product decision we haven't made yet, not a technical impossibility. Until then, the accurate description of our audit log is: it exists, it's tamper-evident, it's metadata-only, and it serves the company's accountability to you rather than your direct inspection. We'd rather you hold that precise sentence than a rosier vague one.
Why this is a safety-tier issue
It can seem strange to file record-keeping under safety, next to money and housing. But informational safety behaves like the rest of the tier: when it's fine you never think about it, and when it fails it poisons everything above it. Someone who learns their private entries were browsed doesn't just lose data — they lose the willingness to write honestly anywhere, and honest writing is the raw material most of this work runs on.
You can't verify a vendor's insides from the outside. What you can do is notice which vendors have built the machinery that makes their insides checkable, and weight your trust accordingly. The boring answer — "we write it down every time" — is the strongest one available, precisely because it isn't an adjective.
If you want the fuller picture of how we handle the rest of it, the trust page is the standing document: what's collected, what's encrypted, what leaves, and what we still owe. This post is one leg of that table. The other legs are linked above, and the questions work on anyone — including us.
—
This post describes NexTier's audit logging as implemented at the time of writing and was verified against the live system; the user-facing gaps named above are real and tracked. It's educational content about evaluating software, not security advice for any other system.