What is Compliance Evidence?
Compliance Evidence is documented, verifiable proof that a required security measure is actually in place and working. It turns a claim into a record: not just a statement that a control exists, but the concrete proof of it, tied to the specific requirement from a framework such as NIS2, DORA or ISO 27001. Typical evidence includes configuration snapshots, log extracts, an unbroken audit trail, policy documents and approvals. Good evidence is current, clearly tied to one requirement, and complete. Without these properties, it stays a claim in an audit, one that triggers follow-up questions and rework.
Compliance Evidence in detail
Frameworks such as NIS2, DORA or ISO 27001 set out requirements, known as controls. For each of these requirements, operations must be able to show that it is in place. That proof is exactly what evidence means here. It ranges from hard technical artefacts such as configuration snapshots and log extracts to organisational documents such as policy, approvals and tickets. A screenshot can serve as evidence, but only with a timestamp and context attached.
The value of a piece of evidence rests on three properties. It has to be current, reflecting today's state rather than one that is long out of date. It has to be traceable, carrying source, timestamp and a link to the requirement. And it has to be complete, actually covering the control. Miss any one of these, and a gap opens up in the audit: the auditor sees a record but can neither place it nor accept it as effective.
Why Compliance Evidence matters in Zscaler operations
Running Zscaler continuously produces exactly the signals that make good evidence: policy states, change history, access and filtering logs, four-eyes approvals. The problem is rarely that no evidence exists. It is that it sits scattered and tied to no requirement. Then, ahead of an audit, the hunt starts: pulling screenshots, assembling exports, reconstructing states. That costs time and often delivers only a snapshot in time.
Deriving evidence continuously from real operational signals and mapping it to controls turns this around. Evidence then stops being a project ahead of an audit and becomes a by-product of clean operations. That cuts the effort, lowers the risk of outdated records, and makes the case you present to auditors solid. The specific national implementation of NIS2 governs the detail here, which is why the mapping to controls should stay traceable over time.
Common sources of error
- Collected once, then left to age: evidence from a year ago no longer proves today's state.
- No link to the requirement: a record that is tied to no control does little good in an audit.
- Screenshot without context: without a timestamp and source, an image stays weak, easily challenged evidence.
- Manual collection right before the audit: that creates stress, gaps, and only a fleeting snapshot.
Compliance Evidence in practice: what CentaurNexus contributes
Compliance Mapping from CentaurNexus ties real signals from your Zscaler tenant to the requirements of NIS2, DORA and ISO 27001, and assembles them into an exportable evidence pack. Evidence then grows out of day-to-day operations instead of being collected under pressure before an audit. Because the mapping runs off real configuration and change data, the records stay current and clearly tied to one requirement. For how a change becomes provable in the first place, see the article Confirm Zscaler changes only after read-back.
Related terms
Frequently asked questions about Compliance Evidence
Compliance Evidence is documented, verifiable proof that a required security measure is actually in place and working. It turns a claim into a record: not just a statement that a control exists, but the concrete proof of it, tied to the relevant requirement from a framework.
Typical evidence includes configuration snapshots, log extracts, an unbroken audit trail, policy documents, approvals and tickets. Screenshots can serve too, if they carry a timestamp and context. What matters is that a record is tied to a specific requirement and shows that the measure is not just planned but actually working.
Mainly NIS2, DORA and ISO 27001. All three call for provable, effective measures, not just statements of intent. For IT operations, that means every required control has to be demonstrable: that it is in place, and how. The specific national implementation of NIS2 governs the detail here.
Good evidence is current, traceable and complete. Current means it reflects today's state, not last year's. Traceable means it carries a timestamp, source and a link to the requirement. Complete means it actually covers the control and leaves no gap that shows up in an audit.
By deriving it continuously from real operational signals, instead of piecing it together manually right before the audit. When configuration states, logs and audit trails get mapped to controls on an ongoing basis, the picture stays solid at all times. That lowers the stress ahead of an audit and avoids outdated or incomplete records.
- BSI: NIS2 Directive and implementation in Germany - bsi.bund.de
- DORA (Regulation (EU) 2022/2554), ICT risk management requirements - eur-lex.europa.eu
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.