On this page0
Unfamiliar word? See Glossary: words used in these docs. Looking for the tasks in order? Begin at Start Here.
Reference
Included in: Advanced. Which Plan Includes What
Evidence Collection
What Zonitix collects as audit evidence on its own, where each kind is kept, how files you upload are protected, and how to give an auditor access.
Continuous Audit Trails
Preparing for an audit usually means collecting screenshots of group memberships, user lists and logs by hand. Zonitix records the same facts as they happen: the audit log keeps key events (for example a new administrator added, a user deactivated, a network scan completed), and background collectors turn the current state of your instance into evidence against each control. Both are reachable only by people holding the right permissions.
Read Access For Your Auditor
Durable Backups
Frameworks the product helps you evidence — Zonitix is not itself certified or assessed against these standards; see the Trust Center for current status.
The readiness score is explained on Readiness Score & Frameworks. Control states, reports, the evidence vault and every endpoint are on Compliance Hub & Reporting.
If something here is not working as you expect, start with When something goes wrong.
The plain explanation is above. This part is for IT and developers: the exact settings, permission names, API addresses and data fields behind it. Closed: select the heading above to open it. While it is closed, your browser’s find-on-page (Ctrl+F or Cmd+F) does not search this part.
What Is Collected, And When
While the Compliance module is active, a collector runs every 30 minutes and records evidence against your controls from the product’s own data and your connected systems; the sources are listed one by one under What The Hub Collects By Itself. Each collector runs on its own, so one failing does not stop the others, and one that finds nothing to collect is reported as idle rather than failed. The first run is 2 minutes after the compliance service starts, and the rest follow on a fixed 30-minute timer. A run that is still going when the next one is due is not doubled up: that turn is skipped. The files produced by compliance report runs are kept in the evidence vault: encrypted at rest (AES-256-GCM), sealed with a keyed HMAC, and SHA-256 verified on the way out — a tampered file returns a 409 on download rather than being served. One exception: free-form files you upload yourself are not themselves hash-chained. Each upload’s SHA-256 is computed on arrival, returned to you and written to the audit log, and when an audit run is finalized the attached files are pinned by that hash in the sealed manifest — so a file swapped or removed after the seal is detectable.
Evidence File API
Audit records are written by the services themselves as actions happen and stored in Postgres. Evidence files are uploaded and retrieved through the compliance service:
// Upload an evidence artifact (multipart):
POST /api/v1/evidence/upload
// Retrieve one back:
GET /api/v1/evidence/files/:filename
// Upload: manage_compliance, or view_assigned_compliance for a control you own.
// One file per request, 25 MB max (413 above that). Returns:
{ "attachmentUrl": "...", "sha256": "<hex digest of the file>" }
// Download: manage_compliance, view_assigned_compliance or view_reporting.
// Every upload and download is audit-logged.
// Evidence that already lives elsewhere can be attached as a link instead:
POST /api/v1/compliance/reports/compliance/evidence
// For comparison, one row of the audit log (not an evidence file) looks like this:
{
"id": 481,
"createdAt": "2026-06-19T06:40:00Z",
"action": "USER_DEACTIVATED",
"userEmail": "admin@acme.com"
}