A penetration test is not a compliance box to tick. When it feeds into your ISO 27001 or NIS 2 programme, scope, methodology, and reporting all need to satisfy specific requirements. A pentest that does not meet these requirements leaves you with a report and a bill, not with evidence.

What auditors actually expect

Both ISO 27001 (A.8.8, A.8.29) and NIS 2 implementation acts require evidence of technical security testing. The auditor's questions are consistent: Was the scope appropriate to the control objective? Was the methodology rigorous and documented? Were findings risk-rated and tracked through to remediation? Was the test recent enough to reflect current infrastructure?

Any of these failing renders the test insufficient as compliance evidence, regardless of what the report cost.

The test that satisfies the auditor is not the test that finds the most vulnerabilities. It is the test with defensible scope, documented methodology, and clear evidence of remediation.

Scope: what to test

Start from the control objective. For ISO 27001 A.8.29, the objective is verifying that the information processing facilities are tested for security. That points to infrastructure, applications, and exposed services — but also to your internal network segmentation, privileged access controls, and any web-facing authentication. Scope that excludes the critical attack surface fails the objective, regardless of what was tested.

Methodology: what rigour looks like

OWASP Testing Guide for web applications. OSSTMM or PTES for broader engagements. Authenticated and unauthenticated perspectives where applicable. Documented test cases. A rules-of-engagement document agreed before test start. CVSS-scored findings with context about exploitability in your environment — not raw CVSS from a vulnerability scanner.

Reporting: what evidence should contain

Executive summary with risk context for non-technical readers. Detailed findings with reproduction steps, CVSS score, and recommended remediation. Methodology and scope appendix. Evidence artefacts (sanitised screenshots, request/response pairs). Retest results where remediation has been verified. A report missing any of these is incomplete.

Cadence: how often

Annual for stable infrastructure. After any material change to the attack surface (new application, major architectural change, migration). After a significant incident. Quarterly scans complement but do not replace the annual pentest.

The red flag in procurement

If a vendor offers a penetration test for a price that seems low for the scope, the test is probably a vulnerability scan with a rewritten cover page. A genuine pentest involves manual exploitation, chained attack paths, and analyst judgement. It cannot be automated. Vendors who try to automate it produce reports that auditors recognise immediately.