Does SOC 2 Require Penetration Testing? What Startups Need to Know

Your startup has completed its SOC 2 audit. The report is ready, your team has invested time in documenting security controls, and you're one step closer to closing an enterprise deal.

Then the buyer's security team asks for a recent penetration test report.

Wasn't SOC 2 supposed to cover that?

Not exactly.

SOC 2 does not universally require penetration testing. But enterprise customers may still expect it, regardless of whether your company has successfully completed an audit.

For growing startups, understanding that distinction can prevent unexpected costs, procurement delays, and last-minute engineering work.

What Does SOC 2 Actually Require?

SOC 2 evaluates how an organization designs and operates controls relevant to its systems, services, and commitments.

It uses the American Institute of Certified Public Accountants' (AICPA) Trust Services Criteria, which cover five categories:

• Security: Protection against unauthorized access, use, or modification.
• Availability: Whether systems are available as committed or agreed.
• Processing Integrity: Whether processing is complete, valid, accurate, timely, and authorized.
• Confidentiality: Protection of information designated as confidential.
• Privacy: How personal information is collected, used, retained, disclosed, and disposed of.

Security is included in every SOC 2 examination. The other categories are included when relevant to the organization's services and commitments.

Within the Security category, the Common Criteria address areas such as risk assessment, monitoring, access controls, and system operations.

But these criteria don't establish penetration testing as a universal requirement for every organization.

A penetration test may provide valuable evidence that a company evaluates technical risks and the effectiveness of its security controls. Whether it is appropriate depends on the organization's risk profile, control environment, and commitments.

The important distinction: a penetration test can support your SOC 2 security program, but it doesn't establish SOC 2 compliance by itself.

Does SOC 2 Type II Change the Answer?

A common assumption is that SOC 2 Type II automatically requires regular penetration testing.

It doesn't.

The difference between Type I and Type II concerns what the auditor evaluates.

SOC 2 Type I assesses whether controls are suitably designed at a specific point in time.

SOC 2 Type II assesses whether controls are suitably designed and operate effectively over a defined period.

Penetration testing may provide relevant supporting evidence in either case, depending on the controls and risks involved.

However, choosing Type II doesn't automatically create a universal requirement to perform penetration testing on a fixed schedule.

Your testing approach should reflect the risks, controls, and commitments within the scope of your examination.

Why Might an Enterprise Customer Still Ask for a Pentest?

Because passing an audit and meeting a buyer's security requirements are two different things.

Enterprise customers often have their own procurement policies, security questionnaires, and contractual expectations.

A SOC 2 report can help demonstrate that your company has implemented relevant security controls.

But a prospective customer may want more specific evidence about the application they intend to use.

For example, their security team might ask:

• Has the application undergone a recent penetration test?
• Was the testing performed by an independent provider?
• Which systems and components were included?
• Were exploitable vulnerabilities identified?
• What happened to the findings after testing?
• Have important fixes been verified?

These questions help the buyer evaluate the risks associated with using your product.

They may be particularly relevant when your application processes customer data, connects to internal systems, or supports critical business operations.

Your SOC 2 report and your customer's security requirements may overlap, but they are not interchangeable.

What Evidence Should Your Startup Be Ready to Provide?

Before scheduling a penetration test, clarify what the buyer actually expects.

Different security teams may request different forms of evidence.

A penetration test report

A report can document the assessment's scope, date, methodology, findings, severity ratings, and available validation evidence.

It helps the buyer understand what was tested and which security issues were identified.

An attestation letter

Some buyers may accept a letter confirming that penetration testing occurred, particularly when the full report cannot be shared.

However, acceptance depends on the buyer's requirements, including who must issue the letter and what information it must contain.

Remediation records

A customer may want to understand how your company handles identified vulnerabilities.

That can include assigned owners, remediation priorities, outstanding findings, and documented risk acceptance decisions.

Retesting evidence

A deployed fix doesn't automatically prove that a vulnerability has been eliminated.

Retesting can provide evidence that a specific finding has been addressed under the relevant conditions.

These documents serve different purposes. Before committing to deliver any of them, confirm what your testing provider can actually supply and what your customer will accept.

When Should a Startup Schedule Penetration Testing?

Waiting until a contract is nearly signed can create unnecessary pressure.

A prospective customer might request testing evidence when your engineers are already focused on a major release or another business-critical deadline.

Instead, consider penetration testing requirements at several important stages.

Before your first enterprise deal

Ask about security requirements early in the sales process. Determine whether the buyer expects independent testing, how recent the results must be, and which systems need to be included.

Before a contract renewal

Check whether the customer expects updated evidence or confirmation that previously identified vulnerabilities have been addressed.

After significant application changes

New authentication flows, major API changes, additional integrations, or newly exposed services may justify further testing.

When a customer explicitly requests it

Clarify the required scope, methodology, documentation, and deadline before selecting a testing provider.

The goal isn't to perform more tests than necessary.

It's to understand when testing is appropriate and avoid discovering a requirement too late.

A Pentest Report Is Only Part of the Evidence

Imagine your startup completes a penetration test and receives a report identifying several vulnerabilities.

You now have evidence that testing occurred.

But what happens next?

For an enterprise security reviewer, the answer may be just as important as the original report.

A useful remediation process should establish:

1. Which findings are supported by evidence

A validated vulnerability provides stronger information for assessing technical risk than an unverified scanner alert.

2. Which issues deserve priority

Severity matters, but exploitability, exposure, potential impact, and business context also influence remediation decisions.

3. Who is responsible for each finding

Every issue should have an accountable owner and a defined next step.

4. What action was taken

Document whether a vulnerability was fixed, remains under investigation, or has been deferred through an explicit risk acceptance decision.

5. Whether the fix worked

Where appropriate, retesting helps establish whether the original vulnerability can still be exploited.

Together, these records help explain what your company discovered, how it responded, and what risks remain.

That evidence may support your broader security program and help answer enterprise customer questions.

It does not, on its own, establish SOC 2 compliance.

Compliance Is Not the Finish Line

For startups, SOC 2 is often an important milestone in building trust with larger customers.

But completing an audit doesn't eliminate technical vulnerabilities, replace ongoing risk assessment, or guarantee that every buyer will accept your existing security evidence.

The more useful approach is to connect compliance efforts with practical security work.

Understand your risks. Evaluate the controls that protect your systems. Test where appropriate. Investigate findings. Track remediation decisions. Verify fixes when necessary.

And, importantly, keep evidence of what your team has done.

At BackDoor, we believe security testing should give startups actionable information about their applications and help engineering teams make informed decisions about vulnerabilities.

Because when an enterprise customer asks how you manage security, the strongest answer isn't simply that you've completed an audit.

It's being able to explain what you've tested, what you've found, and what you've done about it.