The Evidence Problem

Most companies have evidence. They have screenshots, exports, PDFs, and spreadsheets scattered across Dropbox, Google Drive, Jira, and Slack. When the auditor asks for evidence that CloudTrail was enabled during the observation period, someone spends three hours digging through shared folders trying to find the right screenshot — which was taken 8 months ago and may not reflect the current state.

This is not an evidence library. It's an evidence mess.

A real evidence library has three properties: it's organized by control, it's continuous (not point-in-time), and every piece of evidence is verifiable.

What Auditors Actually Want

Auditors evaluate evidence on four dimensions:

Relevance: Does this evidence actually demonstrate that the control is operating? A screenshot of the CloudTrail console page doesn't demonstrate that CloudTrail is enabled with log file validation — the API response showing the trail configuration does.

Completeness: Does the evidence cover the full observation period? For a 6-month Type II review, you need evidence that the control was operating for all 6 months — not just at the start and end.

Authenticity: Can the evidence be verified as genuine? Screenshots can be edited. API responses with timestamps and checksums can be verified. Auditors increasingly prefer structured, API-sourced evidence over manual screenshots.

Timeliness: Is the evidence current? Stale evidence (a configuration export from 6 months ago with no subsequent checks) raises questions about whether the control is still operating.

The Structure: Map Evidence to Controls

Every piece of evidence should map to one or more controls. Your evidence library isn't a folder of files — it's a database where each record says:

• What control does this evidence support? (e.g., CC5.1 — Encryption at rest for S3)
• What is the evidence? (AWS API response showing SSE-KMS enabled on all buckets)
• When was it collected? (Timestamp, ideally from the API source)
• How was it collected? (Automated via SecureSpect / Manual collection)
• Is it still current? (Last verified: today / 30 days ago / stale)

SecureSpect maintains this mapping automatically. Every control in your framework has a list of evidence items linked to it, each with collection timestamp and source.

Automated vs Manual Evidence

Automated evidence is collected by your compliance platform via API calls to your integrations. It's structured, timestamped, and continuous. For example:

• SecureSpect calls the AWS IAM API every 24 hours and stores the IAM password policy configuration as a structured JSON record linked to the relevant controls
• Every time a GitHub repository's branch protection settings change, SecureSpect captures the new state

Manual evidence is anything you upload by hand: screenshots, exported PDFs, signed policy documents, access review records. Manual evidence has a health score that decays over time — the older it gets, the more urgently it needs refreshing.

Evidence Health Scoring

SecureSpect assigns a health score (0–100) to each piece of evidence:

• 80–100 (Healthy): Evidence is current, from an authoritative source, and maps cleanly to a control
• 50–79 (Needs attention): Evidence is aging, was collected manually and may not reflect current state, or has a gap in coverage
• 0–49 (Critical): Evidence is stale, the underlying control is failing, or there's a gap in the observation period

Review your evidence health dashboard monthly. Fix critical and at-risk items before your audit window opens.

The Auditor Workspace

When your audit starts, you don't want to be emailing ZIP files to your auditor. You want to share a read-only workspace where they can browse your evidence organized by control, filter by date range, and see exactly what your compliance platform recorded.

SecureSpect's auditor workspace does this. You grant your auditor a time-limited, read-only link to your organization's evidence. They see:

• Controls organized by Trust Services Criterion
• Evidence linked to each control
• Collection timestamps and sources
• Test results (pass/fail/manual) for automated controls

You control what they can see. They request evidence, it's already there, organized and timestamped.

Common Evidence Library Mistakes

Mistake 1: One screenshot per control per audit. A single screenshot demonstrates point-in-time. Auditors want continuous evidence. If you only took a screenshot of your MFA policy in January, you can't prove MFA was enforced in July.

Mistake 2: No source attribution. "Here is a PDF showing our encryption configuration" — where did it come from? When was it generated? Who generated it? An API export with a timestamp is orders of magnitude more credible than an unsigned PDF.

Mistake 3: Manual everything. Manual evidence degrades. People forget to update it, screenshots don't capture the full configuration, and the process of collecting it manually creates gaps. Automate everything that can be automated, and reserve manual collection for things that genuinely can't be automated (signed policy acknowledgements, physical security logs).

Mistake 4: No CSV import path for legacy evidence. Before SecureSpect, you probably have some evidence in existing tools. Use the CSV import feature to bring historical evidence into your library and link it to controls — so your pre-automation history is part of your evidence record.