VAPT for SOC 2 and ISO 27001 (2026)

Almost every VAPT engagement we see is triggered by a compliance deadline. A SOC 2 Type II window is opening, an ISO 27001 certification audit is booked, or an enterprise customer's security review has stalled a contract. The question is never "should we test" — it is "what will the auditor actually accept, and when do we need to start?"

This guide answers both. It covers what each framework genuinely requires versus what vendors imply it requires, what evidence satisfies an auditor, how to time the engagement against your audit date, and the mistakes that cause a test to be redone.

What Each Framework Actually Requires

The first thing worth knowing is that none of these frameworks contains a line saying "you must run a penetration test annually." The requirement is more indirect than that, and the difference decides your scope.

SOC 2

SOC 2 is not a checklist. It is an attestation against the Trust Services Criteria, and your auditor assesses whether the controls you defined are designed appropriately and operating effectively. Nothing in the criteria mandates a penetration test by name.

In practice, testing is almost always part of the answer. The criteria around risk assessment and monitoring of controls are difficult to satisfy convincingly without some form of technical validation, and most auditors expect to see it. Where teams go wrong is assuming a scan report satisfies this. If your control description says "annual penetration testing by a qualified third party", the auditor will hold you to that wording — and a scanner output does not demonstrate it.

The Type II distinction matters enormously. Type I assesses design at a point in time. Type II assesses operating effectiveness across a window, typically three to twelve months. If your stated control is annual testing, the test must have happened within the window and you must be able to prove it.

ISO 27001

ISO 27001 works differently. The management system requirements are mandatory; the Annex A controls are selected based on your risk assessment and documented in a Statement of Applicability.

Technical vulnerability management sits in Annex A, and it is very rare for an organisation to justify excluding it. The certification cycle runs three years with surveillance audits in between, which means testing evidence needs to persist and stay current across that whole period rather than being produced once.

Because scope is risk-driven, the auditor will ask why you tested what you tested. A scope that conveniently excludes your most complex system will attract questions.

PCI-DSS

PCI-DSS is the outlier, and the most prescriptive. It explicitly requires penetration testing — internal and external — along with segmentation testing where segmentation is used to reduce scope. It also specifies the methodology and requires that findings be remediated and the testing repeated to verify.

If you handle cardholder data, this is the framework that sets your floor. Scope it first and the others usually fall inside it.

What Auditors Actually Accept

Across all three frameworks, the artefact that closes the loop is the same: evidence that findings were remediated, not merely that testing occurred.

A report full of open critical findings demonstrates that you tested. It does not demonstrate that your controls operate effectively — arguably it demonstrates the opposite. The document auditors want is the retest report confirming closure.

What a well-prepared evidence package contains:

The engagement letter or scope document — what was tested, when, by whom, and the methodology followed
The technical report — findings with severity ratings, evidence and reproduction steps
Remediation records — tickets, commits or change records showing what was fixed and when
The retest report — independent confirmation that findings are closed
Tester credentials — auditors increasingly ask who performed the work and what qualifies them

That last item catches people out. "A qualified third party" is doing real work in most control descriptions. Be ready to evidence what qualified them.

Timing: Work Backwards From the Audit Date

The most common failure in compliance-driven testing is not scope. It is timing.

Hand-drawn diagram showing how to work backwards from an audit date through retest, fix window and test start

Work backwards. If the auditor needs evidence on a given date, the retest must be complete before it. The retest cannot happen until remediation is done. Remediation cannot start until the report lands. And the report follows two to four weeks of testing.

A realistic rule: start testing eight to ten weeks before the auditor needs evidence. That leaves room for a remediation cycle that does not require your engineering team to drop everything.

Teams routinely lose a further week before testing even begins, on scoping approvals, credential provisioning and getting the rules of engagement signed. Start that paperwork early — it is free to do so.

For SOC 2 Type II specifically, there is an additional trap. The test must fall inside the observation window. Testing two weeks before the window opens does not count toward it, however recent it feels.

Scoping It Properly

Scope disputes with auditors almost always trace back to a decision made months earlier to save money.

Authenticated testing is not optional. Most real risk lives behind a login. An unauthenticated external test is cheaper and will produce a thinner report — and an auditor assessing access control will notice that access control was never actually tested.

APIs need explicit scoping. If your product is API-first, testing the web UI alone leaves your largest attack surface untested. Object-level and function-level authorisation failures are exactly the class of issue these frameworks care about, and they only surface with deliberate API testing.

Cloud configuration is usually in scope by implication. IAM policies, over-permissive roles and exposed storage are technical vulnerabilities within the meaning of these frameworks even though they are not application code.

Do not scope around your ugliest system. An auditor asking why the legacy monolith was excluded is a conversation that rarely ends well.

Where VAPT Fits Alongside Your Other Controls

A penetration test is one control among many, and it is a point-in-time one. It tells you what an attacker could do against the build that existed on the day of testing.

The frameworks also expect continuous controls — monitoring, configuration management, access review. That is cloud security work, and it runs constantly rather than annually. Meanwhile the controls that prevent insecure change from shipping in the first place sit in the pipeline, which is DevSecOps territory.

Auditors increasingly ask how you prevent recurrence, not just how you find issues. If the same class of finding appears in consecutive years, expect that question. Our AWS security checklist for HIPAA, SOC 2 and PCI-DSS maps where these controls overlap across frameworks, which matters because mapping once and reusing evidence saves substantial effort compared with running each certification as a separate project.

Common Mistakes That Cause a Retest

Testing outside the observation window. For SOC 2 Type II, timing is a hard requirement, not a preference.
No retest in the contract. The most commonly excluded line item, and the one the auditor asks for. Confirm it is in the price before signing.
Scope that does not match the control description. If your policy says "all production systems", testing one application creates a gap the auditor will find.
A scan sold as a pentest. Ask what proportion of the work is manual. If the report is entirely tool output, it may not satisfy a control that specifies penetration testing.
No evidence trail for remediation. "We fixed it" is not evidence. Tickets and commits are.
Letting the report go stale. Testing eleven months before a surveillance audit is technically annual and practically unconvincing.

Practical Sequence

If you are starting from a fixed audit date, this ordering works:

Confirm the framework and the exact control wording you have committed to. The wording determines the scope, not the other way round.
Scope against that wording — systems, authentication, APIs, cloud configuration.
Book testing eight to ten weeks out from the evidence deadline.
Fix as findings arrive, rather than waiting for the final report. Any competent tester reports criticals immediately.
Retest and collect the evidence package — report, remediation records, retest confirmation, tester credentials.

If you want more detail on how an engagement itself runs, our guide to what a VAPT audit covers walks through the six phases and what you receive at each stage. For the technical categories testing focuses on, the OWASP Top 10:2025 is the current reference — note that access control and design flaws, the two categories auditors probe hardest, are precisely the ones automated tools cannot find.

Getting It Scoped

If you have an audit date and need testing scoped against a specific framework, review our VAPT services or talk to our team. We will map the scope to the control wording you have actually committed to, work the timeline backwards from your evidence deadline, and tell you plainly if the date is not achievable — which is more useful than agreeing to it and missing.

Frequently Asked Questions

Does SOC 2 require a penetration test?

Not by name. SOC 2 is an attestation against the Trust Services Criteria, and no criterion mandates a penetration test explicitly. In practice testing is almost always part of the answer, because the criteria around risk assessment and monitoring are hard to satisfy convincingly without technical validation. The critical detail is your own control description — if it says annual penetration testing by a qualified third party, the auditor will hold you to that wording, and a scanner output will not demonstrate it.

What does ISO 27001 require for penetration testing?

ISO 27001 places technical vulnerability management in Annex A, and controls are selected based on your risk assessment and documented in a Statement of Applicability. It is very rare for an organisation to justify excluding it. Because scope is risk-driven, the auditor will ask why you tested what you tested — a scope that conveniently excludes your most complex system will attract questions. The three-year certification cycle also means evidence must stay current across surveillance audits.

When should we schedule a VAPT audit before a SOC 2 or ISO 27001 audit?

Start testing eight to ten weeks before the auditor needs evidence. Work backwards: the retest must complete before the evidence deadline, remediation must finish before the retest, the report follows two to four weeks of testing, and scoping approvals often consume another week before testing begins. For SOC 2 Type II there is an extra constraint — the test must fall inside the observation window, so testing shortly before the window opens does not count toward it.

What evidence do auditors actually accept?

Evidence that findings were remediated, not just that testing happened. A complete package includes the engagement letter or scope document, the technical report with severity ratings and evidence, remediation records such as tickets or commits, the retest report confirming closure, and the credentials of the people who performed the testing. A report full of open critical findings proves you tested; it does not prove your controls operate effectively.

How is PCI-DSS different from SOC 2 and ISO 27001?

PCI-DSS is the most prescriptive of the three. It explicitly requires internal and external penetration testing, plus segmentation testing where segmentation is used to reduce scope, and it specifies methodology and requires findings to be remediated and retested. If you handle cardholder data, PCI-DSS sets your floor — scope it first and the other frameworks usually fall inside it.

What mistakes cause a compliance penetration test to be redone?

The most common are testing outside the SOC 2 observation window, not having the retest included in the contract, a scope that does not match your own control wording, a scan sold as a penetration test, and no evidence trail showing remediation actually happened. Unauthenticated-only testing is another — most real risk sits behind a login, and an auditor assessing access control will notice that access control was never tested.

VAPT for SOC 2 and ISO 27001: What Auditors Actually Accept