An assessor does not read a penetration test report the way an engineer does. The assessor looks for the scope and whether it matches the environment under audit, for the method, for the dates, for the qualification and independence of the testers, and for proof that the findings were fixed and retested.
We scope the test against the requirement it has to satisfy and structure the report so that those answers are easy to find. The testing itself is not reduced: a test designed only to pass an audit protects nothing, and assessors increasingly recognise one when they see it.
01Scope
What we test
PCI DSS v4.0.1: external and internal penetration testing under requirement 11.4
PCI DSS segmentation testing of the cardholder data environment
SOC 2: testing as evidence for the monitoring and vulnerability criteria
ISO/IEC 27001:2022: technical vulnerability management and security testing controls
DORA: digital operational resilience testing of ICT systems
NIS2: assessment of the effectiveness of risk management measures
GDPR Article 32: regular testing of technical and organisational measures
Customer and partner security questionnaires that require a recent test
02Approach
How the work is done
01
Requirement mapping
We establish which requirement the test serves, what it demands in terms of scope, frequency and method, and what your assessor expects to see.
02
Scope alignment
The scope of the test is matched to the boundary of the audited environment. Differences are documented and justified.
03
Testing
The test follows our standard methodology for the type of system. Nothing is left out because the framework does not name it.
04
Evidence
The report states method, dates, tester qualification and independence. After the retest, a letter summarises the result for third parties without technical detail.
No. Compliance is determined by your assessor on the basis of all controls. The test provides the evidence for the requirements that concern security testing and tells you what to fix before the assessor arrives.
Do SOC 2, ISO/IEC 27001, NIS2 or GDPR require a penetration test?
None of them names it as a mandatory control in those words. They require that vulnerabilities are identified and that the effectiveness of measures is tested regularly. A penetration test is the evidence that auditors most commonly expect for those requirements. PCI DSS and DORA are explicit.
How often does the test have to be repeated?
PCI DSS requires penetration testing at least once every twelve months and after significant changes, and segmentation testing at least once every twelve months, every six months for service providers. DORA requires testing of critical systems at least yearly. For other frameworks the frequency follows from your own risk assessment; annual testing is the usual expectation.