It is clear what it proves
The record names the system, tenant, device, facility, process or population being assessed.
How to turn policies, configurations, inventories and routine security work into a clear evidence record that supports each Level 1 answer.
The record names the system, tenant, device, facility, process or population being assessed.
Exports, screenshots and reviews include a date or can be tied to a dated source record.
The evidence covers the users, devices and systems included in the Level 1 scope, not a convenient subset.
A named person or role operates the control, reviews exceptions and keeps the evidence current.
The supplier knows how the record was generated and can repeat the review during the next cycle.
The policy, configuration, interview answers and observed practice do not contradict one another.
This matrix is a practical starting point. The official criteria list broader potential assessment objects and methods, and the supplier should retain the evidence that best fits its actual implementation.
| Control | Evidence examples | What to verify |
|---|---|---|
| 01. Account management 03.01.01 | Account exports, approved-user lists, role or group reports, offboarding records, disabled-account reports, review notes and relevant sign-in or audit records. | Assuming the directory is accurate without a dated review or leaving shared, dormant and former-user accounts unexplained. |
| 02. Access enforcement 03.01.02 | Permission reports, approved access requests, role assignments, shared-drive or application access exports, configuration settings and periodic access reviews. | Having a policy that says “least privilege” while broad groups or inherited permissions still provide access to people who do not need it. |
| 03. Use of external systems 03.01.20 | Approved-system lists, BYOD or remote-work rules, provider agreements, security requirements, device-compliance reports, remote-access settings and portable-media restrictions. | Treating Microsoft 365, a subcontractor portal or an employee’s personal device as “outside the scope” even though it stores, processes or transmits specified information. |
| 04. Publicly accessible content 03.01.22 | Publisher lists, approval records, training records, website-content reviews, public-system audit logs and records showing removal or response to exposed information. | Checking the public website once while ignoring shared links, document portals, social media, job postings and cloud files made public by link. |
| 05. User identification, authentication and re-authentication 03.05.01 | User directories, identity settings, authentication policies, account lists, re-authentication settings, application configuration and sign-in records. | Relying on a shared shop-floor or office account that makes it impossible to determine who accessed or changed protected information. |
| 06. Device identification and authentication 03.05.02 | Device inventories, management-platform exports, enrolment records, certificates, connection reports, conditional-access settings and approved-device lists. | Knowing which laptops were purchased but not knowing which computers and phones can currently connect to the systems in scope. |
| 07. Multi-factor authentication 03.05.03 | MFA policy and configuration exports, conditional-access rules, authentication-method reports, administrator settings, sign-in reports and documented exceptions. | Showing that some employees enrolled in MFA while break-glass accounts, administrators, legacy protocols or another application remain outside the policy. |
| 08. Media sanitization 03.08.03 | Sanitization procedures, wipe logs, disposal or destruction certificates, asset-return records, chain-of-custody records and disposition approvals. | Deleting files, resetting a device or trusting a recycler without retaining evidence that the media was sanitized appropriately. |
| 09. Physical access authorizations 03.10.01 | Authorized-person lists, approval records, badge or key assignments, periodic review records, access-removal records and facility procedures. | Assuming a locked exterior door proves authorization when keys, codes and badge lists have not been reviewed or tied to named people. |
| 10. Physical access control 03.10.07 | Visitor and entry logs, key or badge inventories, access-control configurations, escort procedures, lock-change records, photos or diagrams and review records. | Protecting the server room while printers, paper files, loading areas or an unattended reception desk expose the same specified information. |
| 11. Boundary protection 03.13.01 | Network diagrams, firewall or gateway configurations, remote-access rules, approved-connection lists, network logs, segmentation settings and security architecture notes. | Providing a firewall screenshot without showing that all relevant external connections pass through it or that public systems are separated from internal systems. |
| 12. Flaw remediation 03.14.01 | Patch reports, vulnerability records, update policies, remediation tickets, change records, firmware inventories, exception approvals and recent correction logs. | Relying on automatic updates without reviewing failures, unsupported devices, firmware, third-party applications or systems that were offline. |
| 13. Malicious code protection 03.14.02 | Endpoint-protection status reports, configuration exports, update records, scan results, detection and quarantine logs, alert tickets and exception records. | Paying for endpoint protection but leaving devices inactive, unmanaged, out of date or excluded without a documented reason and compensating safeguard. |
A spreadsheet or controlled list is often enough. Record the control ID, evidence name, system or facility covered, owner, date collected, review frequency, storage location, exceptions and next review date. The register should point to source records rather than becoming a second pile of screenshots that nobody can interpret next year.
A useful screenshot identifies the tenant or system, the relevant setting, the date and enough context to understand coverage. Crop out unrelated personal information, but do not crop away the evidence’s identity. Where possible, keep exports or reports alongside screenshots because they can show complete populations and exceptions more reliably.
Government guidance says Level 1 evidence should be retained for the duration of the attestation cycle, or at least one year. Keep the evidence secure, access-controlled and easy to retrieve. Replace or supplement it when the environment changes.
Source review completed July 27, 2026. Contract documents and current Government of Canada instructions control where they differ from general guidance.
CyberTECT supports Canadian defence suppliers with CPCSC Level 1 readiness, evidence organization and practical implementation planning.