Evidence Binder
The evidence binder is your organized collection of all documentation, configurations, screenshots, and records that demonstrate compliance. The assessor references it throughout the assessment. How you organize it directly affects how smoothly the assessment runs.
Structure
Section titled “Structure”Organize by requirement family, with each requirement having its own folder or section. The assessor works through requirements systematically — they should be able to find the evidence for any specific requirement without help.
Evidence Binder/├── 3.1 Access Control/│ ├── 3.1.1 — Who Gets In/│ │ ├── Policy — Access Control Policy v3.2 (signed).pdf│ │ ├── Config — Entra ID user list export (2025-03-15).csv│ │ ├── Config — Intune device compliance status (2025-03-15).png│ │ ├── Process — Offboarding workflow screenshot.png│ │ └── Review — Q1 2025 access review record.pdf│ ├── 3.1.2 — What They Can Do/│ │ └── ...│ └── ...├── 3.2 Awareness & Training/│ └── ...└── ...For Each Requirement, Include
Section titled “For Each Requirement, Include”Policy — the governing document. Signed, dated, approved. The policy that establishes the rule this requirement enforces.
Procedure — the operational steps. How staff actually implement the policy. A procedure document, a runbook, or a documented workflow.
Configuration evidence — screenshots, exports, or reports showing the control is technically implemented. An Intune compliance dashboard showing 100% device compliance. A GPO settings export showing the password policy. A Sentinel analytics rule showing the correlation logic.
Operational evidence — recent records showing the control is active and working. The last quarterly access review record. Patch compliance from the most recent cycle. A recent incident ticket. Last month’s vulnerability scan results. This proves the control isn’t just configured — it’s operating.
Personnel records — where applicable: training completion records, role assignments, signed acknowledgments, background check confirmations.
Evidence Quality Rules
Section titled “Evidence Quality Rules”Final form only. Drafts don’t count. Working papers don’t count. A policy that says “DRAFT” or hasn’t been signed is not evidence. An unsigned access review is not evidence. Everything must be approved and operational.
Date everything. The assessor needs to see that evidence is current. A screenshot without a date stamp could be from three years ago. Include the system name, date, and time in every screenshot. Export files with date-stamped filenames.
Be specific. A screenshot showing “BitLocker is enabled” on one workstation is evidence for that workstation. A compliance dashboard showing “47/47 devices compliant” is evidence for all of them. Choose the evidence that covers the most ground with the least ambiguity.
Keep it current. Evidence from six months ago may not reflect the current state. Refresh configuration evidence within 30 days of the assessment. Operational evidence (logs, reviews, scans) should include the most recent cycle.
Screenshots need context. A screenshot of a settings page means nothing if the assessor can’t tell which system it’s from. Include: the system name (visible in the title bar or breadcrumb), the date, and enough surrounding context to identify the setting.
Common Mistakes
Section titled “Common Mistakes”Evidence scattered across systems. The policy is in SharePoint, the screenshot is in someone’s email, the log is on a server. Consolidate everything into one organized location before the assessment.
Evidence doesn’t match the SSP. The SSP says “quarterly access reviews” but the evidence binder contains only one review from eight months ago. Every claim in the SSP should have corresponding evidence in the binder.
Over-documenting. 500 pages of raw log output for one requirement. The assessor doesn’t want to read a novel — they want a filtered report or a summary that demonstrates the control is working. Include enough to prove the point, no more.
Under-documenting. A single policy document for an entire family with no configuration or operational evidence. Policies prove you have rules. Configuration evidence proves you implemented them. Operational evidence proves they’re working. You need all three.