Supply Chain Risk Management Under CPCSC

For most of the history of Canadian defence procurement, cybersecurity obligations ended at the prime contractor's perimeter. A prime could hold a subcontractor to contractual security terms, but there was no formal mechanism requiring the prime to verify, assess, or continuously manage the security posture of its supply chain. That arrangement is ending.

Under CPCSC, primes are accountable for the security of their entire supply chain, not just their own environment. Two control families in ITSP.10.171 enforce this: Supply Chain Risk Management (SR) and System and Services Acquisition (SA). Together, they require organizations to build structured programs for evaluating suppliers, managing acquisitions, and ensuring that every link in the chain meets a defined security baseline.

This is not a theoretical shift. Defence contracts increasingly flow through complex networks of primes, subcontractors, and technology providers. A vulnerability anywhere in that chain can compromise specified information just as effectively as a breach at the prime. CPCSC makes this the prime's problem to solve, with auditable controls and evidence requirements.

Supply Chain Risk Management (SR) Controls

The SR family addresses how organizations identify, assess, and manage risks introduced by their suppliers and service providers. It reflects a broader policy direction, visible in both CPCSC and NIST 800-171 Rev 3, toward holding contracting organizations responsible for security outcomes across the entire supply chain.

SCRM Plan

The foundation of the SR family is a documented Supply Chain Risk Management plan. This is not a vendor list or a spreadsheet of questionnaire responses. It is a formal document that defines:

• The organization's approach to identifying supply chain risks
• Roles and responsibilities for supply chain security decisions
• Criteria for evaluating and selecting suppliers
• Processes for ongoing monitoring and reassessment
• Incident response procedures specific to supply chain events

The SCRM plan serves as the governing document for all other SR controls. Without it, individual supplier assessments lack the structure and criteria needed to produce consistent, defensible results.

Supplier Assessments

SR controls require organizations to assess their suppliers against defined security criteria, not just at onboarding, but on an ongoing basis. The standard expects documented evidence that suppliers handling specified information meet security requirements appropriate to the sensitivity and volume of information they access.

This means organizations need a repeatable assessment methodology: questionnaires, evidence review, or third-party attestation reports, depending on the supplier tier. The key word is repeatable. Ad hoc assessments performed once during vendor selection and never revisited do not satisfy the intent of these controls.

Supply Chain Controls and Protections

Beyond individual assessments, the SR family requires organizations to implement controls that protect the supply chain as a system. This includes:

• Contractual security requirements that flow down to subcontractors
• Restrictions on where specified information can be processed or stored within the supply chain
• Requirements for suppliers to notify the prime of security incidents
• Controls over how specified information is shared, transmitted, and returned or destroyed at contract end

These controls create a framework of enforceable obligations rather than relying on trust or informal agreements.

Acquisition Strategies

SR also addresses how supply chain risk factors into procurement decisions. Security is not an afterthought applied to vendors after selection. The standard expects organizations to incorporate security criteria into acquisition strategies from the outset, evaluating potential suppliers on their security posture as part of the selection process rather than bolting on requirements after contracts are signed.

System and Services Acquisition (SA) Controls

While SR governs supplier relationships and risk management, the SA family focuses on how security requirements are embedded into the acquisition of systems, services, and software. Where SR asks how you manage your suppliers, SA asks how you ensure what you acquire is secure.

Acquisition Process Controls

SA requires that security requirements are defined during the procurement process, not after. When an organization acquires a system, platform, or service that will handle specified information, the acquisition documentation must include explicit security requirements derived from ITSP.10.171. This applies whether the acquisition is a commercial off-the-shelf product, a custom-developed system, or a cloud service.

The practical effect: procurement teams need security input before purchase orders are issued, not after systems are deployed and gaps are discovered.

System Development Lifecycle

For organizations that develop software or systems, either internally or through contracted development, SA controls require a secure system development lifecycle (SDLC). This includes:

• Security requirements defined at the design phase
• Secure coding practices documented and enforced
• Security testing integrated into the development process
• Change management controls for development environments

Organizations that already maintain a mature SDLC may find overlap with existing practices. Those that treat security as a pre-release gate rather than a development-phase discipline will need to restructure their approach.

Developer Configuration Management

SA includes a requirement that is easy to overlook but frequently cited in assessment findings: developer configuration management. Development environments, build tools, code repositories, and deployment pipelines must be subject to configuration controls. This means documented baselines for development infrastructure, change control for build and deployment tooling, and separation between development, test, and production environments.

The rationale is straightforward. If an attacker compromises a development environment, they can inject malicious code into systems that ultimately handle specified information. Developer configuration management closes that gap.

Supply Chain Protections at Acquisition

SA controls also address supply chain integrity at the point of acquisition. Organizations must verify that acquired systems and components have not been tampered with, that they come from authorized sources, and that they meet the security baseline defined in the acquisition requirements. This applies to hardware, software, and firmware.

For organizations acquiring commercial software, this typically means validating integrity through checksums, signed packages, or vendor attestations. For custom development, it means securing the delivery pipeline and verifying that what was delivered matches what was specified.

How This Differs from General TPRM

Organizations with existing third-party risk management programs often assume those programs will satisfy CPCSC's supply chain requirements. In some cases, that assumption is correct. In many, it is not.

General TPRM programs, the kind built around SOC 2 or ISO 27001 compliance, tend to focus on whether a vendor has adequate security controls for the data it handles. They evaluate the vendor's own posture. CPCSC's SR and SA controls go further in three ways.

Common Gaps

Across organizations preparing for CPCSC Level 2 certification, several supply chain gaps appear consistently.

Over-Scoped Vendor Assessments

This is a frequently over-scoped section in audit preparation. Not every vendor needs a full security assessment. Organizations that apply the same assessment rigor to every supplier, from their cloud infrastructure provider to their office coffee vendor, burn through resources without improving their security posture.

The solution is classification by data access. Suppliers should be categorized based on the type of information they handle: production data, development data, employee data, or no controlled data at all. Banks, open-source tools, and marketing utilities typically fall outside the scope of SCRM assessments under ITSP.10.171. This classification approach can significantly reduce assessment workload while actually improving focus on the suppliers that matter.

No Documented SCRM Plan

Many organizations perform vendor assessments without a governing plan. They have questionnaires and maybe a risk register, but no documented methodology that defines how suppliers are identified, categorized, assessed, monitored, and offboarded. Without the plan, individual assessments lack context and consistency, and assessors will look for the plan as a foundational artifact.

No Developer Configuration Management

Organizations with strong operational security practices sometimes leave development environments unmanaged. Build servers run on default configurations, code repositories lack access controls beyond basic authentication, and deployment pipelines have no change management. SA controls specifically require configuration management for development infrastructure, and the gap is visible in assessment evidence.

Missing Flow-Down Clauses

Prime contractors sometimes include generic security language in subcontracts without specifically requiring ITSP.10.171 compliance or defined security controls. When an assessor asks how the organization ensures subcontractor compliance, the contract must contain specific, enforceable, and verifiable security requirements that trace back to the standard.

No Supply Chain Incident Response

General incident response plans rarely cover supply chain scenarios. What happens when a subcontractor reports a breach? Who is notified, what evidence is preserved, and how is the impact on specified information assessed? SR controls expect these scenarios to be planned for, not improvised during an incident.

Building a Practical SCRM Program

Implementing SR and SA controls does not require building a vendor risk department. It requires a structured approach that scales with the supply chain's actual risk profile.

Step 1: Map Your Supply Chain

Before classifying or assessing anyone, identify every entity that touches specified information in your environment. This includes subcontractors, cloud providers, SaaS platforms, managed service providers, and development tool vendors. The goal is a complete picture of information flow, not just a list of contracts.

Step 2: Classify by Data Access

Assign each supplier to a tier based on their access to specified information:

This tiered approach focuses effort where risk exists and eliminates unnecessary work for suppliers outside the scope.

Step 3: Document the SCRM Plan

Write the plan before launching assessments. The plan should define:

• Scope and applicability criteria
• Tier definitions and classification methodology
• Assessment procedures for each tier
• Frequency of reassessment by tier
• Roles responsible for supply chain security decisions
• Escalation and remediation procedures
• Supply chain incident response procedures

The plan does not need to be long. It needs to be specific, documented, and followed consistently.

Step 4: Embed Security in Acquisition

Work with procurement to build security requirements into acquisition processes. For any system, service, or component that will handle specified information, security requirements derived from ITSP.10.171 should appear in the RFP, evaluation criteria, and contract terms. This closes the gap between security and procurement that SA controls are designed to address.

Step 5: Establish Developer Configuration Baselines

For organizations with internal development or contracted development teams, document configuration baselines for development infrastructure: repositories, build servers, CI/CD pipelines, test environments. Apply change management controls and ensure separation between development, test, and production environments. This satisfies SA's developer configuration management requirements and reduces the risk of supply chain compromise through the development pipeline.

Step 6: Monitor and Reassess

Build a reassessment cadence that matches your tier structure. Tier 1 suppliers warrant at least annual reassessment, with event-driven reviews if they report incidents or significant changes. Tier 2 suppliers can be reviewed on a longer cycle. Document every assessment, every finding, and every remediation action. The evidence trail is what demonstrates compliance during certification.

Frequently Asked Questions

Does CPCSC require my subcontractors to be certified?

SR and SA are Level 2 control families, not part of the expected Level 1 scope. At Level 2, subcontractors in scope may need their own certification, depending on the contract requirements and the nature of their access to controlled information. The prime contractor is responsible for ensuring that flow-down requirements are in place and that subcontractor compliance is verified.

How do SR and SA controls map to existing SOC 2 or ISO 27001 programs?

SOC 2's CC9 (Risk Mitigation) and ISO 27001's Annex A supplier relationship controls provide a starting point, but they do not fully satisfy ITSP.10.171's SR and SA requirements. The gap is primarily in the specificity of SCRM plan documentation, the requirement for acquisition-phase security integration, and the developer configuration management controls. Organizations with existing programs have a head start on vendor assessment methodology but will need to extend their documentation and scope to cover the full SR and SA families.

Do I need to assess every vendor?

No. ITSP.10.171's SR controls apply to suppliers who handle, access, or could impact specified information. Vendors providing general business services with no access to controlled data fall outside the scope. The key is a documented classification decision for every supplier, so assessors can verify that the scoping was deliberate and risk-based rather than arbitrary.

What evidence do assessors expect for supply chain controls?

Assessors will look for the SCRM plan as a foundational document, along with evidence that it is being followed. This includes supplier classification records, completed assessment questionnaires or attestation reports for in-scope suppliers, contractual flow-down clauses, evidence of reassessment, and records of any supply chain incidents and how they were handled. For SA controls, expect questions about how security requirements were incorporated into recent acquisitions and how development environments are configured and managed.

For a complete view of ITSP.10.171's 17 control families, see the full standard breakdown. For practical guidance on Level 1 self-assessment, start there. If your organization needs to build or formalize its supply chain risk management program, start a conversation.