What to write when they ask for an audit log of who did what

What the row is asking

Reviewers ask for a record of who did what: who changed a setting, who opened a record, and when. They also ask whether the customer can read or export that record, and whether an entry can be changed after it is written. Those are separate sentences.

This is a different row from who on your team can still open customer data. That row is who can reach it. This row is what they did, and whether that record can be changed later.

A log of each action an AI agent takes is a different sentence from the general log of who did what in the app. Write the agent trail only when you can show it.

Onplana, on a page dated October 7, 2026, asks "Is every configuration change logged?" and "Can the audit log be exported?" The same page tells a reviewer to "Change a policy setting and look for the entry in the audit log." Onplana writes vendor-review questions. This is their list, not a founder asking for help.

Cybersecify, on a page that says Updated October 3, 2026, has a logging row for "Audit log immutability (write-once storage, signed logs)." Ashok Kamat wrote the page for Cybersecify, a penetration-testing firm. That cell is a sample the firm wrote, not a claim from a named customer. Write that the log cannot be edited only when that is true.

A comment on r/SaaS, June 23, 2026, names "audit logs" as one of the few rows a long questionnaire turns on. The same day, another comment asks for "an un-editable audit log for literally every action a user takes in the app." Another comment the same day says "Audit logging comes up almost every time. Not just who logged in, but who changed what and when." That is the commenter's report. It is not a count. A comment on July 4, 2026, on the same thread, says they want to know "exactly who accessed what and when" and want "proof its tamper-proof." Those commenters do not name a company. Nothing in the June thread says a deal stalled on the log.

A post on r/SaaS, July 14, 2026, is written as the person selling an AI agent product. A new section asked for a "per-action audit trail for the agent." They said they would get back to the reviewer, and "the deal sat in procurement for six weeks." The same day they wrote that "the sample action trace was the single thing that moved our reviewer, but only after we showed it couldn't be edited after the fact." Company and headcount are not stated. That stall is this post. It is not a count from other reviews.

Telling the customer about an incident is a different clock. What data a vendor can see is a different row.

What reviewers accept

If you keep a log, name what it records. Name who, what, and when. A sign-in line is not the whole answer when they asked who changed what.

If a customer can read the log or export it, say which, and the date you checked. Keep only the access that is true.

Write that an entry cannot be edited or deleted after it is written only when that is true. If someone can change the log, say so. Do not write tamper-proof, write-once, or signed logs unless you can show that.

If you do not have a log, say not yet. Do not tick Yes.

A per-action trail for an agent is its own sentence. A general app log does not answer it. Write the agent trail only when you can show a sample. Write that the sample cannot be edited only when that is true.

An honest gap is a complete answer. The answer that fails is a Yes you cannot stand behind when they change a setting and look for the entry.

What not to write

Do not write that the log cannot be edited because the form asks for it. Write it only when an entry stays as written.

Do not write who logged in as the whole answer when they asked who changed what and when.

Do not answer a per-action agent trail with the general app log. Those are separate sentences.

Do not answer who can still open customer data here. That is a different row.

Do not answer how soon you tell the customer about an incident here. That is a different clock.

Do not treat the date on a vendor row as a log of who opened a customer's account. That date is when you saved the row.

Do not send the contact email as the audit log.

Do not invent a log, an export, or a deal that stalled.

Where this answer lives

Keep these sentences in the questionnaire answer you control.

The public page shows your company name, a short summary, and a contact email. Each row shows the company, what it does, the processing location, the agreement link, and the date you saved it.

The date on a row is the date you saved that row. It is not a record of who opened a customer's account. The contact email is not an audit log.

There is no field for an audit log, how long you keep the log, an export of events, whether an entry can be changed later, or who opened a customer's account. The page does not fill this row.

If the editor already knows a company, a suggestion can offer a location or a public agreement link, and only after you use it. That suggestion does not write a log.

If you want the longer notes

Who can still open customer data is a different row from what they did. What to write is in the access review guide.

How soon you tell the customer about an incident is a different clock. What to write is in the incident notification guide.

What data each vendor can see is a different row from a log of who did what. What to write is in the data access guide.

Whether one customer can see another's data is a different row from a log of who did what. What to write is in the customer data isolation guide.

What the agent is allowed to do, before you say what is logged, is a different row. What to write is in the agent permissions guide.