ISO 27001 & SOC 2:
the technical evidence auditors ask for
A practical guide for companies entering certification: which controls require testing, how often, and what the evidence an auditor accepts actually looks like.
ISO 27001 and SOC 2 are management frameworks, not vulnerability checklists. Neither one says "run a penetration test every year". Both, however, require something documents alone cannot demonstrate: proof that the technical measures actually work. That is where a pentest comes in — and why, in practice, almost every auditor asks for one.
Which ISO 27001 controls touch technical testing
The 2022 revision of Annex A restructured the controls, and three of them rest directly on testing: A.8.8 — management of technical vulnerabilities, A.8.29 — security testing in development and acceptance, and A.8.9 — configuration management. On top of these sits clause 9.1 in the body of the standard: monitoring, measurement and evaluation of ISMS performance.
The practical difference is simple: an automated scanner answers A.8.8 ("we know which vulnerabilities we have"), but not A.8.29 nor clause 9.1 ("we verified the defence holds"). A scanner does not try to chain two medium findings into a real compromise; a tester does.
Where a pentest shows up in SOC 2
SOC 2 is built on the Trust Services Criteria. Criterion CC4.1 requires periodic evaluations of controls, and CC7.1 requires detection and monitoring of vulnerabilities and new configurations. In a Type II audit the auditor does not look at a moment but at a 3–12 month window: what matters is that the testing happened within the period and that remediation was tracked to closure.
This is where the most expensive mistake comes from: a pentest report dated before the observation period began does not count as evidence for that period. Testing is planned together with the audit window, not after it.
What each framework asks for — and what the pentest delivers
| Control / criterion | Relevant requirement | Evidence from the pentest |
|---|---|---|
| ISO 27001 — A.8.8 | Technical vulnerabilities are identified and addressed | Finding list with severity, proof and remediation plan |
| ISO 27001 — A.8.29 | Security testing in development and acceptance | Pre-production test before release, with acceptance criteria |
| ISO 27001 — clause 9.1 | Evaluation of security performance | Comparison across two test cycles: what closed, what came back |
| SOC 2 — CC4.1 | Periodic evaluations of control effectiveness | Report dated inside the observation window, with documented scope |
| SOC 2 — CC7.1 | Detection of vulnerabilities and configuration change | Configuration findings, plus a re-test proving closure |
When to test, within the certification cycle
- Before the stage 2 audit (ISO) — so you do not discover major findings in front of the auditor.
- In the first weeks of the SOC 2 Type II observation period — leaving time for remediation and a re-test inside the same window.
- Annually, for surveillance audits.
- After any major architecture change, cloud migration or new product launch.
What the report must contain to satisfy an auditor
- Explicit scope: which addresses, applications and accounts were in the test — and what stayed out of it.
- Stated methodology (OWASP, PTES) and testing start/end dates.
- Justified severity, not just a CVSS score copied from a scanner.
- An executive summary the management committee can read without technical translation.
- A documented re-test, with the final state of every finding.
Frequently asked questions
Does ISO 27001 mandate a penetration test?
The standard does not use the word "pentest" as an explicit obligation. However, controls A.8.8, A.8.29 and clause 9.1 require identifying technical vulnerabilities, testing security and evaluating the effectiveness of measures. In practice auditors accept a penetration test as the most direct evidence for these requirements, and an organisation that declared A.8.29 applicable without being able to show testing risks a nonconformity.
Is a vulnerability scan enough for SOC 2?
Scanning covers the continuous monitoring part of CC7.1, but on its own it rarely satisfies CC4.1, which requires evaluating control effectiveness. A scanner reports what might be vulnerable; a penetration test shows what can actually be exploited and how far an attacker gets. Most auditors expect both: recurring scanning plus at least one manual test inside the observation period.
How old can the pentest report be at audit time?
The usual rule is twelve months at most, but for SOC 2 Type II something else matters: the report must be dated inside the observation period. An excellent test run a month before the window opened produces no evidence for that window. For ISO, the test is recommended before the certification audit and then annually at surveillance.
What scope must be tested for certification?
The test scope must cover the systems inside the ISMS scope, respectively the systems supporting the chosen SOC 2 criteria: customer-facing applications, the infrastructure hosting them, authentication mechanisms and, increasingly, cloud configuration. A test scope narrower than the declared scope is exactly the thing an auditor notices first.
Who can run the test — an internal team?
It can be, but independence matters. ISO 27001 requires the evaluation to be objective, and SOC 2 looks more favourably on an external party. If the team that built the system is also the team testing it, the auditor will ask for additional evidence of segregation of duties. The simplest route is an external provider with a stated methodology and an independent report.
Related guides
- What a pentest costs — what drives the price, how effort is estimated, and what makes two quotes comparable.
- DORA & TLPT — digital operational resilience in finance and threat-led penetration testing.
- Moldova’s Law 48/2023 — the national cybersecurity framework: who is in scope and what obligations it brings.
- OWASP Top 10 — the ten web risk categories, explained with examples and what gets tested in each.
- PCI DSS 4.0 — requirements 11.3 and 11.4, segmentation testing, and what it means for payment processors.
- Pentest vs vulnerability scanning — what each one finds, what it misses, and what auditors accept as evidence.
- How to prepare for a pentest — scope, access, rules of engagement and everything settled before day one.
This material is informational and does not constitute certification advice. Exact requirements depend on your declared scope and on the certification body or audit firm you work with.
Heading into certification this year?
Book a free consultation and get a testing plan aligned to your scope and audit calendar.