SOC 2 Penetration Testing in Canada: What Auditors Expect

SOC 2 doesn’t explicitly require penetration testing, and it sets no universal testing frequency. For organizations weighing SOC 2 penetration testing requirements in Canada, annual testing is common, but the right timing depends on the audit period and changes to the systems in scope. For a Type II audit, test evidence needs to fall within the observation period to count as relevant evidence.

It’s understandable to want a clear rule before planning an assessment. The standard leaves room for organizations to demonstrate that security controls are evaluated and working, so a test’s scope, timing and documented follow-up matter more than simply having a report on file.

This article explains what a useful penetration-test report should contain, how testing can support the Trust Services Criteria, and what auditors may look for in remediation evidence. You’ll also see how Type I and Type II timelines affect test evidence, and when a penetration test can provide practical insight beyond a compliance exercise.

What does a SOC 2 penetration test report need to include?

A useful report connects the penetration test to the systems and controls included in the SOC 2 examination. Annual testing is common, but scope, timing, findings, and remediation evidence determine how relevant the report is to an audit.

Test Scope and System Boundaries

Test scope identifies the assets and boundaries examined, while the SOC 2 system boundary defines the services and systems covered by the examination. Aligning them helps show which audited assets were tested and where coverage stops. For example, a SaaS organization might include its web application, API, and supporting network, while excluding unrelated corporate tools, such as an AI receptionist like Oscar used for handling inbound business calls.

Make the report specific about the tested environment. It should identify the applications, network components, and other in-scope assets, along with any exclusions or testing limitations. If a new API handles customer data but sits outside the test scope, the report should make that gap visible. Clear boundaries let the auditor compare test coverage with the SOC 2 system description.

There is no universal SOC 2 penetration-testing frequency. Annual testing is common, and customers often expect a report issued within the past 12 months. For Type II, evidence needs to fall within the audit observation period. A Type I assessment may use a test performed around the audit date; Type II timing should reflect the period under review.

Auditor Expectations for Test Evidence

Auditor evidence includes the report and supporting records showing what the test examined, when it occurred, and what the testers found. A report detached from the audited system or observation period may not demonstrate relevant control evaluation. Include the test dates, scope, methodology, limitations, and a clear account of findings and affected assets.

Named methodologies such as OWASP, PTES, and NIST SP 800-115 can help explain the testing approach. The report should also distinguish validated vulnerabilities from observations that could not be confirmed. For each finding, connect the affected asset to its security impact and provide evidence that supports the conclusion.

• Record the testing dates and the environment examined.

• Describe the methodology, access assumptions, and exclusions.

• Document each finding, affected asset, and supporting evidence.

• Track remediation status and any retest results.

For combined SOC 2 and ISO 27001 engagements, map shared assets and findings to each framework’s scope. This keeps evidence traceable across both examinations. The ISO 27001 penetration testing requirements also highlight why the testing scope should connect to the controls being assessed.

Which Trust Services Criteria Can Penetration Testing Support?

The AICPA Trust Services Criteria provide the basis for SOC 2 examinations; penetration testing can support evidence that controls are evaluated, but no specific test is prescribed. SOC 2 is not itself a Canadian statute, so Canadian legal and sector obligations remain separate considerations for an organization.

Trust Services Criteria and Testing

The Trust Services Criteria describe control expectations across security, availability, processing integrity, confidentiality, and privacy. Penetration testing can help an organization evaluate security controls by attempting to exploit weaknesses in systems within the examination scope. Test results can show how controls perform against realistic attack paths, rather than merely confirming that policies or configurations exist.

The cited AICPA criteria are the 2017 Trust Services Criteria, revised in 2022. CC4.1 addresses ongoing or separate evaluations of internal controls. A penetration test can contribute evidence to that evaluation, but it does not prove that every control operates effectively. CC7.1 may also be relevant when an organization connects test findings to its security risk monitoring and response activities.

What penetration testing does SOC 2 Trust Services Criteria expect? They don’t prescribe a particular penetration-testing method or require a specific test. Testing is one way to support evaluation of security controls; its value depends on whether the scope and results relate to the controls under examination.

Supporting Evidence for Criteria

Supporting evidence links a test result to a specific control evaluation and the system examined. A report alone cannot establish that every applicable control works as intended. For example, a finding involving access to sensitive data can help an organization assess whether related security controls are effective and whether its response process addresses the exposure.

For CC4.1, evidence can include the test scope, results, and records showing how the organization evaluated findings. For CC7.1, connect relevant findings with the organization’s monitoring and response process, without treating a penetration test as a substitute for ongoing monitoring. The report should identify tested assets, limitations, and findings clearly enough to trace each result to the applicable control discussion.

The criteria also cover availability, processing integrity, confidentiality, and privacy. Test findings can inform those areas when they directly affect them. For instance, an exploitable weakness that threatens service access may be relevant to availability; a flaw exposing customer information may inform confidentiality or privacy. The evidence should explain the connection rather than assume it.

• Map each finding to the affected system and relevant control.

• Preserve evidence of evaluation, response, and remediation decisions.

• Distinguish test results from broader monitoring and control activities.

Canadian law does not create a separate SOC 2 testing rule. Organizations still need to consider applicable Canadian obligations based on their operations, sector, and data. To discuss how a scoped test can support control evidence, connect with the security team.

Auditor expectations for reports and remediation evidence

Auditors assess penetration-test evidence against the SOC 2 examination’s purpose and period. A Type I assessment evaluates whether controls were designed and implemented as of a specific date. A Type II examination requires evidence that applicable controls operated effectively over time. The distinction determines whether a test result supports a point-in-time assessment or contributes to evidence across an observation period.

For a Type II examination, connect the test date and affected systems to the audit period. A report from outside that period may provide security insight, but it may not support evidence of control operation during the period being examined. Auditors also consider whether the tested environment reflects the systems and services in the SOC 2 scope. A report that excludes a key production web application leaves a gap in coverage.

Auditors may examine the testing process, not just the final summary. Useful supporting records include the agreed scope, test dates, methodology, limitations, and evidence of how findings were evaluated. A finding involving a customer-data API, for example, should identify the affected component and explain the observed risk. Internal notes can show how the organization assessed that risk and chose an action.

Alternative control evaluations need a clear connection to the control objective. Vulnerability scanning, code reviews, red-team exercises, and dynamic application security testing can provide other forms of security evidence, but they are not interchangeable by default. A scan can identify a suspected weakness, while a penetration test attempts to validate exploitability. Explain what the selected evaluation examines and how its results inform the control assessment.

Remediation records show auditors what happened after a finding was discovered. For each finding, retain its severity, affected asset, assigned owner, response decision, and status. If the organization accepts a risk or defers a fix, document the rationale and any compensating action. If a fix is applied, a retest can show whether the original issue remains exploitable. This creates a traceable path from finding to action.

• Match the test dates and systems to the Type I date or Type II observation period.

• Preserve scope, methodology, limitations, findings, and supporting records.

• Link each finding to its risk assessment, remediation decision, and current status.

• Record retest results when a remediation changes the tested weakness.

An independent third-party penetration test is generally stronger SOC 2 evidence than internal testing, but the report still needs relevant scope and clear findings. For example, a test of a staging environment is more useful when that environment closely mirrors production. Auditors can then assess how closely the results represent the systems and controls under examination, rather than treating a report’s existence as proof of effectiveness.

Does SOC 2 Require Penetration Testing Explicitly?

No. SOC 2 doesn’t explicitly name penetration testing as a hard requirement, and it doesn’t explicitly require vulnerability scanning. The organization must still evaluate security controls and support its examination with relevant evidence.

Explicit Testing Requirements

An explicit testing requirement would name a specific activity that every organization must perform. SOC 2 does not prescribe penetration testing or vulnerability scanning as universal steps. That distinction matters: the organization can select security evaluations that fit its systems and control objectives, then show how those evaluations support its control assessment.

Vulnerability scanning and penetration testing provide different evidence. Scanning can identify known or suspected weaknesses across applications and infrastructure. A penetration test investigates whether weaknesses can be exploited in context, including how an attack might affect systems or data. A scan result is useful, but does not by itself demonstrate exploitability.

How do SOC 2 penetration testing requirements compare with ISO 27001 and PCI DSS? SOC 2 does not explicitly require either penetration testing or vulnerability scanning. A properly scoped penetration test can address PCI DSS Requirement 11.3 alongside SOC 2 and ISO 27001, but that does not make the frameworks’ requirements interchangeable.

For an organization working across frameworks, start with the control or requirement being assessed. Then connect the test scope and results to that objective. A test of a customer-facing web application may inform relevant security evidence, while a scan of unrelated infrastructure may not answer the same control question. Framework alignment depends on scope and evidence, not just the test label.

Identification and Exploitation

Vulnerability identification detects or analyses a weakness; exploitation validates whether it can be used to affect a target. This difference matters because a list of potential issues does not show the practical consequences of an attack. NIST SP 800-115 distinguishes vulnerability-identification and analysis techniques, including scanning, from techniques that validate exploitability.

For example, a scanner might flag an outdated application component. A penetration test can examine whether an attacker can use that weakness to access restricted data or move into another system. The result adds context: affected assets, attack path, and demonstrated impact. Testing must stay within its agreed scope and authorized boundaries.

Neither activity replaces the other. Scanning can provide broad, repeatable visibility into potential vulnerabilities; penetration testing can probe selected weaknesses and reveal how they interact. An organization may use both as part of its security evaluation, but SOC 2 does not prescribe either one by name.

Choose an evaluation based on the question it must answer. If the goal is to find likely weaknesses across infrastructure, scanning may help. If the goal is to determine whether a weakness can be exploited in an in-scope application, penetration testing provides different evidence. A scoped assessment can help clarify which evidence best fits the control objective. Discuss a suitable testing scope.

Penetration testing findings and remediation

A penetration-test finding matters when the organization assesses its security impact and acts on it. A clear remediation program turns test results into tracked risk decisions, fixes, and validation evidence.

Findings and Gap Assessment

A gap assessment compares identified weaknesses with the organization’s security controls and risk-management practices. It helps distinguish a technical finding from a broader control gap. For example, an exploitable access-control flaw may point to an application defect and a need to review how access risks are assessed.

CVSS scores findings on a scale from 0 to 10, but a score alone doesn’t determine business impact. The assessment should consider the affected asset, exposure, data involved, and whether an attacker can exploit the weakness. An external vulnerability in a customer-facing web application may deserve different treatment from a lower-impact issue on isolated internal infrastructure.

Use each finding to define an owner, a risk decision, and an action. This makes the gap assessment useful to a security program, rather than just another report. Remediation pricing depends on the case and is given after a quote request; scope, system complexity, and the work needed to address findings affect the estimate.

Remediation and Retesting

Remediation removes or reduces a vulnerability, while retesting checks whether the change works. Both steps matter because closing a ticket does not validate that an attacker can no longer exploit the original weakness. For example, after correcting an authorization flaw, testing should confirm that restricted users cannot access the protected function.

Set remediation priorities using severity and impact. Suggested timelines include addressing critical and high-severity findings within 7 to 14 days; another recommendation places high-severity remediation within 30 to 90 days. These are operational targets, not universal SOC 2 deadlines. Record the rationale when dependencies or risk decisions affect the schedule.

For each finding, maintain a record connecting the initial evidence to the final outcome. Include the affected system, severity, owner, remediation action, target or completion date, and validation result. If the organization accepts a risk instead of fixing it, document why and describe any compensating action. That record helps demonstrate a deliberate response.

• Prioritize critical and high findings according to risk and exposure.

• Track owners, actions, status, and the reason for any delay.

• Retest fixes and preserve evidence showing whether the issue remains exploitable.

• Carry unresolved findings into the risk assessment and remediation plan.

A retest can confirm a specific fix; it doesn’t replace ongoing vulnerability management. Discuss penetration-test findings and remediation to plan testing and validation around your environment.

AppSecure Security

AppSecure Security helps organizations assess in-scope applications and APIs through targeted penetration testing. Turn to the team when you need to investigate exploitable weaknesses, clarify test boundaries, or produce findings that inform security decisions and remediation planning.

Testing can focus on a web application, mobile application, or API, with scope shaped around the systems relevant to your SOC 2 examination. AppSecure Security also offers an Agentic Penetration Testing Platform. The assessment’s purpose is to uncover security issues and provide useful technical findings, not to promise a particular audit outcome.

Contact AppSecure Security to discuss your SOC 2 testing needs and the systems you want assessed.

Turn Testing into a Stronger Security Roadmap

Use the next assessment to make deliberate security decisions, not just close an audit task. Identify which customer-facing workflows matter most, who owns each system, and how security issues move from discovery to an approved action. This creates a practical connection between technical testing and the people responsible for managing risk.

Planning for SOC 2 penetration testing requirements in Canada also gives teams a chance to align security priorities with product changes. A new feature, API, or authentication flow can shift the risks under review. Build a clear process for deciding when those changes warrant fresh testing, and keep the rationale visible to technical and business stakeholders.

AppSecure Security can help assess your environment and uncover technical weaknesses relevant to your systems. Contact AppSecure Security to discuss your testing needs.

A focused next step can turn security findings into lasting progress.

Frequently Asked Questions

How Frequently Should Testing Be Performed for SOC 2?

Annual testing is common, but SOC 2 sets no universal penetration-testing frequency. For organizations planning SOC 2 penetration testing requirements in Canada, test timing should align with the audit period. Type II evidence needs to fall within the observation period; for a 12-month audit, complete at least one test within that period. Additional testing after significant system changes can help keep evidence relevant to the environment.

How to Choose a SOC 2 Pen Testing Provider?

Choose a provider whose testing can produce technically supported evidence for the systems in scope. Independent third-party testing is usually stronger SOC 2 evidence than internal testing. Look for a report that identifies methodology, limitations, affected assets, and validated findings. Recognized approaches include OWASP, PTES, and NIST SP 800-115. For a small-to-medium scope, testing lasting less than 40 hours may not provide sufficient scrutiny.

Should An External Penetration Test Be Performed?

An external penetration test is useful when internet-facing systems, such as a customer login or public API, fall within the SOC 2 system boundary. It examines exposure from an outside attacker’s perspective, but it isn’t the only suitable approach. Organizations may also choose white-box internal testing. The right perspective depends on which risks and systems are included in the examination and what the assessment needs to validate.

What Should a SOC 2 Penetration Testing Report Contain?

A report should make its conclusions traceable to the systems and activities tested. It should distinguish confirmed vulnerabilities from observations that were not validated and identify excluded assets. For example, if a production API was unavailable during testing, state that limitation rather than implying successful coverage. Supporting records should explain the test date, methodology, and results so reviewers can understand the evidence and its relevance.

Black Box, White Box, or Grey Box for SOC 2?

Choose the testing model that best examines the risks in scope. Black-box testing uses limited internal knowledge, while white-box testing provides deeper access or information. Grey-box testing combines an external perspective with some access, such as credentials. That access can help assess whether a user can reach functions or data beyond their authorization, making the approach useful when the test needs to examine realistic account-level attack paths.

Does SOC 2 require penetration testing?

No. SOC 2 doesn’t explicitly require penetration testing or vulnerability scanning. Organizations can use different security evaluations to support their control assessments. The practical question is whether the selected evidence addresses risks within the examination scope. A scan may identify a suspected weakness; a penetration test can investigate whether an attacker could exploit it in the organization’s environment. These activities provide distinct forms of security evidence.

How often should a company perform penetration testing for SOC 2?

Annual testing is common, not a universal SOC 2 rule. In Canada, SOC 2 penetration testing requirements should be planned around the examination’s observation period, especially for Type II. An organization may also schedule additional testing after substantial application, authentication, or infrastructure changes. These event-driven assessments help determine whether earlier findings and conclusions still reflect the current environment and its attack surface.

What systems and environments should a SOC 2 penetration test cover?

Test systems that support services and controls included in the SOC 2 examination. Depending on the organization, scope may include a web application, API, network, or client-side system that processes sensitive customer data. For example, in consumer safety and monitoring platforms such as The Wellbeing App, mobile endpoints and tracking infrastructure represent critical components to evaluate. Staging can be used when it closely mirrors production, but differences in access controls, integrations, or configuration can affect how relevant the results are. Include material systems and document meaningful scope boundaries.