A Screenshot Is Not Evidence. It's a Memory of Evidence.
Your auditor received a folder of screenshots with no timestamps, no hashes, and no lineage. It took three people two weeks to assemble.
Your compliance analyst takes a screenshot of a Conditional Access policy in Azure. She pastes it into a Word doc, saves it to the evidence folder on SharePoint, and moves on. Three months later, an auditor opens that file and asks: can you prove this screenshot hasn't been altered? Can you prove this was the actual state of the system at collection time? Can you prove the control is still operating today?
The answer to all three is no. That screenshot is a memory. It's what someone saw on a screen at some point in time. It isn't evidence.
This distinction matters because the gap between "evidence" and "memory of evidence" is the gap between passing an audit and performing compliance theater.
Why the industry defaulted to screenshots
Screenshots became the universal unit of audit evidence for practical reasons. In 2015, most GRC platforms had no native integration with the systems they were supposed to monitor. Compliance teams couldn't pull configuration data directly from source systems. So they opened portals, pointed their screens at the relevant settings, and hit print screen.
Auditors accepted it because they had no better option. The screenshot became the de facto standard not because it was good evidence, but because it was available evidence. A decade later, most teams still operate this way.
The problem compounds. Teams build processes around screenshots: naming conventions, folder hierarchies, evidence request templates that ask for "a screenshot showing X." New analysts learn the process and perpetuate it. The workaround became the institution.
The five properties of real evidence
If you strip away habit and ask what a piece of audit evidence actually needs to prove, you arrive at five non-negotiable properties. Screenshots fail on every one.
| Property | What It Proves | Screenshot | First-Class Evidence Object |
|---|---|---|---|
| Provenance | Where the data came from | Implied by filename or folder location | Explicit: API endpoint, tenant ID, resource path, auth context |
| Freshness | When the data was captured | File system timestamp (editable, unreliable) | Immutable collection timestamp, automated freshness scoring |
| Scope | What the data covers | Whatever was visible on screen at the moment | Full configuration object, all fields, all dependencies |
| Integrity | That the data hasn't been modified | None. Any pixel editor works. | SHA-256 hash computed at collection time, tamper-evident |
| Lineage | How it connects to the control it satisfies | Folder structure. Maybe a column in a spreadsheet. | Typed graph relationship: evidence → control → framework requirement |
A screenshot has provenance only in the loosest sense ("someone was looking at Azure"). It has freshness only if you trust file metadata that anyone with write access can change. It has scope limited to whatever fit on a 1920x1080 viewport. It has no integrity mechanism whatsoever. And its lineage is a folder path that someone decided made sense six months ago.
This isn't pedantry. Each of these gaps creates a specific audit risk.
Why now: regulators are moving past the screenshot
Three regulatory shifts in the last 18 months make this urgent:
PCI DSS v4.0.1 (enforcement March 2025) requires organizations to demonstrate that security controls are "continuously" operating, not just present at a point in time. A screenshot from your last assessment window doesn't demonstrate continuous operation. It demonstrates one moment.
DORA (Digital Operational Resilience Act) requires financial entities in the EU to maintain "up-to-date documentation" of ICT risk management frameworks, with the ability to demonstrate control effectiveness to supervisors on demand. "On demand" and "screenshot from last quarter" are incompatible concepts.
SOC 2 Type II has always required evidence of operating effectiveness over a period, but auditors are increasingly pushing back on evidence packages that consist entirely of point-in-time captures with no corroborating telemetry. The "sample of screenshots across the period" approach is getting harder to defend.
The direction is clear: regulators want evidence that proves controls are operating now, not evidence that proves controls existed at some point in the past.
What a first-class evidence object looks like
An evidence object in Kyudo's Compliance Graph isn't a file. It's a data structure with immutable properties:
Collection metadata. The exact API endpoint called. The tenant and subscription context. The authentication identity used. The timestamp of collection, precise to the second, set by the source system clock, not the collector's workstation.
Raw artifact. The full configuration object, policy definition, or telemetry signal in its native format (JSON, XML, structured data). Not a rendered image of what it looked like in a portal. The actual data.
SHA-256 hash. Computed at the moment of ingestion from the raw artifact bytes. Any subsequent modification, even a single character, produces a different hash. This is the integrity guarantee.
Confidence score. A composite metric reflecting the evidence's freshness, completeness, and source reliability. A policy configuration pulled directly from Microsoft Graph API 2 hours ago scores higher than a manually uploaded PDF from last month.
Typed relationships. Explicit graph edges connecting the evidence to the control(s) it satisfies, the framework requirement(s) those controls map to, and the source system integration that produced it. Every connection is traversable and queryable.
This structure means an auditor can start at any framework requirement and trace a path through the graph to the source system that produced the proof. No shared folders. No naming conventions. No "I think this screenshot was for SOC 2 CC6.1."
How Kyudo does this
The Evidence Hub operates as a continuous collection engine. It connects to Microsoft Defender XDR, Sentinel, Purview, Entra ID, and Azure Policy through native APIs. Collection runs on schedules you define, or triggers on configuration changes.
When a collection fires:
- The integration pulls the raw data from the source system.
- The artifact is hashed (SHA-256) and timestamped immediately.
- Freshness scoring assigns credit: fresh (< 7 days) gets full credit, aging (8-30 days) gets reduced credit, stale (> 30 days) gets zero credit.
- The Compliance Graph creates typed relationships from the artifact to every control it satisfies.
- If the artifact maps to controls across multiple frameworks (SOC 2, ISO 27001, NIST CSF), all mappings update simultaneously.
No human opened a portal. No human took a screenshot. No human decided which folder to save it in. The evidence was born with provenance, freshness, integrity, scope, and lineage because the system architecture requires it.
When evidence ages past 30 days without recollection, the control's maturity score degrades automatically through CMCAE scoring. You don't discover stale evidence during audit prep. The system surfaces it the moment it goes stale.
The counter-argument: "Our auditor accepts screenshots"
They probably do. Most auditors are pragmatic. They work with what they receive, and they've received screenshots for years. The compliance profession has a mutual dependency here: teams produce screenshots because auditors accept them, and auditors accept them because teams produce them.
But three things are changing:
First, audit firms are differentiating on evidence quality. Firms that accept rigorous, machine-verifiable evidence packages can complete audits faster with fewer sampling requests. The economics favor better evidence.
Second, cyber insurance underwriters are asking questions that screenshots can't answer. "Show me evidence of continuous MFA enforcement over the past 90 days" requires telemetry, not three screenshots taken on three arbitrary days.
Third, regulators are writing "continuous" into requirements. When PCI DSS 4.0.1 says continuous monitoring and SOC 2 says operating effectiveness over a period, the screenshot model doesn't survive contact with the literal text of the standard.
The auditor accepts screenshots today. The question is whether that remains true in 18 months, and whether you want to be scrambling to change your evidence model under time pressure when it does shift.
The hidden cost of screenshot-based evidence
Beyond audit risk, screenshots carry a compounding operational cost:
Collection labor. A mid-size organization managing SOC 2, ISO 27001, and HIPAA typically spends 400-600 person-hours per year on evidence collection. Most of that is opening portals, navigating to settings, screenshotting, formatting, filing.
Duplication. The same Conditional Access policy gets screenshotted separately for SOC 2, ISO 27001, and any client audits. Each instance requires its own collection, formatting, and filing effort. Real evidence objects with cross-framework mapping are collected once and assessed everywhere.
Staleness discovery. You only discover that evidence is stale when someone manually checks. Usually that's during audit prep, when the discovery is most expensive.
Rework cycles. Auditors flag evidence gaps. Analysts re-collect. The re-collected evidence is already aging by the time the auditor reviews it. The cycle repeats.
These costs are invisible in most organizations because they're distributed across analysts' time and absorbed as "just how audits work." They're not. They're the cost of a broken evidence architecture.
Your Monday morning checklist
1. Count your screenshots. Open your current evidence package for any active framework. What percentage is screenshots vs. system-generated artifacts with metadata? If it's north of 50%, your evidence lacks integrity guarantees.
2. Test the five properties. Pick one piece of evidence at random. Can you prove provenance (source system, API, who/what collected it)? Freshness (exact collection time, verified by the system, not a file timestamp)? Scope (full configuration, not just what fit on screen)? Integrity (hash, tamper-evident)? Lineage (explicit connection to control and framework)?
3. Calculate your collection cost. How many person-hours did your team spend assembling the last evidence package? Multiply by your fully-loaded hourly rate. That number is your automation ROI target.
4. Check for duplication. Is the same evidence collected separately for multiple frameworks? Every duplicate collection is wasted effort and an inconsistency risk.
5. Ask "what if the auditor asked for this tomorrow?" If you'd need more than 15 minutes to produce current evidence for any control, your evidence model is reactive. It should be ambient.
Kyudo's Evidence Hub captures evidence directly from Microsoft Defender XDR, Sentinel, Purview, Entra ID, and Azure Policy. Every artifact gets a SHA-256 hash, automated freshness scoring, and typed lineage in the Compliance Graph. No screenshots. No shared folders.
Book a demo to see what evidence looks like when it's born with provenance.
