CPCSC Level 1 Readiness: What Canadian Defence Suppliers Need to Do Before Attesting

Before you attest, make sure your scope and evidence match what you are claiming. That sentence is the entire job of CPCSC Level 1 readiness, and it is where most small Canadian defence suppliers are about to slip.

This is the operational companion to the CPCSC overview. The overview tells you what CPCSC is and why Level 1 matters now. This page tells you how to actually get ready: define your scope, trace your Specified Information flows, walk the 13 ITSP.10.171 controls, retain the right evidence, lodge the attestation in CanadaBuys, and survive a spot check.

What Level 1 is and when it applies

CPCSC Level 1 is an annual self-assessment against 13 security requirements drawn from ITSP.10.171, the Canadian Centre for Cyber Security publication that mirrors NIST SP 800-171 with no substantial technical changes. Level 1 applies when a defence contract carries a Level 1 clause, which is happening on select contracts starting summer 2026.

Two properties shape readiness:

• Certification is required at contract award, not throughout the bidding process. You can bid without attestation, but you cannot be awarded a Level 1 contract until you have a valid one on file.
• The self-assessment is annual. The expiry date matters. A lapsed attestation is, contractually, no attestation.

That means the right time to be ready is “before the contract you actually want to win lands,” and the right thing to renew is on a calendar, not on memory.

How to define scope

Scope is the single most important decision in a Level 1 program, because everything else (controls, evidence, attestation) is true only inside scope. The scope question is straightforward in principle: which systems store, process, or transmit Specified Information (SI)?

A defensible Level 1 scope statement names, at minimum:

1. The categories of SI you handle (non-public contract details, controlled goods information, protected information).
2. The user populations who touch SI (employees, contractors, named third parties).
3. The endpoints those users use to touch SI.
4. The internal systems (file servers, ERP, CAD, project management) where SI is stored or processed.
5. The cloud tenancies and SaaS services in the SI path.
6. The network boundaries that separate SI-handling systems from the rest of your environment.

Suppliers who undersize scope (“only this one folder is in scope”) usually fail a verification later, because SI tends to flow into email, shared drives, and personal devices. Suppliers who oversize scope (“everything is in scope”) usually fail to maintain evidence, because the control burden is too high. The right scope is the smallest one that honestly contains the SI flow.

How to map SI flows

A flow map answers a different question than the scope statement. Scope says where SI lives. Flow says how SI moves. You need both.

A minimum-viable SI flow map captures, for each SI category:

• The entry point (how SI enters your environment: emailed PDF, CanadaBuys download, prime contractor portal, EDI feed)
• The internal handoffs (who opens it, where they save it, who else opens it)
• The transformation steps (extracted into a CAD model, summarised into a quote, attached to an internal project file)
• The egress points (sent to a sub, archived to backup, deleted)
• The retention boundary (when SI must be sanitised or destroyed)

Two things almost always surface in the flow map that were not in the original scope draft: personal email forwards and chat-tool drops. Both are common and both are in scope. Address them before you attest, not after.

How cloud and SaaS services affect scope

Cloud and SaaS are not out-of-scope by virtue of being managed services. If SI lands in a tenancy, the tenancy is in scope. What changes is how the controls are implemented and evidenced.

For each cloud or SaaS service in the SI path, document:

• Provider name, service name, and tenancy identifier.
• Where the data is stored (region matters for Controlled Goods).
• Which controls the provider implements on your behalf (data-at-rest encryption, infrastructure hardening, malicious-code scanning at the platform layer).
• Which controls remain your responsibility (account lifecycle, MFA, sharing settings, sanitisation when access ends).
• How you obtain evidence the provider’s controls are operating (SOC 2 Type II, ISO 27001 certificate, provider-issued compliance attestation).

The split between “what the provider does” and “what you must still do” is where most small suppliers under-document. Microsoft 365 does not, on its own, attest your CPCSC Level 1 posture.

The 13 controls, with implementation notes and evidence to retain

The 13 Level 1 controls come from ITSP.10.171, the Canadian counterpart to NIST SP 800-171. Below, each control is listed by its official ITSP.10.171 identifier, with implementation guidance and the evidence you should retain.

Access control

1. Account management (03.01.01).

Run one account inventory tied to identity, with no shared logins, offboarding inside a defined window, and a documented joiner-mover-leaver process. Retain the inventory export, the last 12 months of joiner-mover-leaver records, and a sample termination ticket showing the access-revocation timestamp.

2. Access enforcement (03.01.02).

Role-based access in each SI-touching system, with a quarterly access review you can defend on paper. Retain the role-to-permission mapping per system, the signed access-review records, and an exception log for any standing privilege.

3. Use of external systems (03.01.20).

Keep a register of every external connection (VPNs to subs, prime portals, EDI feeds, file-share invitations) and an approval gate for new ones. Retain the register, a sample approval record, and traffic logs showing the connection in use is the one you documented.

4. Publicly accessible content (03.01.22).

SI never goes on the public website, marketing channels, or public buckets. Name a reviewer for anything that does go out. Retain the publishing approval log, periodic public-bucket scan output, and a sample reviewer signoff.

Identification and authentication

5. User identification, authentication, and re-authentication (03.05.01).

Every user account maps to a real person, with re-authentication enforced after a defined idle window or on a privilege change. Retain the user-to-account mapping, the re-authentication policy, and a sample session-timeout configuration screenshot.

6. Device identification and authentication (03.05.02).

Device inventory exists and is current. SI-touching systems authenticate the devices that connect to them, not just the users. Retain the device inventory, the device-registration or enrolment policy, and a sample MDM (or equivalent platform) compliance report.

7. Multi-factor authentication (03.05.03).

MFA on every SI-touching system, no exceptions. Use phishing-resistant MFA (FIDO2, certificate-based) where the system supports it, and fall back to TOTP only when no stronger option exists. Retain the MFA enforcement screenshot per system, the MFA factor inventory, and the exception register (which should be empty or short and time-bounded).

Media protection

8. Media sanitization (03.08.03).

Write the sanitisation procedure for laptops, drives, and removable media. Get a certificate of destruction from any third-party disposal vendor. Retain the procedure, the signed certificates, and an asset-disposal log tying serial numbers to sanitisation events.

Physical protection

9. Physical access authorizations (03.10.01).

Keep an authorised-personnel list for any facility, room, or rack that houses SI-handling systems. Issue and revoke physical access tokens against that list. Retain the authorisation list, sample new-grant approvals, and the revocation log for access that ends.

10. Physical access control (03.10.07).

Locked office or facility, an access-card or key register, visitor sign-in, and an escort rule for visitors near SI-handling systems. Retain the cardholder list, the facility access policy, sample visitor log entries, and the key/card issuance and recovery log.

System and communications protection

11. Boundary protection (03.13.01).

Managed firewall, cloud or on-premise, with default-deny outbound on sensitive segments and a documented rule set. Public-facing infrastructure (web servers, jump hosts) sits in a separate segment from SI-handling systems; the cloud equivalent is a separated VPC or subscription with controlled peering. Retain the firewall rule export, change-control records for rule edits, a sample log review that evidences the rules are in force, and a network diagram showing the public-vs-internal separation.

System and information integrity

12. Flaw remediation (03.14.01).

Patch management policy with named SLAs, vulnerability scanning on a defined cadence, ticketing for remediation. Retain the patch policy, the last 12 months of patch reports for SI-handling systems, and vulnerability scan reports with the remediation evidence attached.

13. Malicious code protection (03.14.02).

Managed endpoint protection on every SI-touching endpoint. Auto-update enabled. Scan schedule documented. Alerts triaged. Retain the deployment report (coverage %), an update-status report, and a sample alert-handling ticket.

The thirteen controls, identifiers, and family groupings above are the current Government of Canada CPCSC Level 1 criteria, as published on the CPCSC Level 1 criteria page on canada.ca and drawn from ITSP.10.171 (Canadian Centre for Cyber Security). For the companion CCCS guidance on how Level 1 self-assessment evidence is structured, see ITSP.10.171-01, Assessing Security Requirements for Specified Information. The functional posture under each control is what Level 1 attestation is asserting against the authoritative text.

CanadaBuys and the attestation process

CanadaBuys is where the attestation lives. The process, in order:

1. Complete the self-assessment internally. Record scope, the 13 control statements, evidence pointers, and an explicit “implemented / partially implemented / not implemented” status per control.
2. Have a named accountable individual (typically the CEO, CIO, or designated security lead) sign the self-attestation.
3. Lodge proof of self-attestation in CanadaBuys, including the expiry date.
4. Retain the internal assessment package so it can be produced if Canada verifies specific controls.
5. Provide the proof of self-attestation when submitting a bid where Level 1 applies.

The CanadaBuys record is the visible artefact procurement officers see. The internal assessment package is what defends that record under verification. Both must exist; one without the other fails.

Common gaps in small supplier environments

Patterns we keep seeing in small Canadian defence suppliers preparing for Level 1:

Shadow SI shows up in personal email almost every time. A sales contact receives an SI-carrying PDF, forwards it to a personal Gmail to read on a phone, and now both endpoints are in scope, one of them outside your control.

Account inventories are usually missing. “Whoever has a Microsoft 365 license” is a billing list, not an inventory. A real inventory ties each account to a person and to an access decision.

MFA is often half-deployed. Microsoft 365 is covered, but the CAD vendor portal, the prime contractor sharing site, and the bookkeeper’s accounting tool (the one with invoices that carry contract numbers) are not.

Public buckets drift. A staging bucket created for one project becomes the default upload location and ends up holding files it should not.

Sanitisation happens, evidence does not. Old laptops get wiped or destroyed, no certificate of destruction is kept, and a control that is actually implemented becomes one you cannot prove.

Annual renewals get forgotten. The first attestation gets celebrated, the renewal calendar never gets set, and the second-year contract is lost because the attestation lapsed.

Cloud provider attestations are never collected. The team relies on Microsoft, AWS, or Google for several controls, then cannot produce the provider’s compliance documentation when asked.

Each of these is fixable, and each is the kind of thing that will be found in a spot verification before it is found by a procurement officer.

How Pilotcore helps

Pilotcore runs a focused CPCSC Level 1 readiness assessment built around the operational outline on this page. The engagement produces:

• A defensible scope statement and SI flow map.
• A control-by-control walk of all 13 ITSP.10.171 Level 1 controls with implementation status and gap notes.
• An evidence pack indexed to each control, ready to support a spot verification.
• A signed self-attestation package and the CanadaBuys lodgement steps.
• A renewal calendar so the annual cycle does not lapse.

Nelson Ford, principal at Pilotcore and based in Ottawa, is a CISSP and CMMC Certified Professional, and works with Canadian defence suppliers on both CPCSC and the CMMC side requirements when the supply chain spans both countries.

Before you attest, make sure your scope and evidence match what you are claiming. If you have a defence contract in front of you that may carry Level 1, a scoped readiness assessment now is cheaper and faster than a scramble at award time. Book a CPCSC readiness conversation.

About the author

Nelson Ford - CMMC CCP / CISSP

• CISSP
• CMMC Certified Professional

Nelson Ford is the principal at Pilotcore, based in Ottawa. He is a CISSP and CMMC Certified Professional, and works with Canadian defence suppliers on CPCSC readiness and US contractors on CMMC. He writes Pilotcore's compliance and zero-trust commentary.

Frequently asked questions

What are the 13 CPCSC Level 1 controls?

The 13 Level 1 controls are drawn from ITSP.10.171 and cover account management, access enforcement, use of external systems, publicly accessible content, user identification and authentication, device identification, multi-factor authentication, media sanitization, physical access authorizations, physical access control, boundary protection, flaw remediation, and malicious code protection.

How do I scope my CPCSC Level 1 environment?

A defensible scope statement names the categories of SI you handle, the user populations who touch it, the endpoints and internal systems where SI lives, the cloud tenancies and SaaS services in the SI path, and the network boundaries that separate SI-handling systems from the rest. The right scope is the smallest one that honestly contains the SI flow.

Does Microsoft 365 cover my CPCSC Level 1 obligations?

Microsoft 365 implements some controls on your behalf (data-at-rest encryption, platform hardening, malicious-code scanning at the platform layer) but does not attest your CPCSC Level 1 posture. You remain responsible for account lifecycle, MFA, sharing settings, and sanitisation, and you must document which controls the provider implements and which controls remain your responsibility.

What evidence do I retain for CPCSC Level 1?

For each control, retain artefacts that prove implementation. That means account inventories with joiner-mover-leaver records, access-review signoffs, MFA enforcement screenshots, the network diagram, firewall change-control records, patch and vulnerability scan reports, endpoint protection coverage reports, certificates of destruction for sanitised media, and a signed self-attestation package.

How often does CPCSC Level 1 self-attestation renew?

The self-attestation is annual. The CanadaBuys record carries an expiry date, and a lapsed attestation is contractually treated as no attestation at all. Set a renewal calendar before the first attestation goes in, so the second-year contract is not lost to a missed renewal.

Where do I lodge the CPCSC self-attestation?

Proof of self-attestation, including the expiry date, is lodged in CanadaBuys. The internal self-assessment package (scope, control-by-control statements, evidence pointers) stays with the supplier and is produced if Canada verifies a specific control. Both must be current at the time of contract award.