1. Purpose and Scope

This document defines what qualifies as acceptable evidence in the CERG operating model. It extends the evidence quality tiers (E1/E2/E3) defined in FLOW-001 §17 with specific quality rules, sampling methodology, and freshness requirements.

This standard applies to every CERG artifact that produces or references evidence: the Unified Control Baseline (CB-001), the Audit and Evidence Management Procedure (PRC-AUD-001), the Risk Register and Exception Process (PRC-RM-001), and all standards and procedures that define evidence requirements.

CERG-GOV-AUD-001 is authoritative for evidence quality, freshness, and sampling expectations. CERG-PRC-AUD-001 governs how evidence is collected, stored, tested, and produced during audit response. Where the procedure needs to determine whether evidence is acceptable, this standard governs.

Evidence proves the control works. A document that says a control exists is not evidence that it operates. An email that says “done” is not evidence. A screenshot with no date is not evidence. This standard defines what is.

2. Evidence Quality Rules

Every piece of evidence accepted into the CERG evidence library must answer these questions. If the answer to any required question is “no” or “unknown,” the evidence is insufficient for its claimed tier.

Required for All Evidence (E1 minimum)

Question	Required	Meaning
Who produced it?	Yes	A named person, system, or automated process. “The security team” is insufficient.
When was it produced?	Yes	A specific date or timestamp. “Last quarter” is insufficient.
What system/control does it apply to?	Yes	A specific control ID (from CB-001), asset, or requirement. “Access management” is insufficient.
What period does it cover?	Yes	A specific time window. “Current” is insufficient — current as of when?
Where is it stored?	Yes	A file path, URL, or repository location. Must be retrievable by someone other than the person who produced it.

Required for E2 (Control Operates)

Question	Required	Meaning
Is it complete?	Yes	The evidence covers the full scope claimed. A sample must be identifiable as a sample — see §5.
Is it tamper-resistant?	Preferred	Can the evidence be altered after collection? If yes, compensating controls (hash, read-only storage, audit log) must be documented.
Does it show a sample or full population?	Yes	Must be explicit. “We reviewed all 250 accounts” or “We sampled 25 of 250 accounts (see sampling methodology §5).”

Required for E3 (Control Is Effective)

Question	Required	Meaning
Is it repeatable?	Yes	Could someone else produce equivalent evidence using the same method? If the method is “I looked at it,” the evidence is not repeatable.
Does it prove design, operation, or both?	Yes	Must be explicit. A configuration export proves design. A test result proves operation. Both may be needed.
Is the evidence independent of the person asserting the control?	Required for E3	The person producing the evidence should not be the person whose work is being evidenced. Self-attestation is E2 at best. Independence means: a different person, an automated system, or an external assessor.
Does it include failure conditions?	Yes	What would the evidence look like if the control had failed? A test that always passes is not a test.

Evidence Tier Decision Table

If…	Then the evidence is at most…
Produced by the same person who operates the control	E2
No timestamp or date	E1 — insufficient for E2+
Cannot be retrieved independently	E1 — insufficient for E2+
Scope is undefined (“some accounts were reviewed”)	E1 — insufficient for E2+
Method is not documented (“I checked it”)	E2 — insufficient for E3
No failure condition defined	E2 — insufficient for E3
Automated, timestamped, independently retrievable, scope-defined, with failure conditions	E3

3. Bad Evidence — What Not to Accept

The following are common evidence submissions that should be rejected. Each represents a pattern, not an exhaustive list.

Screenshot with No Date

What it looks like: A screenshot of a configuration page. No visible timestamp. No URL. No indication of when it was captured or by whom.

Why it fails: Screenshots are tamperable, non-repeatable, and usually undated. A screenshot proves someone looked at a screen at some point. It does not prove the configuration was in that state during the audit period.

What to request instead: A configuration export with timestamp and origin metadata. A scripted configuration audit with output. An automated CSPM/CNAPP posture report.

Email Saying “Done”

What it looks like: An email thread where someone asks “is the access review done?” and someone replies “yes, done.”

Why it fails: An email is an assertion, not evidence. It does not show what was reviewed, what was found, what was remediated, or who performed the work. It does not prove the control operated — it proves someone sent an email.

What to request instead: The access review output: population list, sample methodology (if sampled), findings, remediations, reviewer sign-off with date.

Vendor Says Yes

What it looks like: A vendor responds to a security questionnaire with “yes” to every question. No supporting evidence.

Why it fails: Self-attestation without evidence is not evidence. A vendor that checks “MFA enforced” without providing the IdP policy configuration has not evidenced the control.

What to request instead: Vendor-provided evidence: SOC 2 report, ISO 27001 certificate, penetration test summary, configuration exports, or architecture documentation. If the vendor cannot provide evidence, the control status is “Inherited — Unverified” with documented residual risk.

Meeting Notes with No Action Owner

What it looks like: Meeting minutes stating “the team discussed the risk and agreed to monitor it.”

Why it fails: Discussion is not treatment. “Monitor” without a method, frequency, owner, and trigger is not a treatment strategy. Meeting notes do not create accountability.

What to request instead: A risk register entry with named owner, treatment strategy, due date, and next review date. The decision log entry documenting what was decided and by whom.

Policy Text with No Proof of Operation

What it looks like: A policy document excerpt that says “access reviews shall be performed quarterly.” No evidence that one was performed.

Why it fails: A policy describes intent. Evidence proves execution. The gap between “we have a policy that says we do this” and “we did this” is where controls fail.

What to request instead: The output of the access review. Evidence that it was performed, not evidence that it was required.

Tool Export with No Scope Definition

What it looks like: A vulnerability scan report with 10,000 findings. No indication of which assets were scanned, which were excluded, or why.

Why it fails: Without scope definition, you cannot determine whether the scan covered the assets it needed to cover. A scan of 80% of assets with 10,000 findings may be worse than a scan of 100% of assets with 12,000 findings — but you cannot tell from the report alone.

What to request instead: Scan configuration showing target scope, exclusions with rationale, and scan date. The report should include “X of Y assets scanned; Z excluded with documented rationale.”

Sample with No Population

What it looks like: “We reviewed 25 accounts. They were all correct.”

Why it fails: Without knowing the population size (25 out of how many?) and the sampling method (random? judgmental? convenience?), you cannot assess whether the sample is representative. 25 out of 25 is complete. 25 out of 2,500 with no methodology is not auditable.

What to request instead: Population definition (total accounts), sample size, sampling method, and rationale. See §5 Sampling Methodology.

4. Design vs. Operating Effectiveness

Every control has two dimensions. Evidence must address the right one.

Design Effectiveness

Question: If the control were performed as designed, would it achieve its objective?

Evidence needed: - Control description (what is supposed to happen) - Configuration or design documentation (how it is implemented) - Comparison to the control objective (does the design match the intent?)

Example: An access review control requires quarterly review of all privileged accounts. The design evidence is the access review procedure document and the IdP configuration showing privileged role definitions. This proves the control is designed to identify and review privileged access.

Design is NOT sufficient to prove the control operates.

Operating Effectiveness

Question: Was the control actually performed consistently during the period under review?

Evidence needed: - Output of the control’s operation (the actual review results) - Evidence of cadence (was it done when it was supposed to be done?) - Evidence of completeness (was the full scope covered?) - Evidence of follow-through (were findings remediated?)

Example: The quarterly access review output: population list of 47 privileged accounts, sample of 15 reviewed, 2 accounts flagged for excessive access, both remediated and re-validated. Review performed 2026-06-15, next review due 2026-09-15. This proves the control operated.

Testing Both

For Tier 1 controls (Critical systems, regulated environments), test both:

Design test: Review the control documentation. Walk through the control with the control owner. Confirm the design addresses the control objective.
Operating test: Select a sample from the audit period. Examine evidence for each item in the sample. Confirm the control was performed as designed, at the required cadence, with appropriate follow-through.

Status Implications

Design	Operating	Control Status
Designed	Operating with evidence	Implemented
Designed	Operating, evidence incomplete	Partially Implemented — evidence gap documented
Designed	Not operating consistently	Partially Implemented — operating gap documented
Designed	Not yet operating	Planned — implementation in progress
Not designed	N/A	Planned or Not Implemented

5. Sampling Methodology

This section is the canonical CERG sampling standard for evidence review and control testing. When testing a control across a population, sampling is acceptable if the methodology is documented and defensible. Regulatory, assessor, or auditor-specific sampling requirements override these CERG defaults for that engagement and must be documented in the test plan.

When Sampling Is Acceptable

The population is large enough that full-population testing is impractical
The control produces consistent results (not highly variable)
The sampling method is documented before testing begins
The sample is representative of the population

When Full-Population Testing Is Required

The population is small (<30 items) — test all of them
The control is Tier 0/Tier 1 (Crown Jewel / Critical systems)
The control has previously failed
A regulatory requirement mandates full-population testing
The evidence is for an E3 claim and the control is high-variability

Sample Size Guidelines

Population Size	CERG Baseline Minimum Sample	For High-Risk Controls
<30	Full population	Full population
30-100	25	30
101-500	50	80
501-1,000	80	120
1,001-5,000	100	200
>5,000	150	300

These are baseline defaults, not statistical guarantees. Adjust based on control risk, prior test results, regulatory requirements, assessor direction, and whether the evidence supports an E2 or E3 claim. Document the rationale for any deviation.

Sampling Method

Method	When to Use	Documentation Required
Random	Preferred. Every item has equal selection probability.	Random seed or selection method. List of selected items.
Judgmental	When specific high-risk items must be included. Supplement with random sampling of remaining population.	Rationale for judgmental selection. List of items and why each was selected.
Stratified	When the population has distinct subgroups with different risk profiles.	Stratification criteria. Sample size per stratum.
Convenience	Not acceptable for audit evidence.	Not applicable; convenience sampling is prohibited.

Documentation Required for Every Sample

Population definition (what is the full set of items?)
Population size (how many items total?)
Sampling method (random, judgmental, stratified)
Sample size (how many were tested?)
Selection rationale (why this method and size?)
List of selected items
Test results per item
Exception handling (what if a selected item cannot be tested?)
Extrapolation (do sample results apply to the full population?)
Tester name and date

6. Evidence Freshness Rules

Evidence ages. An access review from 2024 does not prove the control operated in 2026. Every piece of evidence has a shelf life.

Freshness by Evidence Type

Evidence Type	Freshness Window	Refresh Trigger	Stale After
Access review output	Current review cycle + 30 days	Next scheduled review	Review date + 90 days
Joiners/movers/leavers (JML) log	Current month	Monthly	60 days
Exposure scan report	Current scan cycle	Next scheduled scan	Scan date + 30 days (IT) / 90 days (OT with approval)
MFA/enforcement configuration	Current quarter	Configuration change	90 days or on change
Firewall rule review	Current quarter	Next scheduled review	120 days
Backup restore test	Current test cycle	Next scheduled test	Test date + 180 days
Vendor SOC 2 report	Report period + 90 days	New report issued	Report expiration
Vendor ISO 27001 certificate	Certificate validity period	Renewal	Certificate expiration
Penetration test report	Current test cycle	Next scheduled test	Test date + 365 days
Policy/procedure approval	Current approved version	Document change	Version superseded
Incident lessons learned	Incident closure + 30 days	Corrective action completion	Action due date + 90 days
Risk acceptance	Acceptance date to expiration	Expiration or review date	Expiration date
Exception approval	Approval date to expiration	Expiration or review date	Expiration date
Training completion record	Current training cycle	Next training cycle	Training date + 365 days

Stale Evidence

Evidence that exceeds its freshness window is stale. Stale evidence: - Cannot be used to support E3 claims - Can be used for E2 claims only if a documented rationale explains why the evidence is still representative - Creates a Finding Record if the control relies on it and no fresh evidence is available - Must be flagged in the evidence index with “Stale” quality status

Freshness Monitoring

The Evidence Librarian checks evidence freshness at the monthly review. The evidence index spreadsheet (§7 of the Small Team Adoption Path) or the GRC platform tracks freshness dates. Stale evidence is flagged in the monthly metrics report.

6.1 Evidence Retrieval SLA (Adoption-Gate Tiered)

Evidence must be retrievable within the following SLA, tiered by adoption gate. The applicable gate is defined in the organization’s Adoption Gates document (CERG-GOV-IMP-005 where published; otherwise default to Gate 1).

Gate	Timeframe	Retrievable Within	Method	Evidence Index Required
Gate 1 (Spine)	0–90 days	15 business days	Manual collection from control owners; shared drive or email attachment acceptable	No — file naming convention suffices
Gate 2 (Operating)	90–180 days	10 business days	Structured evidence index (spreadsheet or lightweight GRC tool)	Yes — spreadsheet with control-id, path, date, owner
Gate 3 (Governed)	180+ days	5 business days	Tool-supported retrieval (GRC platform, evidence repository with search)	Yes — tool-native index
Gate 4 (Adaptive)	Mature program	2 business days	Automated evidence pipeline (API-driven collection, on-demand retrieval)	Yes — automated index updated continuously

SLA Clock Start. The retrieval SLA clock starts when the evidence request is formally received by the Evidence Librarian or the owning pillar leader, not when the request is initiated. The requesting party is notified within 1 business day that the SLA clock has started.

A process finding is opened if evidence is not retrievable within the applicable gate SLA, regardless of whether the underlying control is operating. The finding owner is the Evidence Librarian or the pillar leader responsible for the control evidence.

7. Business-Owner Accountability

Evidence proves a control operated. The business owner proves the risk is owned. These are different things and both must be present for risk acceptance.

Every Risk Acceptance Must Include

Field	Required	Meaning
Business Owner Name	Yes	A specific person outside the security team. Not a role. Not a department. A named individual.
Business Owner Acknowledgement	Yes	Evidence that the business owner understands and accepts the risk. An email is acceptable. An unsigned form is not.
Business Impact Statement	Yes	What happens to the business if the risk materializes? Revenue impact, operational impact, customer impact, regulatory impact. Written by the business owner, not by security.
Risk Scenario in Business Terms	Yes	The risk statement translated from security terminology into business terminology. “Unpatched systems” → “Potential for service outage affecting customer ordering for up to 48 hours.”
Acceptance Rationale	Yes	Why is accepting this risk better than treating it? Cost, operational impact, timing, vendor limitation? Must be specific.
Review Commitment	Yes	The business owner commits to reviewing this risk on the specified cadence.

Red Flags — Return the Acceptance

Reject a risk acceptance if: - The business owner field says “Security,” “CISO,” or is blank - The business impact statement was written by the security team - The acceptance rationale is “we have always done it this way” - The review commitment is missing or vague (“we’ll review it sometime”) - The business owner cannot be reached to confirm their acknowledgement

Template Enforcement

Every risk acceptance template, exception request form, and risk register entry must include business-owner fields that cannot be bypassed. The Risk Register Owner is responsible for rejecting incomplete submissions.

8. Evidence by Control Type

Different controls produce different evidence. This section maps control types to their expected evidence forms.

Control Type	Expected Evidence (E2 minimum)	E3 Evidence
Access Review	Review output showing population, sample/full scope, findings, remediations, reviewer, date	Independent re-performance of a sample by a different reviewer
JML (Joiners/Movers/Leavers)	JML log export from HRIS/IdP showing all changes in period	Sample validation: verify 5 leavers’ accounts were actually disabled
MFA Enforcement	IdP policy export showing MFA requirement, exclusions list, date	Authenticated login attempt without MFA — must be rejected
Vulnerability Scanning	Scan report with scope, exclusions, findings, date	Authenticated re-scan confirming critical/high findings resolved
Patch Management	Patch compliance report, deployment records	Verify a sample of critical patches were applied within SLA
Firewall Rule Review	Rule set export, review date, reviewer, findings	Automated rule analysis comparing current rules to approved baseline
Backup Restore Test	Test plan, test results, RTO/RPO achieved, system owner sign-off, date	Independent observation of a restore test
Change Management	Change record, security impact analysis, approval, implementation evidence, post-change validation	Verify a sample of changes: did control continuity check pass?
Vendor Risk Assessment	Completed assessment questionnaire, evidence reviewed, risk rating, review date	Independent review of a sample of vendor-provided evidence
Incident Response	Incident record, timeline, containment actions, lessons learned, corrective actions	Post-incident tabletop or simulation validating corrective actions
Security Awareness Training	Training completion report, population coverage, date	Phishing simulation results showing behavior change
Logging/Monitoring	Log source inventory, coverage report, detection rule inventory	Simulated attack: did the detection rule fire?

9. Document Control

Field	Value
Document ID	CERG-GOV-AUD-001
Version	1.0
Status	Approved
Effective Date	2026-06-11
Classification	Public
Owner	Governance Pillar Leader
Approved By	CISO
Parent Policy	`CERG-POL-001` - Cybersecurity Policy
Review Cycle	Annual
Next Scheduled Review	2027-06-11
Frameworks	NIST CSF 2.0
Regulations	Cross-cutting
Environments	All CERG-managed evidence

Revision History

Version	Date	Author	Change Summary
1.0	2026-06-11	Governance Pillar Leader	Initial release. Evidence quality rules, bad evidence examples, design vs. operating effectiveness, sampling methodology, freshness rules, business-owner accountability, and evidence-by-control-type mapping.

Review Triggers

Change to evidence requirements in CB-001
Feedback from audit or assessment findings
Change to regulatory evidence retention requirements
Direction from the CISO

Document	ID	Relationship
Cybersecurity Policy	`CERG-POL-001`	Parent policy
Cross-Pillar Operational Flows	`CERG-GOV-FLOW-001`	Evidence quality tiers (E1/E2/E3)
Unified Control Baseline	`CERG-GOV-CB-001`	Control definitions and evidence requirements
Audit and Evidence Management Procedure	`CERG-PRC-AUD-001`	Operational evidence collection and audit response
Control Effectiveness Framework	`CERG-GOV-CEF-001`	Control testing methodology
Risk Register and Exception Process	`CERG-PRC-RM-001`	Risk acceptance evidence requirements

Source: governance/CERG-GOV-AUD-001_Evidence_Quality_Standard.md · Download .md · View on GitHub

Table of Contents