Evidence lifecycle and integrity

Summary

• All evidence is one kind of record, whatever produced it: a file you uploaded, a link, a note, or an observation a data source synced. Each record knows who captured it and carries a digest of what it said at capture.
• Evidence counts toward control coverage only when it is linked to a specific requirement, its status is Valid, and it passes qualification. Platform-generated records are held to a stricter test than uploads and syncs.
• Each item's content and file are hashed at capture; digests are chained per organization and the chain head is signed, so a later change or deletion is detectable.

Concepts

Where evidence comes from

How it works

Uploading a file

Your browser never streams a file through the web app. The app issues a short-lived, signed upload link and the browser sends the bytes directly to private object storage under a path owned by your organization. Downloads use signed links that expire; there is no public URL for an evidence file.

Linking to a control

A link has two levels. A control-level link attaches evidence to a control as context. A requirement-level link attaches it to one of the control's required evidence items (the slots with ids such as E-AM-02). Only requirement-level links count toward coverage.

Linking checks that the pair does not already exist and that the control belongs to a framework you have enabled. It writes an "evidence added" entry to the control's log, runs the coverage check, and may move the control to In progress or Pending review; see Control status and coverage.

Qualification

Coverage asks three questions of each linked record. Is it mapped to this exact requirement? Is its status Valid? Does it qualify?

Qualification is where platform-generated evidence is treated differently:

The reasoning: a platform page is useful context, but its existence alone does not prove that policies, reviews, agreements, or processes exist.

Expiry

The expiry date is informational. Statistics and filters treat a record as expired once the date has passed, but nothing rewrites the status on that date; the record still covers its requirement until someone changes the status. The one exception is privacy evidence, which is marked Expired explicitly and then re-runs the coverage check on linked controls.

The integrity record

Every record carries an integrity record with three parts.

Content digest. A SHA-256 digest computed at capture over the descriptive content of the record: title, description, structured data, provider kind, external identity, and the owning organization. Status, tags, expiry, and timestamps are excluded on purpose, so approving or re-tagging a record does not change its digest. The organization is included so a digest cannot be replayed into another tenant.

File digest. For files, a SHA-256 digest of the bytes as read back from storage at capture, together with the storage object's own version identifier. It is skipped, with a recorded reason, for files over 100 MiB or when the file cannot be read back.

Provenance. Who captured the record (you, a connected tool, or the platform), the capture time, and the person or integration responsible. Editing a record re-attributes provenance to the editor.

Verification recomputes both digests and reports Verified, Mismatch, or Not captured.

The hash chain and attestations

Within minutes of a capture or a content change, the record's new digest is appended to your organization's chain: each entry carries a sequence number, the previous entry's hash, and its own hash over the entry. Appends are serialized per organization so the chain cannot fork.

The chain head is then signed with a key that belongs to your organization alone. The private key is held encrypted on our infrastructure and is never exported. The signature is a verifiable-credential statement over the chain's root digest, refreshed as the chain grows. Attestation refuses to sign a chain that fails verification, and does nothing when nothing has changed.

Deletion

Deleting evidence unlinks it from every control (writing an "evidence removed" entry to each control's log) and then removes the record and its file. Control statuses are not reset. The chain keeps its entries for the deleted record, so the deletion is visible through chain verification: the chain holds a record for an id that no longer exists.

Edge cases and failure modes

• A valid file linked at control level covers nothing. Coverage is per requirement. Link it to the requirement slot, not just the control.
• Expired is a report, not a state. A record past its expiry date is still Valid and still covers its requirement until someone changes the status.
• Register evidence looks like coverage but mostly is not. The Personnel Directory record is mapped to several identity requirements and qualifies for none of them.
• Editing synced evidence changes its provenance. After a manual edit the record says a human captured it, and the next sync will overwrite the derived fields again, producing a new chain entry.
• Large files have no file digest. Over 100 MiB the content digest still exists, but the bytes themselves are not attested.
• Digest churn is expected on legitimate change. A sync that updates a record's data appends a new chain entry; that is the design, not a mismatch.

What you can influence

• Status: set Valid when you have reviewed a record; that change re-runs the coverage check on every linked control.
• Requirement-level links: choose the requirement slot when linking so the record can count.
• Expiry dates: use them to drive review, knowing they do not change status on their own.
• Verification: ask for an integrity verification on any record; Mismatch means the content or file differs from what was captured.

Related guides

• Evidence Vault
• Control detail
• Statuses
• Control status and coverage
• Sync model and job scheduler