Audit log

The audit log answers the question "who did what" on your instance. It is written by your instance and read in the settings. This page describes what goes in, what does not, and how long it is kept.

What is recorded

The instance records every change request (POST, PUT, PATCH, DELETE) that succeeds, and every request refused for lack of authentication or permission (HTTP 401 and 403). A request refused for its content (another 4xx error) is not an action and is not recorded; a request that failed on the server side (5xx) is, since it may have been applied in part.

Each entry holds:

Field	Content
Time	Timestamp of the request
User	The identifier of the authenticated user; empty for an unauthenticated call
Method and path	For example POST /scan/trigger; the path is truncated to 300 characters
Status	The HTTP code of the response
IP	The client address, as seen by the instance's entry point; an address header forged by the client is not trusted
User agent	Truncated to 200 characters

Request bodies are never kept: they may hold credentials. The instance's own internal requests and monitoring probes are excluded.

An entry outlives the deletion of its author. The displayed email is then empty and the column reads "system / unauthenticated".

Where to read it

Open "Settings", "Users & Access" tab, "Audit" sub-tab. The "Audit log" card carries the description: "Who did what: every change request with its author, path, result and IP. Kept one year."

• Reading requires the read:users permission.
• The table shows the columns "Time", "User", "Action", "Status" and "IP", 50 entries per page, newest first.
• The "Filter by email, path or method…" field searches a substring in the author's email, the path or the method.
• If the log cannot be read, the page shows an error rather than an empty table: "The audit log could not be read (HTTP …). Nothing is shown rather than an empty trail."

There is no export; the log is read in the application.

Retention

Entries are kept for 365 days. The purge runs once a day, independently of finding retention: changing the findings' "Retention Period" does not change the log's duration, and no setting in the interface changes it.

Limits

• Part of the interface's actions do not appear: creating, changing and deleting roles and their scopes, notification channels and rules, custom rules, changing a finding's status, comments, folders, the framework switches. The card's description, "every change request", is therefore to be read with this reservation.
• For a cloud account created or changed in the interface, the log records the test or sync operations, not the saving of the account itself.
• An entry says which route was called, not what changed: neither the target object nor the before and after values are kept.
• Reads are not logged: viewing a finding, a masked secret or the inventory leaves no trace.
• Single sign-on events (SAML, OIDC) are recorded separately, with no screen to read them.
• If writing to the log fails, the request is still served; the failure is visible only in the instance's technical logs, which you cannot access.
• Entries are kept in your instance's database and included in its backups; they are not sent to any external system.