DocsEveryday work

Audit trail & exports

Updated 2026-10-07

The Audit trail is the complete, append-only record of every action taken in your workspace. It shows who did what, to which record, and when. It is read-only by construction. There is no edit affordance and no delete affordance anywhere in the product, and the underlying store grants no update or delete rights. Corrections are new entries, never rewrites.

The store records every action, but the Audit trail screen and its exports show each reader only the rows their access allows. Internal-marked rows are hidden from directors and examiners. Fraud-case rows need the permission to read financial-crimes work, and rows about suspicious activity report decisions are not shown in the trail to anyone. A row that records a change to a link between two records appears only when you can open the record at one end, and the other end is shown only by its kind.

Every write is an event. Creating a finding, editing a policy, running an agent, granting examiner access, changing a role, approving anything and exporting anything each produce a row. The row holds the actor, the action, the object type and identifier, and a timestamp. Human and system actors are visually distinct, so an automated control test is never mistaken for a person's decision.

Two categories of row are marked specially, because examiners ask about them:

  • Sole operator. The only person in the institution who held the required permission made the decision. The row carries the justification that was given at the time.
  • Authority override. The Authority Engine flagged the decision, and the row carries the outcome that was recorded.

Both are explained in Approvals & delegation of authority.

The trail is filterable by date range, actor, object type, action, and source IP or CIDR range. The IP filter matters more than it sounds. It is how you answer an access question about a specific session. It is also part of how examiner access is evidenced, since an examiner grant can be pinned to an IP range for its duration.

An append-only claim is only worth what you can prove. Key events are sealed into a per-institution hash chain, with roots anchored and externally timestamped. Those events are approvals, risk acceptance decisions, attestations, policy releases, evidence attachment and exam artifacts.

The Integrity verification panel on the Audit trail screen recomputes that whole chain on demand. Choose Verify now and the result is one of two things. Either the chain is verified, with the count of sealed events, or there is an integrity break with the exact sequence number where the chain first fails. There is no partial credit and no reassuring middle state.

A proof pack is an export a third party can verify without logging in to Zovos and without trusting us. It bundles the sealed artifacts, their manifest hashes, and a standalone verifier that runs offline. This is the artifact to hand an external auditor, a regulator, or a counterparty who asks you to prove that a document existed in a particular form on a particular date.

Sealed artifacts include board packs, finalized minutes, monitoring workpapers, exam binders and absence-testing run manifests. Each records a SHA-256 content hash at the time it was sealed, so re-verification later tells you whether anything behind a claim has drifted.

You do not have to open the zip to see what you delivered. Expand a built package in Settings and it shows its ordered item index and its sealed manifest in the product, so "prove exactly what was in that pack" is answerable without a download.

The Audit trail exports directly to CSV for spreadsheet work and JSONL for your SIEM. Beyond the trail itself, the product produces the register exports an examination tends to ask for:

  • Server-stamped PDF and XLSX exports cover the risk register, gap report, findings, loss events and program inventory.
  • Quick client-side CSVs are available from most register screens for ad hoc analysis. These save the rows currently on screen.
  • An import-ready CSV covers a whole register of risks, third parties, controls, policies or findings. It is streamed from the server and audit-logged, in the exact column shape our own importer accepts. This is the export to reach for when someone asks whether you can get your data out.
  • Scheduled exports run on a cadence you set. Each one is kept for you to download from Settings through a short-lived secure link, or dropped on your own SFTP server with a pinned host key. Email is configurable as a destination too, but Zovos does not send email today, so that leg stays inert until delivery is switched on.
  • A continuous audit-log feed goes to the SIEM forwarder you configure on the Integrations tab of Settings. It sends each new audit row to a generic HTTPS collector, Splunk HTTP Event Collector, or Microsoft Sentinel, so the record also lives in your own stack.

Exports require the settings read permission. On a scheduled export, a failed delivery leg marks the whole run as an error and raises a delivery alert naming the leg that failed. Nothing degrades quietly to a partial success.

In practice, three questions come up in almost every exam, and the trail answers all three. The first is who approved this and whether they were entitled to. The second is whether this record has been altered since it was signed. The third is what an examiner from another agency saw in their session. The audit rows answer the first, the integrity verification answers the second, and the scoped access log answers the third.

The audit trail records actions in Zovos. It is not a general-purpose log of your bank's systems, and connecting a connector does not import that system's own audit history.

Internal audit work is walled off. Outside the internal audit function, internal-audit rows are left out of the Audit trail and its exports entirely, so not even their existence shows. The board sees only approved or issued internal-audit artifacts, such as the approved audit plan, sent independence confirmations and issued reports, and never the workpapers, draft findings or fieldwork behind them. A proof pack exported by someone outside the audit function contains hash-only stubs for those entries, which still verify offline. That is by design. An auditee should not be able to read in-progress audit work through the audit trail.

Retention of the trail and of your exports is covered in Your data: exports, backups & retention.