Does SOC 2 Require Penetration Testing?

You can pass a SOC 2 audit and still lose an enterprise deal because you don’t have a recent penetration test report. And for startups selling to larger customers, compliance and buyer expectations don’t always line up.

SOC 2 does not universally require every organization to conduct penetration testing. What’s expected depends on the organization’s controls, risk assessment, and commitments. But passing an audit doesn’t automatically satisfy a customer’s security team. A prospective buyer may still ask for recent test results, evidence of vulnerability remediation, or independent validation that your application has been tested.

For startups with limited engineering resources, discovering a testing requirement late in the sales cycle can mean unexpected costs, delayed deals, and engineers pulled away from planned work. And understanding what SOC 2 actually requires, what your security risks warrant, and what enterprise customers expect helps you plan testing before it becomes a procurement blocker.

What SOC 2 Actually Requires From Your Security Program

SOC 2 does not prescribe one security program that every company must implement. Instead, it evaluates whether an organization has appropriate controls in place for the systems and services covered by its audit, based on the commitments it makes and the criteria that apply to its business.

And penetration testing can provide useful evidence that your team evaluates security risks and checks whether technical controls are working as intended. But the SOC 2 framework does not impose a blanket requirement for every company to conduct a penetration test. Whether testing is appropriate depends on your system, risk profile, control environment, and customer commitments.

The Trust Services Criteria Define the Scope

SOC 2 uses the AICPA’s Trust Services Criteria to assess an organization’s controls across five categories.

• Security: Whether systems are protected against unauthorized access, use, or modification. This is the common foundation of a SOC 2 examination.
• Availability: Whether systems are available for operation and use as committed or agreed.
• Processing Integrity: Whether system processing is complete, valid, accurate, timely, and authorized.
• Confidentiality: Whether information designated as confidential is protected as committed or agreed.
• Privacy: Whether personal information is collected, used, retained, disclosed, and disposed of in accordance with the organization’s privacy commitments and applicable requirements.

Security applies to every SOC 2 examination. The other categories are included when they are relevant to the organization’s services and commitments. A company does not automatically need to address all five.

The 33 Common Criteria Focus on Controls

Within the Security category, the 33 Common Criteria address how an organization manages security across areas such as risk assessment, monitoring, access controls, and system operations. Together, they provide a framework for evaluating whether the organization has appropriate controls to manage risks to its systems and information.

For example, penetration testing can help your team:

• Identify and validate vulnerabilities. Testing can reveal weaknesses in your application, APIs, authentication mechanisms, or access controls and establish whether they can be exploited.
• Assess technical risk. A validated finding can show how a weakness might affect customer data, application functionality, or access to sensitive systems.
• Evaluate security controls. Testing can expose gaps in controls designed to prevent unauthorized access or protect sensitive information.
• Support remediation and follow-up. A report provides evidence of identified issues, their severity, and the steps taken to address them. Retesting can help verify that fixes work.

The value of a penetration test is the evidence it produces about your security posture. That evidence may support relevant controls and help inform the auditor’s assessment, but it does not replace the broader set of controls your organization must implement.

Type I and Type II Reports Don't Change the Requirement

The type of SOC 2 report you pursue affects what the auditor evaluates and the period covered by the examination, but it does not automatically determine whether you need a penetration test.

	SOC 2 Type I	SOC 2 Type II
What it assesses	Whether controls are suitably designed at a specific point in time	Whether controls are suitably designed and operated effectively over a defined period
Evidence focus	Control design as of the examination date	Control design and evidence of operation throughout the examination period
Pentesting implication	Testing may support relevant controls, depending on the organization's approach	Testing may provide evidence of security evaluation, but does not automatically satisfy operating-effectiveness requirements

For either report type, determine the appropriate testing approach based on your risks, controls, and customer commitments.

What Auditors Actually Evaluate

A penetration test report is only one piece of evidence. It may identify serious weaknesses that still need to be addressed, and it cannot demonstrate that your company has implemented every applicable control.

For startup leaders, what you need to do next is to review the controls in scope with their auditor, understand what evidence is needed, and determine where penetration testing fits into the wider security program.

That covers the audit perspective. Enterprise customers may have additional requirements, including a recent penetration test and evidence that serious findings have been addressed. And meeting those expectations requires more than commissioning a test.

Why Enterprise Customers May Require a Pentest Anyway

A SOC 2 report can help your startup get through a security review, but it may not be enough to close an enterprise deal. Larger customers often have their own security policies, procurement requirements, and risk tolerances. If their process calls for an independent penetration test, your existing compliance report may not satisfy the requirement.

Enterprise Security Questionnaires Can Reveal the Gap

During procurement, a buyer may ask whether your company conducts penetration testing regularly, whether an independent provider performs the testing, and how your team tracks and resolves findings. These questions help the buyer understand how you evaluate the security of the product they intend to use.

For example, a customer may want to see that your application has been tested for exploitable weaknesses, that findings have assigned owners, and that serious issues have been addressed or retested.

This becomes especially relevant when your startup is selling a product that handles customer data, connects to internal systems, or becomes part of a customer's business operations. The buyer is assessing the risk of relying on your product, instead of just whether you've completed an audit.

Your SOC 2 Scope May Not Match the Buyer's Requirements

SOC 2 evaluates the controls covered by your examination. Enterprise customers can impose additional expectations through their procurement policies, security questionnaires, or contract terms. Those expectations may include a recent penetration test, a defined testing frequency, or evidence that identified vulnerabilities have been remediated.

That doesn't mean every request is mandatory or that you should automatically agree to every requirement. It means you need to distinguish between what your audit covers and what a particular customer requires before you commit to a deal.

Know What Evidence the Buyer Expects

Before scheduling a test or allocating a budget, ask the buyer what they will accept as proof. Requiring penetration testing can mean different things to different security teams. Common requests include:

• A penetration test report. The buyer may want to review the scope, testing date, findings, severity, and validation evidence.
• An attestation letter. Some buyers may accept a letter confirming that testing occurred, particularly when they cannot review the full report. Confirm who must issue it and what it needs to state.
• Remediation status. Buyers may ask which findings remain open, how serious they are, and whether fixes have been completed.
• Retesting evidence. A buyer may want confirmation that vulnerabilities have been retested after remediation, rather than relying solely on a statement that fixes were deployed.

These deliverables are not interchangeable. A report documents the test and its results; remediation records show how the company handled the findings; retesting provides evidence that specific fixes worked.

Before promising any of these, confirm what your testing provider can actually deliver. If a buyer requires a particular document or format, establish whether the provider can meet that requirement before committing to a deadline.

When Should You Schedule a Penetration Test?

The right timing depends on your sales pipeline, product changes, and contractual commitments. Several situations deserve particular attention.

• Before your first enterprise contract. Ask about testing requirements early enough to budget for the work and complete it before procurement becomes a blocker.
• Before a contract renewal. Check whether the customer expects updated testing evidence or proof that previously identified findings have been addressed.
• After material application changes. Significant changes to authentication, authorization, APIs, or other security-sensitive components may warrant additional testing.
• When a customer explicitly requires it. Confirm the required scope, acceptable testing methods, report age, and deadline before choosing a provider.

For a startup approaching its first enterprise deal, the practical move is to raise these questions during qualification or early procurement, and not when the contract is already waiting for security approval.

Ask the buyer what systems must be tested, how recent the results need to be, whether independent testing is mandatory, what evidence they expect, and whether unresolved findings will affect approval. Those answers give you a clearer basis for estimating cost, scheduling engineering support, and deciding whether your current testing arrangements are sufficient.

How to Turn Penetration Test Results Into Evidence of Follow-Through

A penetration test can help satisfy a buyer’s request for independent security testing, but the report may also reveal issues your team needs to address. For a startup with limited engineering capacity, each finding needs an owner, a risk-based priority, and a clear decision about what happens next.

Start With Validated Findings

An unverified scanner alert gives engineering a reason to investigate. A validated finding provides stronger evidence that a weakness exists and can be exploited under the conditions tested, that can help a small team decide which issues deserve immediate attention and which need further investigation.

Validation should establish what the vulnerability allows an attacker to do, how it affects the application, and what evidence supports the finding. When a report includes a reproducible proof of concept and clear technical details, engineers have a stronger basis for assessing the risk and planning a fix.

Validation does not eliminate the need for prioritization. A confirmed vulnerability still needs to be assessed in context, including its potential impact, exposure, and the sensitivity of the affected system or data.

Document Remediation Decisions

Every finding should have a status that reflects what the team has actually done with it. At a minimum, track:

• Ownership: Who is responsible for investigating or fixing the issue?
• Priority: How urgently does it need to be addressed, given its severity and potential impact?
• Remediation status: Is it open, in progress, fixed, or awaiting retesting?
• Risk acceptance: If the team decides not to fix it immediately, who approved that decision, why was it accepted, and when should it be reviewed?
• Outstanding work: What remains unresolved, and what is the next action?

An unresolved finding should never simply disappear from the report because the team ran out of time. If a fix must wait, document the rationale and the decision-maker. That gives the team a defensible record of how it manages risk, while making it easier to revisit the issue when circumstances change.

Retest Fixes and Preserve the Evidence

A developer marking a ticket as resolved does not independently establish that a vulnerability has been eliminated. Retesting helps verify whether the reported issue can still be reproduced after the fix.

When retesting is complete, preserve the result alongside the original finding and remediation record. If the vulnerability persists, document that outcome and return it to the appropriate remediation workflow. If the fix works, record the validation result and close the finding according to your team's process.

This creates a clearer history of what was discovered, what the team changed, and whether the change addressed the problem.

Build an Auditable Trail Without Creating More Work

Keep the original penetration test report, individual findings, remediation tickets, risk acceptance decisions, and retest results linked together. You want to be able to trace a finding from discovery through its final disposition without reconstructing the history from Slack messages and scattered spreadsheets. A useful record should let an auditor or enterprise security reviewer understand:

• What the test identified and how the finding was validated.
• How the team assessed and prioritized the risk.
• What remediation action was taken, or why the risk remains open.
• Whether the fix was retested and what the result showed.

This is where the quality of a penetration test matters beyond the initial report. Clear validation, actionable remediation guidance, and usable retesting evidence make it easier for engineering to act on findings and for the business to demonstrate follow-through.

Remediation evidence supports your SOC 2 security program, but it does not establish SOC 2 compliance on its own. Your company still needs to implement and demonstrate the other applicable controls.

The Work That Comes After a Penetration Test

A SOC 2 report can help your startup through a security review, but an enterprise buyer may still want recent penetration test results and evidence that serious findings have been addressed.

If you’re preparing for an enterprise security review, don’t wait until procurement is holding up the deal to find out what evidence the buyer expects. Confirm the required scope, report age, remediation evidence, and retesting expectations.

Backdoor helps teams identify and validate vulnerabilities, prioritize findings, and guide remediation. If an enterprise deal is waiting on security evidence, explore whether Backdoor fits your testing and follow-up needs.