Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot

Home / Knowledge hub / Audit log

Knowledge hub

Audit log

A record of who did what and when, kept so you can answer later.

What it means

An audit log records who did what and when, so that you can answer that question later. It differs from the technical logs your engineers read after a crash. Those describe the software. An audit log describes people and their actions.

A usable entry names the account, the action, the thing acted on, the time, and where the request came from. With less than that you are guessing during the one hour you cannot afford to guess.

The entry also has to survive. A record the acting account can edit or delete is a note, not evidence.

Why it matters

During an incident it separates knowing from theorising. It decides whether you tell a customer that five records were opened, at these times, by this account, or only that you are not sure.

Retention decides how useful it turns out to be. A question about last March arrives in October, and a log that keeps thirty days answers nothing.

There is a commercial side too. Enterprise buyers ask who can see their data and how you would know if somebody had. One real log entry answers both faster than a page of policy.

How it shows up

The gaps are predictable. Many systems log writes and not reads, so a quiet data theft leaves no trace at all. Internal tools bypass the log. The people a log records can often delete their own entries.

We do not write your audit log. We do show which records the wrong role could have opened in the first place, with the request that did it.

Questions people ask

Audit log, answered

What makes an audit log count as evidence?

Three things. It records enough to answer a question: the account, the action, the record touched, the time, and where the request came from. The people it records cannot quietly change it. And it still exists when the question finally arrives.

Miss any one of those and you have a log file. You do not have an answer.

What if somebody inside can change what the log says?

Then it proves nothing, and that includes your own administrators. Write entries somewhere the application cannot edit afterwards, and send a copy to a system the acting account does not control.

This comes up more often than people admit. Somebody asks for an entry to be adjusted before a customer sees it, and a log that allows that was never evidence.

Should the audit log live in our main database?

It can start there, and plenty of products do exactly that. Append only, never updated, never deleted by application code. That carries you a long way.

The trouble arrives later. Anyone who reaches the database reaches the log, and the table grows faster than the rest of your schema. Shipping a copy elsewhere solves both without a rebuild.

Does our API need an audit log too, or just the web app?

Both, and the API is the one teams forget. Customers and partners often do more through the API than through the screen, and integration keys tend to carry wide permissions.

If your log covers only actions taken in a browser, an incident that ran through the API leaves you with nothing to read.

How would we know if the log had stopped recording?

You would not, unless something watches it. Logging fails quietly. A configuration change, a full disk, or a release that dropped one call, and the entries simply stop.

Alert on the absence, not only on the contents. A day with no entries at all should reach a person.

Could you answer who opened what?

We do not build audit logging for you. We do show which records the wrong role could have opened in the first place, with the request and response that proved it. Start with one app.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.