ISO 27001 penetration testing
ISO/IEC 27001:2022 (Information Security Management System)
Technical vulnerability and security testing evidence your certification body expects at Stage 2.
Engagement at a glance
Drives testing
A.8.8, A.8.29 and clause 9.1: Technical vulnerabilities, security testing and evaluation
Cadence
At least annually, and on significant change to in-scope systems
Typical duration
2 to 3 weeks of testing, plus retest
Region
Global
Issued by
Certified by an accredited certification body
93
Annex A controls in the 2022 revision
3
Controls directly evidenced
3 yr
Certification cycle
Annual
Recommended testing cadence
The requirement
What ISO 27001 asks for
A.8.8, A.8.29 and clause 9.1 · Technical vulnerabilities, security testing and evaluation
Annex A.8.8 requires information about technical vulnerabilities to be obtained and appropriate measures taken. A.8.29 requires security testing to be defined and implemented in the development and acceptance process. Clause 9.1 requires the organisation to evaluate the performance and effectiveness of the ISMS.
ISO 27001 certification auditors work from evidence. When they reach A.8.8 on technical vulnerabilities and A.8.29 on security testing, they want to see that you actually find weaknesses in your systems and do something about them, not that you have a policy saying you will.
An independent penetration test is the cleanest way to close those controls. It also feeds clause 9.1, where you have to evaluate whether the ISMS is performing, and it gives your internal audit and management review something concrete to discuss rather than a list of unverified assertions.
XHack delivers that testing evidence. We scope to your ISMS boundary, test, report against the Annex A controls the findings touch, support remediation, retest to closure and sign an attestation letter. Your certification body runs the Stage 1 and Stage 2 audits and issues the certificate.
What your auditor checks
The report has to clear every one of these
These are the questions a ISO 27001 auditor asks of a penetration test before accepting it as evidence. Every engagement we run is built to answer all of them.
Independent of the team that built and operates the systems
Scope aligned to the ISMS boundary and Statement of Applicability
Recognised methodology documented in the report
Findings rated consistently, with CVSS v4.0 vectors
Technical vulnerabilities linked to A.8.8 treatment
Testing linked to A.8.29 where development and acceptance are in scope
Remediation recorded and owned
Independent retest confirming closure
Evidence usable in internal audit and management review
Signed attestation letter from the testing firm
What we test
Where the testing effort concentrates
The surfaces this engagement covers, weighted by how much of the work they typically represent. Scope is confirmed with you before anything starts.
In-scope applications and APIs
Systems named in the ISMS scope statement
95%
External perimeter
Internet-facing services in scope
85%
Internal network and hosts
Where the ISMS boundary includes them
75%
Cloud configuration
IAM, storage, network posture
70%
Development and acceptance testing
Evidence for A.8.29
60%
Weights are indicative of typical effort. Your exact scope is agreed and signed before testing begins.
How the engagement runs
Scope, test, close, attest
Typically 2 to 3 weeks of testing, plus retest. The retest is included, because a report full of open findings is not evidence of anything.
Scope to the ISMS boundary
We read your scope statement and Statement of Applicability so the test covers what the certification body will ask about, and nothing outside it.
Test under signed rules of engagement
Grey-box testing across applications, APIs, perimeter and internal network as the boundary requires, following PTES, OWASP WSTG and NIST SP 800-115.
Report mapped to Annex A
Each finding is mapped to the Annex A controls it touches, so the evidence lands where the auditor is looking rather than in a general appendix.
Remediation and treatment
Findings feed your risk treatment under A.8.8. We support your team through the fixes and escalate anything critical immediately.
Retest and attestation
Every finding retested and closed, with an attestation letter you can put in front of the certification body at Stage 2.
Where the effort goes
Share of a typical engagement, by phase
Scoping & rules of engagement
15%
Testing & exploitation
45%
Reporting & mapping
20%
Retest & attestation
20%
What we bring
Built for the ISO 27001 auditor specifically
The parts of this engagement that are shaped by the framework rather than copied from a generic testing template.
Mapped to Annex A
Findings cross referenced to A.8.8, A.8.29, A.8.25 and the access and cryptography controls, so the auditor sees the link immediately.
Closed before Stage 2
We plan the retest so your register can be clean when the certification audit happens, rather than open findings going into it.
Internal audit input
The report is written so it can be cited in your internal audit and management review records under clause 9.
Surveillance ready
An annual cadence that keeps A.8.8 evidenced for the surveillance audits in years one and two.
The deliverable
What lands on your auditor's desk
A report structured so the evidence sits where the auditor is already looking, with every finding mapped to the control it touches.
In the report
Signed letter of attestation from the testing firm
Scope statement tied to the ISMS boundary
Methodology, tester qualifications and independence statement
Findings with CVSS v4.0, evidence and reproduction steps
Annex A control mapping per finding
Remediation implemented and independent retest result
Summary suitable for internal audit and management review
Control mapping
How the report evidences each control
A.8.8
Technical vulnerabilities identified, rated and fed into your treatment process.
A.8.29
Security testing evidence for development and acceptance where in scope.
A.8.25
Secure development lifecycle weaknesses surfaced and remediated.
A.5.15 to A.5.18
Access control findings tested and closed.
Clause 9.1
Independent evaluation of how effectively the controls actually perform.
Where our work stops, and who takes it from there
XHack provides the penetration testing evidence for A.8.8, A.8.29 and clause 9.1. We do not issue certificates, attestation opinions or regulatory approvals, and we do not run your wider compliance programme. For ISO 27001, that sits with: Certified by an accredited certification body. Staying independent of them is exactly what makes our evidence worth something when they review it.
Questions
ISO 27001 testing, answered
The standard does not name it. It requires you to manage technical vulnerabilities (A.8.8) and to test security in development and acceptance (A.8.29), and to evaluate effectiveness under clause 9.1. Certification auditors routinely accept an independent penetration test as the evidence for those, and routinely question programmes that have none.
No. We provide the technical testing evidence. Building the ISMS, the risk assessment, the Statement of Applicability and the policy set is your programme, run by you or a compliance consultancy. We slot into it with the part that needs an independent offensive security team.
Far enough before Stage 2 that findings are remediated and retested. Turning up to a certification audit with open high severity findings and no retest is an avoidable way to collect a nonconformity.
Yes, and it usually should. The underlying testing is the same. We map one engagement to both the Annex A controls and the Trust Services Criteria so a single report serves both audits.
Other frameworks we test for
Get the ISO 27001 evidence sorted
Tell us who is auditing you and when your review period closes. We will scope the test, tell you what it costs, and make sure there is room to remediate and retest before the deadline.