Evidence Is Not a Screenshot: Why Audit Artifacts Need Provenance

It's Tuesday afternoon. A compliance analyst opens the Azure portal, navigates to Entra ID, clicks into Conditional Access policies, and starts taking screenshots. One for the MFA policy. One for the named locations config. One for the session controls. She pastes each into a Word document, adds a heading, and saves it to the SOC 2 evidence folder on SharePoint.

Three days later, the external auditor opens the folder and asks a simple question: when were these screenshots taken?

The analyst checks. The Word document's metadata says it was modified yesterday (she fixed a typo). The screenshots themselves have no embedded timestamp. The Conditional Access policy shown in the screenshot was last modified in January, but the screenshot could have been taken anytime between then and now. There's no way to prove it.

The auditor notes the gap. The analyst spends another half-day re-taking the screenshots with the browser's clock visible. Everyone moves on. Nobody questions whether this process makes any sense.

The screenshot problem is a provenance problem

Screenshots are the default unit of audit evidence across the industry. They're fast to capture, easy to understand, and universally accepted. They're also fundamentally broken as evidence artifacts.

A screenshot has no integrity guarantee. You can't verify it hasn't been edited. It has no machine-readable metadata about what system it came from, what API call produced the data, or whether the configuration shown was the actual state at collection time or a cached view. It has no relationship to the control it's supposed to satisfy, just a filename and a folder structure that someone decided made sense.

This isn't a theoretical problem. Auditors increasingly flag evidence packages that rely on screenshots without corroborating metadata. Cyber insurers are moving toward continuous evidence requirements, not annual snapshot collections. And regulators (particularly in financial services post-DORA) are starting to ask how organizations can demonstrate control effectiveness between audit windows, not just during them.

The screenshot was never designed to be evidence. It was a workaround because compliance teams didn't have systems that captured evidence natively. The workaround became the standard. Now the standard is breaking.

What evidence actually needs

If you were designing an evidence system from scratch (no legacy, no "this is how we've always done it"), what would an evidence artifact look like?

The gap between these two columns isn't a feature gap. It's an architectural gap. You can't retrofit provenance onto screenshots. You need evidence objects that are born with integrity, provenance, and lineage built in.

Freshness isn't optional

Most compliance teams treat evidence collection as a project. Audit coming up in Q3? Start collecting evidence in Q2. Package it. Ship it. Done until next year.

That model assumes controls don't change between collection windows. They do. A Conditional Access policy that was properly configured in March might have been modified in June to accommodate a vendor integration. If your evidence was collected in March and your audit is in September, you're presenting six-month-old data as proof of current state. The auditor may accept it. The auditor shouldn't.

Kyudo scores evidence freshness on a simple scale:

• Green (< 7 days): Fresh. This evidence reflects near-current state. Full credit.
• Yellow (8-30 days): Aging. The evidence is probably still accurate, but drift is possible. Reduced confidence.
• Red (> 30 days): Stale. No credit. The evidence is too old to attest to current control state. Recollect.

Stale evidence gets zero credit in control assessments. Not reduced credit. Zero. A control with only stale evidence drops to unattested status across every framework it maps to.

This is a deliberate design choice. If your evidence is more than 30 days old, you don't know what your control state actually is. Pretending otherwise is compliance theater.

SHA-256 and the integrity chain

Every evidence artifact in Kyudo gets a SHA-256 hash at collection time. This is a cryptographic fingerprint computed from the raw content of the artifact. If a single byte changes after collection, the hash won't match.

Why does this matter? Because audit evidence needs to prove two things: what the state was, and that the record hasn't been altered since collection. Screenshots can prove neither. A JSON configuration snapshot with a SHA-256 hash and an immutable timestamp proves both.

The integrity chain works like this:

1. Collection: The Evidence Hub pulls the configuration directly from the source system via API (Microsoft Graph, Azure Resource Manager, AWS Config, etc.). No human in the loop. No browser. No copy-paste.
2. Hashing: The raw artifact is hashed immediately. The SHA-256 hash, the collection timestamp, and the source system metadata are recorded as an atomic unit.
3. Storage: The artifact is stored immutably. It can't be edited after collection. If the configuration changes, a new artifact is collected with a new hash, creating a version chain.
4. Verification: At any point, the hash can be recomputed from the stored artifact and compared to the recorded hash. If they match, the artifact is provably unmodified.

An auditor reviewing this evidence doesn't need to trust the compliance team's process. They can verify the integrity independently. That's a fundamentally different trust model than "here are some screenshots we took, trust us on the timing."

Lineage: from framework requirement to source system

Provenance isn't just about integrity. It's about knowing why a piece of evidence exists and what it proves.

In Kyudo's Compliance Graph, every evidence artifact has explicit, traversable relationships: the specific framework control IDs it attests to, the control in the authoritative registry it supports (with current maturity level and completeness score), the source system and API endpoint that produced it, the collection context (automated vs. manual, scheduled vs. triggered), and its full assessment history over time.

This lineage isn't metadata in a sidecar file. It's the graph structure itself. You can traverse from an EU AI Act requirement to the control it maps to, to the evidence that satisfies the control, to the Defender for Cloud signal that produced the evidence, in a single query. Every hop is typed and timestamped.

When an auditor asks "show me the evidence chain for this control," the answer isn't a folder of files. It's a directed graph with integrity guarantees at every node.

The multi-framework multiplier

Evidence provenance gets even more important when you're managing multiple frameworks. Without provenance, you collect the same evidence multiple times for multiple frameworks because you can't prove that the artifact in your SOC 2 folder is the same one that should be in your ISO 27001 folder.

With provenance, one artifact serves all frameworks. The evidence object knows which controls it satisfies via STRM relationship mapping. When the Evidence Hub collects a Conditional Access policy configuration, CMCAE evaluates it against every mapped control across every active framework. One collection event, one artifact, one hash, applied everywhere the mapping holds.

This eliminates the absurd scenario where three different analysts collect three screenshots of the same Conditional Access policy for three different framework audits in the same quarter. That's not thoroughness. That's a process failure masquerading as diligence.

Auditor-ready packaging

Evidence in Kyudo doesn't live in a shared folder. When it's time for an audit, the Evidence Hub generates a structured evidence package: a ZIP archive containing every artifact, its metadata, its SHA-256 hash, its lineage, a freshness summary, and a gap report for controls that lack sufficient evidence.

An auditor receiving this package can verify every hash, trace every lineage chain, and confirm every freshness score independently. The compliance team doesn't need to explain where things came from or when they were collected. The evidence speaks for itself.

"Our auditor accepts screenshots"

They do. For now.

But audit standards are tightening. AICPA's guidance on IT audit evidence increasingly emphasizes completeness, accuracy, and integrity of system-generated information. Cyber insurance underwriters are asking for continuous evidence of control operation, not annual attestations. A screenshot from six months ago doesn't prove your MFA policy is enforced today. An evidence object with a 3-day-old timestamp and a SHA-256 hash does.

And screenshots don't scale across frameworks. Every new framework means another round of screenshot collection for overlapping controls. Evidence objects with cross-framework mapping are collected once and assessed everywhere.

Your Monday morning checklist

1. Audit your evidence formats. What percentage of your current evidence package is screenshots vs. system-generated artifacts? If it's more than 50% screenshots, your evidence has no integrity guarantee.

2. Check your freshness. Pick ten controls at random. When was the evidence last collected? If any artifact is more than 30 days old, you're presenting stale data as proof of current state.

3. Test your lineage. Pick one piece of evidence. Can you trace it from the framework requirement to the source system without leaving your GRC tool? If the answer involves opening a shared folder and reading a filename, your lineage is informal.

4. Measure your collection cost. How many person-hours per quarter does your team spend collecting, formatting, and organizing audit evidence? That's your automation target.

5. Ask about reusability. Does the same evidence automatically satisfy the same control across multiple frameworks? Or does someone manually copy it between framework folders?

Microsoft produces the security truth. Kyudo turns it into audit proof.

---

Kyudo's Evidence Hub captures evidence directly from source systems with SHA-256 hashing, automated freshness scoring, and full Compliance Graph lineage. No screenshots. No shared folders. No trust-me timestamps.

Book a demo to see evidence provenance in your Azure tenant.