.svg)
Table of Contents
- What Is ITSP.10.171?
- Who It Applies To
- How ITSP.10.171 Maps to CPCSC Levels
- The 17 Control Families
- Summary Table: All 17 Families at a Glance
- ITSP.10.171 vs. NIST SP 800-171 Revision 3
- Where Existing Programs Create a Head Start
- Building the Program, Not Just Checking Boxes
- FAQ
What Is ITSP.10.171?
ITSP.10.171 is Canada's technical standard for protecting controlled government information in non-government systems and organizations. Its full title is "Protecting Specified Information in Non-Government of Canada Systems and Organizations," and it was developed by CCCS to give the CPCSC program a concrete, auditable set of security requirements.
The standard draws heavily from NIST SP 800-171 Revision 3, which serves the same purpose in the U.S. for protecting Controlled Unclassified Information (CUI) in the defence supply chain. The structure is intentionally similar: 17 control families, comparable control language, and a shared lineage in NIST SP 800-53. But ITSP.10.171 is not a copy. CCCS adapted the controls for the Canadian context, introduced differences in how certain families are structured, and aligned the standard with Canadian legislative and procurement requirements.
The result is a standard that will feel familiar to anyone who has worked with NIST 800-171, while containing enough differences to require its own implementation effort.
Key Takeaway
ITSP.10.171 is the technical rulebook behind CPCSC. It defines 97 security controls across 17 families. Every certification level traces back to this standard.
Who It Applies To
ITSP.10.171 applies to any organization that handles, processes, stores, or transmits specified information on behalf of the Government of Canada. In practice, this means:
- Prime contractors holding Department of National Defence (DND) contracts that involve controlled information
- Subcontractors in the defence supply chain who receive or process controlled information from primes
- IT service providers whose infrastructure hosts or transmits controlled information, even if they don't access the content directly
- Any organization bidding on future DND procurements that require CPCSC certification
The scope is determined by the contract, not the organization's size. A 15-person engineering firm holding a single DND subcontract faces the same ITSP.10.171 requirements as a multinational prime, though the implementation scale differs.
Specified Information vs. CUI
ITSP.10.171 uses the term "specified information" rather than the American "Controlled Unclassified Information." The categories are not identical. Specified information covers unclassified government information that requires protection under Canadian policy, including federal contractual information and controlled information as defined by CPCSC.
How ITSP.10.171 Maps to CPCSC Levels
The CPCSC program uses ITSP.10.171 as its technical baseline, but not every certification level requires every control.
Level 1 is expected to draw approximately 13 requirements from 6 of the 17 families, producing an anticipated 71 assessment objectives. These numbers are based on CPCSC's alignment with CMMC Level 1 and industry analysis, as the government has not yet published the official Level 1 control list. The expected families cover foundational areas, primarily access control, identification and authentication, media protection, physical protection, system and communications protection, and system and information integrity. Companies self-assess annually and attest through Canada Buys.
Level 2 requires implementation of all 97 controls across all 17 families. Assessment is conducted by a third-party certification body accredited through the Standards Council of Canada (SCC). This is where the standard's full scope comes into play, and where the implementation effort increases significantly.
Level 3 builds on Level 2 with additional controls determined by DND, assessed directly by the department. The details of Level 3 requirements are still being defined.
The practical implication: organizations targeting Level 1 can focus on a subset of the standard, but those anticipating Level 2 contracts (starting April 2027) need to plan against the full 97-control scope now.
The 17 Control Families
ITSP.10.171 organizes its 97 controls into 17 families. Each family addresses a distinct security domain, from how users access systems to how vendors are managed in the supply chain. The families below are presented in the order they appear in the standard.
Access Control is the largest family and one of the most operationally intensive. It covers least privilege enforcement, account management, access enforcement, information flow control, session management, and remote access. These controls define who can reach what, under what conditions, and what happens when those conditions change.
Organizations with mature identity and access management practices will find overlap here. The gap typically appears in information flow enforcement, where the standard expects documented controls on how specified information moves between systems and networks, not just who can log in.
Personnel education requirements cover security awareness training for all users, role-based training for personnel with security responsibilities, and maintenance of training records. This family is straightforward in concept but requires documented evidence that training was delivered, tracked, and updated.
The common gap: organizations run annual security awareness training but lack role-based training for administrators, incident responders, and personnel who handle controlled information directly.
This family covers audit event definition, content of audit records, audit storage capacity, audit review and analysis, and audit reduction. The requirement is not just to log events but to review them, respond to anomalies, and retain records for the required period.
Organizations running SIEM tools or centralized logging platforms will have a foundation here. The ITSP.10.171 requirement goes further than "we have logs" and expects documented processes for what gets logged, who reviews it, and how anomalies escalate.
Configuration Management covers baseline configurations, change control, security impact analysis, least functionality, and configuration settings. The standard expects documented baselines for all systems in scope, a controlled change process, and evidence that systems are configured to the principle of least functionality, meaning unnecessary services, ports, and protocols are disabled.
This is where informal "we know our systems" practices fall short. The standard requires documented baselines, not institutional knowledge.
This family addresses identity verification: multi-factor authentication, identifier management, authenticator management, and device identification. MFA is a baseline expectation for all remote access and privileged accounts, and authenticator management includes password complexity, rotation policies, and protection of authentication credentials.
For organizations already enforcing MFA through an identity provider, much of this family maps to existing capabilities. The gap tends to appear in device identification, where the standard expects organizations to identify and authenticate devices (not just users) before granting access to controlled information.
Incident Response covers incident handling procedures, monitoring and reporting, testing, and the incident response plan itself. The standard expects a documented plan, defined roles and responsibilities, regular testing (tabletop exercises or simulations), and evidence that incidents are tracked through to resolution.
Having an incident response plan on paper is not sufficient. The standard looks for evidence that the plan has been tested and that personnel know their roles during an actual incident.
System maintenance controls cover controlled maintenance procedures, maintenance tools, nonlocal (remote) maintenance, and maintenance personnel oversight. The standard expects that maintenance activities are authorized, logged, and supervised, particularly when performed remotely or by external personnel.
This family tends to surface gaps in organizations that rely on third-party managed service providers for infrastructure maintenance without formal oversight procedures.
Media Protection covers access to media, marking, storage, transport, sanitization, and use restrictions. "Media" includes any physical or digital storage that contains specified information: hard drives, USB devices, backup tapes, mobile devices, and removable media.
The transport and sanitization controls are particularly relevant for organizations with on-premises infrastructure. The standard expects documented procedures for sanitizing media before disposal or reuse and for protecting media during transport between facilities.
This family addresses personnel screening, termination procedures, personnel transfers, and access agreements. Controls require that personnel with access to specified information undergo appropriate screening, that access is revoked promptly upon termination, and that transfer between roles triggers a review of access privileges.
The access agreement requirement means documented acknowledgement from each individual that they understand their security responsibilities, not just an employee handbook reference.
Physical Protection covers access authorizations, physical access control, monitoring, visitor access management, power equipment protection, fire protection, and alternate work site considerations. The standard expects controlled physical access to facilities where specified information is processed or stored, visitor logs, and environmental protections.
This family is often the largest gap for organizations that have operated primarily in cloud environments. Controlling physical access to a data center or server room requires different capabilities than managing IAM policies in AWS.
Risk Assessment covers the risk assessment process, vulnerability monitoring and scanning, and risk response. The standard expects periodic risk assessments, active vulnerability scanning, and documented decisions about how identified risks are treated (mitigated, accepted, transferred, or avoided).
The key word is "documented." Running vulnerability scans is common practice. Maintaining a risk register that tracks identified vulnerabilities through to remediation or acceptance decisions, with rationale, is where many organizations need to formalize their approach.
This family covers security assessments, system interconnections, Plan of Action and Milestones (POA&M), continuous monitoring, and the use of independent assessors. The standard expects that organizations periodically assess their own security controls, maintain a POA&M for identified deficiencies, and implement continuous monitoring.
At Level 2, this family also requires the involvement of independent assessors, which connects directly to the third-party certification requirement.
This family addresses boundary protection, cryptographic protection, collaborative computing controls, transmission confidentiality and integrity, and network disconnect. The standard expects encryption of specified information both at rest and in transit, boundary protection between network segments, and controls on collaborative computing devices (such as conferencing systems with microphones or cameras in areas where controlled information is discussed).
Encryption requirements are specific: the standard expects cryptographic mechanisms validated through recognized programs, not just "we use TLS."
System and Information Integrity covers flaw remediation, malicious code protection, security alerts and advisories, system monitoring, and information handling. The standard expects timely patching, endpoint protection, monitoring for indicators of compromise, and procedures for handling security alerts from vendors and government sources.
The flaw remediation requirement is time-bound. The standard expects that identified vulnerabilities are remediated within defined timeframes, not "when we get to it."
The Planning family covers security planning, the system security plan (SSP), and rules of behavior. The system security plan is the foundational document that describes the security controls implemented across the environment. It needs to be current, accurate, and reviewed periodically.
The SSP is also the primary artifact that assessors review during Level 2 certification. An incomplete or outdated SSP creates problems that extend well beyond this single control family.
This family covers acquisition process controls, system development lifecycle requirements, developer configuration management, and supply chain protections at the acquisition level. The standard expects that security requirements are defined during procurement, that development follows a secure SDLC, and that acquired systems meet the organization's security baseline.
For organizations that build custom software for defence contracts, the developer configuration management controls require documented secure development practices, not just "our developers follow best practices."
The newest and most forward-looking family covers SCRM plans, acquisition strategies, supply chain controls, and supplier assessments. The standard expects organizations to identify, assess, and manage supply chain risks, particularly for critical components and services.
This family reflects a broader shift across both Canadian and American defence procurement toward holding prime contractors accountable for the security posture of their entire supply chain, not just their own environment.
Mapping ITSP.10.171 to Your Environment?
We help teams build an effective security program across all 17 control families.
Summary Table: All 17 Families at a Glance
| Family | Code | Focus Area | Key Controls |
| Access Control | AC | User permissions, system entry | Least privilege, access enforcement, remote access, session management |
| Awareness and Training | AT | Personnel education | Security awareness, role-based training, training records |
| Audit and Accountability | AU | Logging and monitoring | Audit events, record content, storage, review and analysis |
| Configuration Management | CM | System setup standards | Baselines, change control, least functionality, security settings |
| Identification and Authentication | IA | Identity verification | MFA, identifier management, authenticator management, device ID |
| Incident Response | IR | Breach handling | Incident handling, monitoring, testing, IR plan |
| Maintenance | MA | System upkeep | Controlled maintenance, tools, nonlocal maintenance, personnel |
| Media Protection | MP | Storage safeguards | Media access, marking, storage, transport, sanitization |
| Personnel Security | PS | Staff vetting | Screening, termination, transfer, access agreements |
| Physical Protection | PE | Facility security | Access control, monitoring, visitors, power, fire protection |
| Risk Assessment | RA | Vulnerability identification | Risk assessment, vulnerability scanning, risk response |
| Security Assessment and Monitoring | CA | Control testing | Assessments, POA&M, continuous monitoring, independent assessors |
| System and Communications Protection | SC | Data transmission | Boundary protection, encryption, transmission integrity |
| System and Information Integrity | SI | Unauthorized modification prevention | Flaw remediation, malware protection, system monitoring |
| Planning | PL | Security strategy | System security plan, rules of behavior |
| System and Services Acquisition | SA | Procurement safeguards | Acquisition process, SDLC, developer config management |
| Supply Chain Risk Management | SR | Vendor oversight | SCRM plan, acquisition strategies, supplier assessments |
ITSP.10.171 vs. NIST SP 800-171 Revision 3
The relationship between ITSP.10.171 and NIST SP 800-171 Rev 3 is deliberate. CCCS built ITSP.10.171 using NIST 800-171 as the foundation, maintaining the same 17 control families and similar control language. The intent is interoperability: organizations operating in both Canadian and U.S. defence supply chains should be able to build one security program that addresses both standards.
That said, the standards are not identical. The differences fall into several categories.
Structural Alignment
Both standards use 17 control families with the same family names and codes (AC, AT, AU, CM, IA, IR, MA, MP, PS, PE, RA, CA, SC, SI, PL, SA, SR). The control numbering follows a similar convention. For organizations familiar with NIST 800-171 Rev 3, the ITSP.10.171 structure is immediately navigable.
NIST 800-171 Rev 3 introduced a significant restructuring from Rev 2, expanding from 14 families and 110 controls to 17 families and 97 requirements (consolidating overlapping controls while adding new families). ITSP.10.171 mirrors this Rev 3 structure, including the three families added in the revision: Planning (PL), System and Services Acquisition (SA), and Supply Chain Risk Management (SR).
Where They Align
The core technical controls are substantially the same. Access control, identification and authentication, audit and accountability, configuration management, incident response, and system integrity controls map closely between the two standards. Organizations that have implemented NIST 800-171 Rev 3 will find that a significant portion of their existing controls satisfy ITSP.10.171 requirements.
This alignment is by design. Canada's defence supply chain overlaps with the U.S. supply chain, and requiring fundamentally different security controls would create unnecessary burden for dual-jurisdiction contractors.
Where They Differ
The differences, while not dramatic in number, matter in implementation:
- Terminology: ITSP.10.171 uses "specified information" where NIST uses "Controlled Unclassified Information (CUI)." The categories are not perfectly interchangeable, and the handling requirements follow different policy frameworks.
- Assessment methodology: NIST 800-171 Rev 3 assessment feeds into the CMMC program with its own assessment methodology (defined in NIST SP 800-171A). ITSP.10.171 assessment objectives are defined within the standard and feed into the CPCSC assessment framework, which follows a different accreditation and certification model through SCC rather than the CMMC Accreditation Body (The Cyber AB).
- Regulatory context: NIST 800-171 exists within the U.S. federal acquisition regulation framework (DFARS). ITSP.10.171 operates within Canadian procurement policy under PSPC. The contractual mechanisms, reporting requirements, and government oversight bodies are different.
- Supplementary controls: At CPCSC Level 3, DND may impose additional controls beyond ITSP.10.171 that have no direct NIST 800-171 equivalent. The details of these are still being defined.
- Cryptographic requirements: Both standards require validated cryptographic mechanisms, but they reference different validation programs. NIST references FIPS 140 validation. CCCS references the Canadian Cryptographic Module Validation Program (CCMVP), though in practice, FIPS 140-validated modules are generally accepted.
Dual-Jurisdiction Contractors
Organizations operating in both Canadian and U.S. defence supply chains should build a unified security program against the superset of both standards. The control overlap is significant enough that maintaining a single program with documented mappings to both standards is more efficient than running parallel compliance efforts.
Where Existing Programs Create a Head Start
Organizations with existing security certifications, particularly SOC 2 or ISO 27001, have a meaningful head start on ITSP.10.171 implementation. The overlap is not one-to-one, but the foundational capabilities transfer.
SOC 2 Trust Services Criteria map well to several ITSP.10.171 families, particularly access control, change management, incident response, and system monitoring. The gap areas tend to be media protection, physical security (for cloud-native organizations), personnel screening, and supply chain risk management, which are domains SOC 2 addresses lightly or not at all.
ISO 27001:2022 has broader overlap, particularly through its Annex A controls covering physical security, supplier relationships, and human resource security. Organizations with ISO 27001 certification will find fewer gap areas, though the specific control language and assessment objectives in ITSP.10.171 still require their own implementation evidence.
CMMC or NIST 800-171 Rev 2/Rev 3 implementations provide the most direct overlap, given the shared lineage. The primary work is mapping existing evidence to ITSP.10.171 assessment objectives and addressing any Canadian-specific differences.
The Principle That Applies Across All Frameworks
An effective security program translates across frameworks. Organizations that have built real security capabilities, not just audit artifacts, will find that ITSP.10.171 requires evidence documentation and gap remediation rather than a ground-up rebuild.
Building the Program, Not Just Checking Boxes
ITSP.10.171 contains 97 controls. The temptation is to treat each one as a checkbox: implement the minimum, document the evidence, pass the assessment. That approach produces a certification, but it also produces a brittle security posture that requires significant effort to maintain at each assessment cycle.
The alternative is to treat ITSP.10.171 as a framework for building an effective security program where compliance is a byproduct of operational security practices. When access controls work because they are part of how the organization actually operates (not because an audit is approaching), the assessment becomes a documentation exercise rather than a scramble.
This distinction matters more at Level 2, where third-party assessors are looking for evidence that controls are operational, not just documented. Assessors trained in this space can distinguish between a program that runs continuously and one that was stood up for the assessment.
For organizations beginning their CPCSC journey, the CPCSC overview guide covers the certification program structure, timelines, and levels. For organizations that need support building or extending a security program to meet ITSP.10.171 requirements, Truvo's CPCSC compliance practice works with organizations across the defence supply chain. You can also reach out directly to discuss your specific situation.
Preparing for CPCSC?
Build an effective security program mapped to ITSP.10.171 requirements.
Frequently Asked Questions
What is the difference between ITSP.10.171 and CPCSC?
ITSP.10.171 is the technical standard that defines the security controls. CPCSC is the certification program that uses ITSP.10.171 as its assessment baseline. Think of ITSP.10.171 as the rulebook and CPCSC as the certification process that verifies compliance with those rules. CPCSC also defines the certification levels, assessment methodology, and accreditation framework that sit on top of the technical controls.
Is ITSP.10.171 the same as NIST 800-171?
Not exactly. ITSP.10.171 was built using NIST SP 800-171 Revision 3 as a foundation, and the two standards share the same 17 control families with substantially similar technical controls. However, they differ in terminology, assessment methodology, regulatory context, and certain implementation specifics. Organizations cannot submit a NIST 800-171 assessment as evidence of ITSP.10.171 compliance; each standard requires its own assessment against its own objectives.
How many controls are in ITSP.10.171?
ITSP.10.171 contains 97 security controls organized across 17 families. For CPCSC Level 1, organizations are expected to be assessed against approximately 13 requirements drawn from an anticipated 6 families, producing roughly 71 assessment objectives. These figures are based on CPCSC's alignment with CMMC and have not been officially confirmed by the government. Level 2 requires implementation and assessment of all 97 controls.
Do I need to implement all 97 controls for Level 1?
No. Based on CPCSC's alignment with CMMC Level 1, Level 1 is anticipated to require approximately 13 requirements from 6 control families, covering roughly 71 assessment objectives. The government has not yet published the official Level 1 control list, but the expected families are Access Control, Identification and Authentication, Media Protection, Physical Protection, System and Communications Protection, and System and Information Integrity. However, organizations anticipating Level 2 requirements should plan against the full standard, as the remaining controls take time to implement properly.
Can existing SOC 2 or ISO 27001 controls satisfy ITSP.10.171 requirements?
Existing certifications provide a meaningful head start but do not satisfy ITSP.10.171 on their own. SOC 2 and ISO 27001 overlap with several ITSP.10.171 families, particularly in access control, incident response, and system monitoring. Gap areas typically include media protection, supply chain risk management, and certain physical security controls. The most effective approach is to map existing controls to ITSP.10.171 assessment objectives, identify gaps, and extend the program to cover them.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.
Ready for CPCSC Level 1?
Score your readiness across the 6 expected control families. Free.
Take the Scorecard