Skip to main content

Audit Trail

The audit trail is a time-ordered record of changes and reads within your tenant. It exists to answer questions that come up during a compliance assessment or an internal review: "who changed this setting, and when", "who took this report", "what did the external auditor actually see".

1. What is recorded​

Changes​

Write actions on connections, projects, members, access and organizations are recorded. For example:

  • Creating or deleting a connection; connecting or disconnecting KMS/S3 storage; bulk-creating member account connections for an organization
  • Creating, updating or deleting a project/project group; adding, removing, or changing the role of a project member
  • Creating, revoking or accepting an invitation; changing a tenant role
  • Creating, revoking or extending an auditor access grant
  • Starting a sync, scan or IAM analysis; changing a finding's assignee or status, individually or in bulk
  • Signing out; revoking a session

Reads that count as evidence​

Some reads are also recorded, because "what changed" alone cannot answer every audit question:

  • Viewing a report, or exporting it as PDF
  • Exporting findings, assets, or audit events (CSV/JSON)
  • Downloading the organization deployment package (the stack set template)

Every read made by an outside auditor​

Every read request made while signed in as an auditor is recorded without exception, even on screens not in the list above. A read already covered above (viewing a report, say) leaves that one record; everything else leaves a separate "read recorded" entry - however many rows one auditor session produces, filtering by that actor shows everything they saw.

Failed attempts too​

A request refused for lack of permission (an insufficient role, an auditor reaching outside their scope, expired access) is recorded as a failure as well - recording only what succeeds could never answer "who tried what, and was it blocked".

What is deliberately not recorded here

Deleting an entire tenant, and the start/progress/completion of an execution (a sync, a scan, and so on) by itself, are not covered by this screen. A tenant deletion is recorded as a separate, signed deletion certificate, and executions have their own, stronger execution ledger. A request that changed nothing - a dry run, for instance - is not recorded either.

2. Narrowing the list with filters​

You can combine the following filters:

  • Date range - the last few days, or an arbitrary start and end date
  • Category - authentication, user/access management, connection, project, sync, scan, risk, report, export, read access, and so on
  • Actor - a specific user, or a role (for example, showing only what auditors did)
  • Target - the kind of object something happened to (a connection, a project group, an assessment, a report, a user, an invitation, an access grant, and so on) and its id

Every entry carries the kind and id of the object it happened to. When a request touches more than one object along its path (say, "removed a member from this connection"), the one that actually changed - the member - is what is recorded.

3. Exporting​

You can export the record as CSV or JSON, with the same filters applied so you get exactly the range you need.

Up to 10,000 events are included per request. If there are more, they are never silently truncated - the response tells you there is more and where to pick up from. Passing that point back in your next request continues from exactly there. Because it continues from a position rather than a page number, new events written while you are exporting cannot cause you to see a row twice or miss one.

4. Retention​

There is no automatic deletion cycle for audit records today - they are kept until the tenant itself is deleted. A configurable retention policy is planned for a later release.