The Evidence Half-Life Problem

In January, your team collected evidence for 47 controls. Screenshots of firewall rules, exports of access reviews, PDFs of policy documents. Everything packaged, filed, cross-referenced. Your GRC platform shows 47 green checkmarks. Compliance posture: strong.

It's now March. Twelve of those firewall rules have been modified to accommodate a new SaaS integration. Three access reviews are overdue. One policy document was updated but the new version was never uploaded. Your GRC platform still shows 47 green checkmarks. Nothing changed in the system because nothing triggered a re-evaluation.

Your evidence decayed. Your platform didn't notice.

Evidence has a half-life

Radioactive materials decay at predictable rates. Carbon-14 has a half-life of 5,730 years. Audit evidence has a half-life too, but nobody measures it.

A configuration screenshot from January doesn't prove anything about March. It proves what was true in January. Every day that passes between collection and review, the probability that the evidence still reflects reality decreases. Configuration drift, personnel changes, policy updates, emergency access exceptions, vendor integrations, all of these happen continuously. Evidence collected once and never refreshed becomes progressively less truthful.

The problem is that traditional GRC platforms treat evidence as binary: collected or not collected. Present or absent. There's no concept of decay. A six-month-old screenshot of a Conditional Access policy receives the same "complete" status as a configuration pull from yesterday. The system has no mechanism to distinguish between them.

This isn't a UI problem. It's an architectural one. If your GRC platform stores evidence as files in a database without collection timestamps tied to automated freshness logic, age is invisible.

Why now: regulations are saying the word "continuous"

The regulatory landscape shifted from periodic to continuous in the last 24 months. The word "continuous" now appears in binding requirements, not just guidance:

PCI DSS v4.0.1 (enforced March 2025) explicitly requires ongoing monitoring of security controls. Requirement 12.4.2 mandates that targeted risk analyses be performed "at least once every 12 months and upon significant change." But the broader requirement set demands mechanisms for "detecting and alerting on failures of critical security control systems" on an ongoing basis. Collecting evidence annually doesn't meet a continuous monitoring obligation.

CMMC Level 2 requires organizations to "monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls." The word "ongoing" does meaningful work here. An evidence package from your last assessment is a historical record, not ongoing monitoring.

SOC 2 Type II evaluates operating effectiveness over the examination period (typically 6 or 12 months). Auditors need to see that controls operated consistently across the period, not just that they existed at two or three sample points. Evidence collected once at the start and once at the end, with nothing in between, creates sampling gaps that auditors increasingly flag.

DORA Article 6(5) requires financial entities to ensure that ICT risk management frameworks are "documented and reviewed at least once a year" and that testing of ICT systems occurs on a "regular basis." The implementing technical standards go further, requiring evidence of control testing frequency proportionate to risk.

The common thread: regulators no longer accept "we checked once and nothing's changed" as a compliance posture. They want evidence that controls are operating now, and they want visibility into how recently that was verified.

The freshness scoring model

Evidence freshness isn't subjective. You can measure it, score it, and build automation around the scores. Kyudo uses a three-tier model:

The zero-credit threshold at 30 days is deliberate. If you haven't verified a control in over a month, you don't know whether it's still operating. Giving partial credit to 60-day-old evidence would be lying about your posture.

When evidence crosses from fresh to aging, the control's confidence score in CMCAE maturity assessment decreases automatically. When it crosses to stale, the control drops to "unattested" status. Every framework that control maps to sees the degradation immediately.

This creates pressure in the right direction. The system doesn't wait for audit prep to discover that evidence is outdated. It alerts the moment freshness drops below threshold.

How decay compounds across frameworks

A single control in Kyudo's Controls Hub can map to requirements across 3-7 frameworks simultaneously. When the evidence supporting that control goes stale, every mapped framework is affected.

Consider a Conditional Access policy enforcing MFA for all users. This single control typically maps to:

• SOC 2 CC6.1 (Logical and physical access controls)
• ISO 27001 A.8.5 (Secure authentication)
• NIST CSF PR.AC-7 (Users, devices, and other assets are authenticated)
• PCI DSS 8.4.2 (MFA for all access into the CDE)
• CMMC AC.L2-3.5.3 (Multi-factor authentication)

If the evidence for this control goes stale, five framework scores degrade simultaneously. The control was collected once. The decay propagates everywhere.

Traditional GRC platforms don't show this cascade because they don't score freshness and they often store evidence per-framework rather than per-control. You might have a stale screenshot in your SOC 2 folder and not realize it affects your CMMC posture because they're tracked independently.

In the Compliance Graph, the relationship is explicit. One evidence artifact, typed edges to one control, typed edges to multiple framework requirements. When the evidence decays, the graph propagates the impact in real time.

How Kyudo does this

The Evidence Hub treats evidence collection as a continuous process, not a project. Here's the operational model:

Scheduled collection. Evidence pipelines run on defined schedules, typically daily or weekly depending on the control's risk tier. A high-risk control (MFA enforcement, encryption at rest, network segmentation) might collect daily. A lower-risk control (password complexity policy) might collect weekly. The schedule is configurable per control.

Change-triggered collection. When Defender XDR, Sentinel, or Azure Policy detects a configuration change relevant to a mapped control, the Evidence Hub triggers an immediate collection. You don't wait for the next scheduled run. The change itself triggers re-verification.

Freshness degradation. Every artifact has a collection timestamp. The system continuously evaluates age against the freshness tiers. When an artifact moves from fresh to aging, the control's confidence score drops. When it moves to stale, the control becomes unattested. No human action required.

Automated re-collection. When evidence approaches the staleness threshold, the system can automatically re-collect from the source integration (Microsoft Graph, Azure Resource Manager, Defender APIs). If the re-collection succeeds and the configuration matches the previous state, freshness resets to full. If the configuration changed, the new artifact is stored alongside the old one, creating a version history.

Drift detection. When a re-collected artifact differs from the previous version, the system flags the drift. Did the MFA policy change? Who changed it? When? Is the new configuration still compliant with the mapped control requirements? This turns evidence collection into a continuous control monitoring mechanism, not just an audit preparation activity.

The entire model runs on Kyudo's native Microsoft integrations: Defender XDR for security posture, Sentinel for event telemetry, Purview for data governance, Entra ID for identity configuration, Azure Policy for resource compliance.

The counter-argument: "30 days is too aggressive"

Some teams will argue that a 30-day staleness threshold is impractical. Controls don't change that often, they'll say. Policies are stable. Configurations don't drift in 30 days.

Three responses:

First, you don't know that configurations don't drift in 30 days unless you're checking. That's the entire point. The absence of evidence of change isn't evidence of absence of change. If you're not collecting, you're assuming.

Second, 30 days is the maximum, not the target. For high-risk controls, 7 days is the freshness window. For controls where configuration changes could have immediate compliance impact (encryption policies, access controls, network rules), even 7 days might be generous. The 30-day threshold is the absolute floor below which no confidence is warranted.

Third, automated collection makes the threshold trivial to meet. If evidence collection requires a human to open a portal and take a screenshot, then yes, 30 days is aggressive. If evidence collection is a scheduled API call that runs without human intervention, maintaining freshness costs nothing in ongoing labor. The constraint isn't the threshold. It's the automation.

Organizations that resist freshness scoring are typically organizations where evidence collection is still manual. The real objection isn't "30 days is too aggressive." It's "we can't collect evidence that frequently with our current process." That's not an argument against the threshold. It's an argument for automating collection.

From "collect before audit" to "collect always"

The evidence half-life problem forces a fundamental shift in how compliance teams operate. The old model:

1. Audit scheduled for Q3.
2. Evidence collection project starts in Q2.
3. Team spends 4-8 weeks assembling artifacts.
4. Evidence package shipped to auditor.
5. Gaps identified. Re-collection.
6. Audit complete. Evidence ignored until next cycle.

The new model:

1. Evidence collects continuously via automated pipelines.
2. Freshness scores are always visible. Gaps are always surfaced.
3. When audit starts, evidence package is already current.
4. Auditor receives evidence with verified freshness and integrity.
5. Gaps are small and recent because they were surfaced when they formed, not 6 months later.

This is the difference between reactive compliance (collect evidence in response to an audit) and ambient compliance (evidence exists as a continuous byproduct of control operation). The half-life problem disappears when collection is continuous because nothing ever gets old enough to decay.

Your Monday morning checklist

1. Age-test your evidence. Pick 10 controls at random from your current framework. Check when the evidence was last collected. If any artifact is older than 30 days, you don't actually know whether that control is operating.

2. Identify your highest-decay controls. Which controls have the most volatile underlying configurations? Access policies, firewall rules, encryption settings. These decay fastest and should be your first automation targets.

3. Map collection to risk tier. Not all controls need daily evidence. But high-risk controls (identity, access, encryption, network segmentation) should never be more than 7 days stale. Lower-risk controls can tolerate 14-21 days. Document your freshness targets.

4. Measure your re-collection cost. When an auditor flags stale evidence, how long does it take to re-collect and re-package? If the answer is hours, that's your case for automated collection pipelines.

5. Ask your GRC platform: does it score freshness? Not "does it store a timestamp." Does it actively degrade control scores when evidence ages? If not, your platform is showing you green checkmarks on stale data.

---

Kyudo's Evidence Hub scores every artifact for freshness automatically. Fresh evidence (< 7 days) gets full credit. Aging evidence (8-30 days) degrades confidence scores. Stale evidence (> 30 days) gets zero credit, and the control drops to unattested. No silent decay.

Book a demo to see freshness scoring applied to your actual control environment.