From SOC 2 to CPCSC: Extending Your Security Program for Defence Contracts

The question comes up consistently when companies with established security programs look at entering the Canadian defence supply chain: Do we need to build a completely new security program for CPCSC?

The short answer is no. A SOC 2 Type II certification means an organization has already invested in designing, implementing, and evidencing a security program across the Trust Services Criteria. That investment translates directly into a meaningful portion of what ITSP.10.171 requires. The overlap is structural, not coincidental, because both frameworks draw from common security principles and, in several areas, from the same NIST lineage that underpins NIST SP 800-171.

The goal is to identify exactly where the existing program carries forward, where it needs deepening, and where entirely new controls are required. This is the approach that produces the best outcomes: treat the existing security program as a foundation, identify what CPCSC adds to the requirements, and extend rather than rebuild. Organizations that take this path consistently reach certification faster and with a program they actually understand and can operate, rather than ending up with a second set of policies that exist independently from the controls they already run.

The Overlap Map: SOC 2 TSC to ITSP.10.171

The following table maps the SOC 2 Common Criteria to the relevant ITSP.10.171 control families. The overlap column reflects how directly the SOC 2 criteria translate to CPCSC requirements when a real, operational program backs them, not just policy documents with a company name swapped in.

The pattern that emerges: a meaningful portion of what ITSP.10.171 requires has a direct analog in a well-operated SOC 2 program, while the remainder ranges from controls that need deepening (moderate overlap) to entirely new control families (gaps). The overlap is strongest in the families expected at Level 1 (AC, IA, PE, SC, SI, MP), where SOC 2 CC6 and CC7 provide a solid foundation.

Where SOC 2 Gives You a Head Start

Access Control and Identity (CC6 to AC, IA, PE)

This is the strongest overlap area. SOC 2 CC6 requires logical access controls, authentication mechanisms, physical access restrictions, and regular access reviews. Organizations with a mature SOC 2 program will already have RBAC, MFA on privileged and remote access, documented access provisioning and deprovisioning procedures, and periodic access reviews.

The ITSP.10.171 Access Control and Identification & Authentication families require the same foundational capabilities. The adjustment is typically in documentation depth, specifically around information flow enforcement and session management specifics, rather than in building new technical controls.

Monitoring, Logging, and Incident Response (CC7 to AU, IR, SI)

SOC 2 CC7 addresses system monitoring, anomaly detection, and incident management. Organizations maintaining SOC 2 Type II typically have centralized logging, defined incident response procedures, vulnerability management programs, and evidence of operational execution.

The ITSP.10.171 Audit and Accountability and Incident Response families expect similar capabilities. The deepening required tends to be around audit record content (what specifically gets logged), audit review frequency, and incident reporting timelines specific to defence contracts.

Change Management (CC8 to CM, MA)

SOC 2 CC8 requires documented change management processes with approvals, testing, and rollback procedures. The ITSP.10.171 Configuration Management family requires formal configuration baselines, least functionality enforcement, and controlled maintenance.

The overlap here is moderate rather than strong. SOC 2 change management tends to focus on the process of approving and deploying changes. ITSP.10.171 adds requirements for documenting baseline configurations, restricting unnecessary services and ports, and maintaining a system component inventory that goes beyond what a typical SOC 2 program tracks.

Risk Assessment (CC3 to RA)

SOC 2 CC3 requires a risk assessment process that identifies threats and vulnerabilities, assesses likelihood and impact, and produces a risk response. The ITSP.10.171 Risk Assessment family expects the same, with additional emphasis on vulnerability scanning at defined intervals and risk response documentation.

Organizations with a mature SOC 2 risk assessment methodology can typically extend it to cover the CPCSC scope without fundamental redesign. The key addition is ensuring the risk assessment explicitly addresses the defence supply chain context and the specific information types in scope.

The Gap Areas: What SOC 2 Does Not Cover

The critical gaps are not areas where SOC 2 is weak. They are areas where SOC 2 was simply not designed to go. These control families exist in ITSP.10.171 because defence supply chain security has requirements that commercial SaaS trust frameworks do not address.

Supply Chain Risk Management (SR) and Acquisition Controls (SA)

SOC 2 CC9 includes vendor risk management, but at a level designed for commercial service organizations evaluating their SaaS dependencies. The ITSP.10.171 Supply Chain Risk Management family requires a formal supply chain risk management plan, supplier assessments that address the flow of controlled information through the supply chain, and controls over externally provided system components and services.

For primes managing subcontractors, this extends to ensuring that downstream suppliers meet equivalent protection standards. This is an entirely new discipline for organizations coming from a commercial SOC 2 context.

Personnel Security (PS)

SOC 2 addresses personnel-related controls primarily through the control environment (CC1), covering background checks, onboarding, and role assignments. ITSP.10.171 Personnel Security requires personnel screening at a depth that reflects defence supply chain requirements, including controls over personnel termination and transfer that go beyond standard commercial offboarding procedures.

Organizations accustomed to standard commercial background checks will need to assess whether their screening processes satisfy the ITSP.10.171 assessment objectives, particularly for personnel with access to specified information.

Media Protection (MP)

SOC 2 does not have a dedicated media protection criteria. ITSP.10.171 Media Protection requires controls over media storage, transport, sanitization, and handling of system media containing controlled information. This includes procedures for marking media, limiting access to media based on information classification, and sanitization methods that meet defined standards before disposal or reuse.

For organizations that operate entirely in the cloud and rarely handle physical media, this still matters. The control family extends to digital media and requires documented procedures for how information is stored, transmitted, and destroyed across all media types.

System and Communications Protection (SC)

While SOC 2 CC6 covers encryption in transit and at rest, the ITSP.10.171 System and Communications Protection family requires cryptographic protection that meets specific validation standards, boundary protection between network segments, and controls over collaborative computing devices and public-access systems. The cryptographic validation depth required, particularly around FIPS-validated modules for specified information, goes beyond standard commercial encryption practices.

System Security Plan (PL)

SOC 2 does not require a System Security Plan in the structured format that ITSP.10.171 expects. The Planning family requires a documented SSP that describes the system boundary, the authorization to operate, interconnections with other systems, and the implementation status of every applicable control. This is a significant documentation effort even for organizations with well-documented SOC 2 programs, because the SSP format and content expectations are specific to the defence certification context.

How to Extend Rather Than Rebuild

The organizations that extend efficiently share a common characteristic: they have a real, operational security program behind their SOC 2 certificate, not a set of policy templates with their company name swapped in.

The distinction matters because extending a program requires understanding what actually runs, how evidence is produced, and where controls operate versus where they are documented but not enforced. When an organization has policies that were written to pass an audit but do not reflect actual operations, the extension exercise quickly becomes a rebuild exercise, because there is no real foundation to build on.

For organizations with an operational program, the extension methodology is straightforward:

Step 1: Scope the delta. Map current SOC 2 controls to ITSP.10.171 requirements at the assessment objective level. The table above provides the family-level mapping, but the actual work happens at the individual control and assessment objective level. This produces a clear picture of what carries forward, what needs deepening, and what is entirely new.

Step 2: Prioritize the gaps. Not all gaps carry equal weight. Start with the control families that are entirely new (SR, PS, MP, SC depth, PL) rather than deepening existing controls. New control families require design, implementation, and evidence cycles. Deepening existing controls typically requires documentation and process adjustments.

Step 3: Build the evidence layer. This is where organizations with strong security architecture sometimes stumble. Teams that built excellent technical controls but never documented the reasoning or produced evidence of ongoing operation face a specific challenge: the controls work, but the evidence layer that an assessor needs does not exist. Building the evidence layer for existing controls is faster than building new controls, but it is real work that should not be underestimated.

Step 4: Write the SSP. The System Security Plan is the single largest documentation deliverable for CPCSC that SOC 2 programs do not produce. It documents the complete system boundary, authorization, interconnections, and control implementation status. Starting this early, even as a living draft that evolves as controls are implemented, prevents a documentation crunch before self-assessment submission.

Step 5: Validate through self-assessment. For CPCSC Level 1, the self-assessment against the applicable controls is where the entire program comes together. Organizations that extended from SOC 2 should validate that the evidence produced for the new and deepened controls meets the ITSP.10.171 assessment objectives, not just the SOC 2 criteria they were originally designed for.

Implementation Timeline for SOC 2 Certified Companies

Timeline estimates assume an organization with a current SOC 2 Type II report and an operational security program behind it. Organizations with a Type I report or a program that exists primarily on paper should add 4-8 weeks.

The 12-16 week estimate assumes dedicated resources. Organizations relying on existing team members who are also running the SOC 2 program, building product, and managing infrastructure should expect the longer end of the range. This is the bandwidth problem that a fractional security team is designed to solve: bringing the CPCSC-specific expertise and capacity without requiring the organization to hire a full-time compliance team for a finite implementation project.

FAQ

Does a SOC 2 Type II report satisfy any CPCSC requirements directly?

No. CPCSC does not recognize SOC 2 as a reciprocal certification. There is no mutual recognition arrangement between the two frameworks. However, the controls, processes, and evidence that an organization maintains for SOC 2 translate directly into satisfying many ITSP.10.171 requirements. The work carries over, even though the certificate does not.

What is the biggest gap area for SOC 2 certified companies entering CPCSC?

The System Security Plan (SSP) is typically the single largest new deliverable. SOC 2 programs produce a system description, but the SSP required by ITSP.10.171 is a different document in structure, depth, and purpose. Beyond the SSP, supply chain risk management is the most operationally significant gap, because it requires new processes, new supplier engagement, and new evidence that most commercial programs have not built.

Can we maintain both SOC 2 and CPCSC with a single security program?

Yes, and this is the recommended approach. Organizations that build a single, effective security program and map multiple frameworks onto it operate more efficiently than organizations that maintain parallel programs for each certification. The overlap between SOC 2 and CPCSC is substantial enough that a unified program with framework-specific evidence mappings is both feasible and significantly less expensive to operate than two independent programs.

Should we pause SOC 2 to focus on CPCSC?

In most cases, no. SOC 2 certification serves the commercial side of the business, and CPCSC serves the defence supply chain side. The operational controls are largely the same. The extension approach described in this guide is designed specifically to avoid the false choice between frameworks. The incremental effort to add CPCSC on top of a running SOC 2 program is materially less than building either program from scratch.

Extending a SOC 2 program for CPCSC is a scoping exercise, a gap remediation project, and a documentation effort. It is not a program redesign. Organizations that approach it this way reach certification faster, with a program that makes operational sense because it was built on controls they were already running.

The alternative, treating CPCSC as a separate compliance initiative disconnected from the existing program, produces exactly the kind of paper compliance that fails at the first real test. Whether that test is a Level 2 assessment, a supply chain security incident, or a prime contractor's due diligence questionnaire, the organizations with a unified, operational program are the ones that pass.

If your organization has a SOC 2 program and is evaluating defence supply chain opportunities, a gap analysis against ITSP.10.171 is the practical first step. It quantifies the delta, prioritizes the work, and produces a realistic timeline for certification.