Compliance Evidence Collection Checklist (SOC 2 / ISO 27001 dual)
Purpose & Scope:
This checklist structures evidence collection for SOC 2 Type II and ISO 27001 audits by mapping Trust Services Criteria and Annex A controls to specific artifacts. It ensures auditors receive complete, timely, and properly formatted evidence, reducing back-and-forth during audit fieldwork.
Instructions:
The evidence owner (typically the compliance officer or control owner) completes this checklist during each evidence collection cycle. Update the "Value" column with the actual evidence location or status before each audit request. Review and refresh evidence per the frequency indicated in the "Freshness Requirement" column.
Evidence Collection Template
| # | Control ID | Control Description | Evidence Required | File Naming Convention | Freshness Requirement | Upload Location | Guidance | Value |
|---|---|---|---|---|---|---|---|---|
| 1 | CC1.1 / A.5.1 | Establishment of information security policies | Approved Information Security Policy document | policy_info-security_v[version]_[yyyy].pdf | Reviewed annually; version must be current | evidence/policies/ | Link to the latest board‑approved policy. Include version number and approval date. | [Policy Document URL] |
| 2 | CC1.2 / A.6.1 | Internal organization roles and responsibilities | Organizational chart showing security roles | org-chart_security-[yyyy]-[mm].pdf | Updated quarterly or upon reorganization | evidence/organizational/ | Highlight roles with security accountability (e.g., CISO, IT manager). | [Org Chart URL] |
| 3 | CC2.1 / A.9.1 | User access provisioning process | Access provisioning workflow diagram + sample ticket | access-provisioning_[system]_v[version].drawio<br>access-ticket-sample_[system]_[yyyy]-[mm]-[dd].pdf | Diagram reviewed annually; sample ticket from last 30 days | evidence/access-control/ | Provide end‑to‑end process from request to revocation. Include separation of duties. | [Workflow Diagram] <br> [Sample Ticket] |
| 4 | CC2.2 / A.9.2 | User access review documentation | Access review reports for privileged/user accounts | access-review_[system]_[yyyy]-[mm].xlsx | Conducted quarterly; report from most recent review | evidence/access-control/ | Include reviewer name, date, account list, and action taken (retain/modify/remove). | [Access Review Report] |
| 5 | CC3.1 / A.12.1 | Change management procedure | Change management policy + sample RFC | change-mgmt-policy_v[version].pdf<br>rfc-sample_[yyyy]-[mm]-[dd].pdf | Policy reviewed annually; RFC from last 30 days | evidence/change-management/ | Show how changes are requested, approved, tested, and documented. | [Policy] <br> [Sample RFC] |
| 6 | CC4.1 / A.12.4 | Logging and monitoring setup | Centralized logging configuration + sample alert | logging-config_[system].yaml<br>alert-sample_[yyyy]-[mm]-[dd].txt | Configuration reviewed quarterly; alert from last 30 days | evidence/monitoring/ | Demonstrate collection of security‑relevant events (auth, firewall, AV). | [Config File] <br> [Sample Alert] |
| 7 | CC5.1 / A.12.6 | Vulnerability management process | Vulnerability scan report + remediation tracker | vuln-scan_[asset-type]_[yyyy]-[mm].pdf<br>remediation-tracker_[yyyy]-[mm].xlsx | Scans conducted monthly; tracker updated weekly | evidence/vulnerability/ | Include scan scope, severity ratings, remediation due dates, and status. | [Scan Report] <br> [Tracker] |
| 8 | CC6.1 / A.14.2 | Secure development lifecycle | SDLC policy + threat model sample | sdlc-policy_v[version].pdf<br>threat-model-sample_[feature]_[yyyy]-[mm].drawio | Policy reviewed annually; threat model from last major release | evidence/application-security/ | Show how security is integrated into design, development, and testing phases. | [Policy] <br> [Threat Model] |
| 9 | CC7.1 / A.16.1 | Incident response procedure | IR plan + tabletop exercise report | incident-response-plan_v[version].pdf<br>ir-tabletop-[scenario]_[yyyy]-[mm].pdf | Plan reviewed annually; exercise conducted semi‑annually | evidence/incident-response/ | Include roles, communication plan, and lessons learned from tests. | [IR Plan] <br> [Tabletop Report] |
| 10 | CC8.1 / A.18.2 | Compliance with legal requirements | Regulatory compliance matrix | regulatory-matrix_[jurisdiction]_[yyyy].xlsx | Updated upon regulatory change or annually | evidence/legal-compliance/ | Map applicable laws/regulations to controls and evidence of compliance. | [Compliance Matrix] |
Version: 1.0
Review Cycle: Quarterly (or as frameworks update)
Owner: Compliance Officer
Key Takeaways
- Assign Clear Ownership: Designate a single evidence owner for each control to avoid gaps and duplication.
- Use Consistent Naming: Follow the file‑naming conventions exactly; auditors love predictable, searchable files.
- Mind Freshness: Track the “Freshness Requirement” column vigilantly—most items need quarterly or annual updates, so set calendar reminders.
- Centralize Storage: Keep all artifacts in the prescribed
evidence/folders; a single shared drive or DLP‑protected repository works best. - Document Review Process: Record who reviewed each artifact and when, then attach that sign‑off to the “Value” field.
- Run a Mock Review: Before the official audit, have an internal reviewer walk through the checklist to catch missing or outdated evidence.
Conclusion
A well‑maintained evidence collection checklist bridges the gap between your security controls and the auditor’s expectations. By mapping each SOC 2 and ISO 27001 requirement to a concrete artifact, you reduce the back‑and‑forth that typically drags audit timelines. Keep the checklist current, store files consistently, and revisit it each quarter—or whenever a framework update lands. Doing so not only smooths the audit process but also reinforces a culture of continuous compliance throughout the organization.
Next Steps:
- Schedule a quarterly review meeting with all control owners to verify that each “Value” entry reflects the latest evidence.
- Conduct a mock audit at least one month before the official audit window to surface any gaps early.
- Update the checklist whenever a new control is added or an existing standard is revised, and communicate those changes to the entire compliance team.
By treating this checklist as a living document rather than a static form, you’ll keep audits on track, minimize surprise requests, and demonstrate to stakeholders that security is an ongoing priority.