Evidence

The Evidence module is where your organization tracks two related things:

1. Evidence requirements — what kinds of proof you need to collect. “We need quarterly access review records.” “We need annual penetration test reports.” These are durable expectations.
2. Evidence claims — specific instances of that proof. “Here is the Q2 2026 access review record.” “Here is the penetration test report from 17 April 2026.” These are the actual artifacts and attestations, with validity periods and review states.

One evidence claim can satisfy many frameworks at once. If your organization is certified against three different standards that each require evidence of secure backups, you collect the evidence once and link the claim into all three. The Evidence module is what makes that reuse possible without losing the audit trail.

When you would reach for this

You set up evidence when:

• A framework, obligation, or control says “you must be able to demonstrate X” and you need to define what counts as adequate proof.
• You’re collecting a specific record (a report, a screenshot, a log export, an attestation) and need to register it as a claim against one or more requirements.
• An auditor asks for proof of something and you need to find the latest valid claim, with its validity period and approval state.
• A claim is expiring and you need a place to track its replacement.
• Two frameworks ask for the same proof and you want to avoid uploading the document twice.

You don’t reach for this when running the assessment that consumes the evidence (that’s Assessments) or when storing the artifact itself (artifacts live in the workspace artifact store; the claim references them).

What lives in evidence

Two record types:

Evidence requirement carries:

• A title and a stable key you pick, plus a description of what the proof needs to demonstrate.
• A status: draft, active, retired.
• An optional subject reference when the requirement targets a specific module or resource type.
• A requirement snapshot with structured detail (collection cadence, retention period, format expectations, approver routing).

Evidence claim carries:

• A claim key and a title describing this specific instance.
• A reference to the evidence requirement it satisfies (a claim can be standalone, but most are tied to one).
• A subject reference identifying what the claim is about (a specific control, a specific obligation, a specific scope node).
• A source reference identifying where the proof came from (a DMS document, a form response, an external system, an artifact upload).
• A source snapshot with the structured detail of the source.
• A claim snapshot with collection metadata, reviewer notes, and any audit-relevant detail.
• A validity window (validFrom and validUntil) so the claim is known to expire.
• A status: draft, submitted, approved, rejected, expired, superseded, archived.

A worked example: a university maintains accreditation evidence

A higher education institution is preparing for a renewal of its institutional accreditation, plus a separate program-level accreditation for two of its professional schools, plus an information-security framework certification it has held for three years. Many of the documents it collects (faculty qualification records, student-data protection attestations, board minutes on governance, training completion reports) are needed by all three review bodies.

The institution’s quality director, Beatrice, sets up Evidence like this.

Step 1: define the requirements. Beatrice walks each accreditation framework and the security framework, identifying every place a reviewer will ask for proof. For each, she creates an evidence requirement:

• faculty-qualifications-roster — annual roster of faculty qualifications and credentials.
• student-data-protection-attestation — annual attestation that student data protections meet policy.
• governance-board-minutes — quarterly board minutes covering governance topics.
• security-training-completion — annual training completion rate per department.
• pen-test-report — annual penetration test report from an independent assessor.

Each requirement carries the cadence (annual / quarterly), the retention period the institution must hold the proof for, and routing for approval.

Step 2: collect a claim against a requirement. When the Q2 2026 board minutes are finalized, Beatrice’s assistant creates an evidence claim:

• Title: “Q2 2026 board governance minutes.”
• Requirement: governance-board-minutes.
• Subject: linked to the relevant board program record.
• Source: the DMS document holding the signed minutes.
• Validity: validFrom: 2026-04-15, validUntil: 2026-07-15 (one quarter).
• Status: submitted for the quality reviewer to approve.

The quality reviewer reviews the claim and moves it to approved. The claim is now valid evidence; any framework that has a coverage link to the relevant requirement node can use it.

Step 3: reuse across frameworks. The institutional accreditation framework, the program accreditation framework, and the security framework all have requirement nodes about board governance. Through Frameworks, all three have coverage links to the governance-board-minutes evidence requirement. The single approved Q2 claim shows up as evidence for all three frameworks. No duplicate upload, no duplicate review.

Step 4: handle expiry. When the Q2 claim approaches its validUntil date, Beatrice’s team gets a reminder. Before it expires, they collect the Q3 minutes and create a new claim, which supersedes the Q2 claim. The Q2 claim’s status moves to superseded; it remains visible for historical audits but no longer counts as current evidence.

Step 5: external system source. For the penetration test report, the external assessor uploads their report to the institution’s secure file drop and emails a reference number. Beatrice’s security analyst creates a claim with source = “external” and the assessor’s reference in the source snapshot. The artifact attaches a copy of the report. When the security framework auditor arrives, they see the claim with the assessor’s name, the report date, and the artifact in one place.

When the accreditation visit happens, the reviewers can be shown every approved evidence claim currently within its validity window, grouped by the framework’s requirement nodes.

Claim statuses

The lifecycle of an evidence claim:

What you’ll see in the product

Evidence lives under Governance → Evidence in the workspace.

Two top-level tabs: Requirements and Claims.

The Requirements list shows every requirement defined, with status, cadence, and the count of approved claims currently valid.

Inside a requirement, you see all claims that have been logged against it, grouped by status. You can quickly see “do we have a currently-valid claim?” and “what’s coming up for expiry?”

The Claims list shows every claim across the organization, filterable by status, requirement, subject, source, and validity window.

Inside a claim, you see the full record, the linked artifact or DMS document, the audit history, and (where applicable) the chain of supersession back to earlier claims.

Every change is captured in the workspace Audit Log. Approved evidence claims are also part of the audit chain.

One claim, many frameworks

The single most important property of Evidence: a single approved claim can satisfy many framework requirements through coverage links from the requirement to the claim’s evidence requirement. This is how a single board-minutes document can be evidence for institutional accreditation, program accreditation, and security framework certification simultaneously.

When a framework auditor reviews the claim, they see the framework-side requirement and the cross-framework usage clearly. There is no manufactured duplication; one collection, many uses.

Common workflows

Defining a new evidence requirement

1. Evidence → Requirements → New requirement. Pick a stable key, title, description.
2. Capture the cadence, retention period, format expectations, and approval routing in the requirement snapshot.
3. Through Frameworks, create coverage links from relevant framework nodes to the new requirement.

Logging a new evidence claim

1. Evidence → Claims → New claim. Pick the requirement (or leave standalone for ad-hoc evidence).
2. Identify the subject (the control, obligation, or other governed object the claim is about).
3. Identify the source (a DMS document, a form response, an artifact upload, an external system).
4. Capture validity dates.
5. Submit for review.
6. Reviewer approves, rejects, or sends back for revision.

Refreshing recurring evidence

1. As an existing approved claim approaches expiry, collect the next instance.
2. Create a new claim referencing the same requirement, with the new validity window.
3. The system records the previous claim as superseded.
4. Frameworks pointing at the requirement automatically see the new current claim.

Withdrawing evidence

1. Set the claim to archived with a rationale.
2. The claim is no longer active evidence.
3. Audit history preserves the original.

Looking for the API?

See Evidence API reference for the v1 REST endpoints to list requirements, list and create claims, and integrate external sources of proof.

Related

• Frameworks - coverage links from framework nodes to evidence requirements enable cross-framework reuse.
• Controls - controls require evidence to demonstrate they operate.
• Obligations - obligations require evidence of compliance.
• Assessments - assessments cite evidence claims.
• Submissions - submission packages include evidence claims.