ISO/IEC 27001
ISO 27001 penetration testing
ISO/IEC 27001 does not use the words "penetration test" — but Annex A 8.8 requires you to manage technical vulnerabilities and A 8.29 requires security testing. Auditors read both as asking for independent, evidenced testing.
We produce exactly the artefacts a certification or surveillance audit asks to see, and we write them so an assessor can follow them without a translator.
THEY TRUST US
ISO/IEC 27001
Which controls a penetration test speaks to
Whether you are working toward first certification, preparing for a surveillance audit, or answering a customer security questionnaire, the same handful of Annex A controls come up. A penetration test is direct evidence for each of them.
We are ourselves ISO 27001 certified, so the evidence pack we hand you is the same shape as the one we maintain internally.
Annex A control → what we deliver
| Control | What Haxoris delivers |
|---|---|
| A 8.8 — Management of technical vulnerabilities | Identification, validation and prioritisation of the vulnerabilities actually present in your systems, with severity and exploitability evidenced rather than asserted by a scanner. |
| A 8.29 — Security testing in development and acceptance | Application and API testing against OWASP ASVS and WSTG, scheduled so it fits your release cycle rather than blocking it. |
| A 8.25 / A 8.28 — Secure development lifecycle and secure coding | Findings traced back to the coding or design pattern that produced them, so the fix removes a class of bug rather than one instance. |
| A 5.7 — Threat intelligence | Testing informed by the attack techniques currently used against your sector, not a generic checklist. |
| Clause 9.1 / 9.2 — Monitoring, measurement and internal audit | An independent measurement of control effectiveness that your internal audit programme can cite directly. |
Certification, surveillance and recertification
| Stage | What auditors typically expect | How we fit in |
|---|---|---|
| Initial certification (Stage 1 & 2) | Evidence that technical vulnerability management is operating, not just documented | A full-scope test plus remediation record, timed a few weeks before Stage 2. |
| Annual surveillance | Evidence that testing continued and that prior findings were closed | An annual retest with a comparison against the previous engagement. |
| Recertification (3-year cycle) | A demonstrable trend of improvement across the cycle | Year-on-year findings data showing what changed and what stayed fixed. |
Certification bodies differ in what they ask for. If your auditor has issued specific expectations, send them to us and we will scope the test to meet them.
The evidence chain an auditor expects
An assessor is looking for a closed loop, not a PDF. We produce every link in it:
Scope and authorisation
A written scope tied to your Statement of Applicability, plus rules of engagement and signed authorisation.
Test report
Findings with severity, business impact, reproduction steps and evidence, cross-referenced to the Annex A controls they bear on.
Remediation record
Each finding mapped to a fix, an owner and a date — the record your corrective-action process consumes.
Retest and statement
A free retest and a written statement of what was resolved, which is the artefact that closes the nonconformity.
What you get
Every ISO 27001 engagement includes the following as standard:
Auditor-ready report with an executive summary
Findings mapped to Annex A controls
Free retest once fixes are deployed
Written retest statement for your evidence pack
Debrief call with your engineers and your ISMS owner
Testing by OSCP- and CISSP-certified testers
TESTIMONIALS
What our clients say about us
ISO 27001 and penetration testing — common questions
01 Does ISO 27001 require a penetration test?
Not in those words. Annex A 8.8 requires management of technical vulnerabilities and A 8.29 requires security testing in development and acceptance. In practice, auditors accept an independent penetration test as the strongest available evidence for both, and many certification bodies expect one.
02 When should we test relative to the audit?
Ideally a few weeks before Stage 2, so there is time to remediate and retest before the assessor arrives. Testing after the audit means carrying findings into the report; testing too early means the evidence is stale.
03 Do you map findings to Annex A controls?
Yes, as standard. Each finding names the controls it bears on, so your ISMS owner can file the report against the right control without re-reading it.
04 How much does an ISO 27001 penetration test cost?
It depends on scope. A basic web application test starts from around €2,000; wider ISMS scopes covering multiple systems cost more. A typical engagement runs 5 to 15 person-days and we quote a fixed price after a short scoping call.
05 Is Haxoris itself certified?
Yes — Haxoris is ISO 27001 certified by TÜV SÜD. We are happy to share our certificate details on request, and the evidence pack we hand clients mirrors the one we maintain for our own audits.
06 Can you also help us close the findings?
We can advise on remediation and we retest for free, but we deliberately do not sell the fixes we recommend. Testing and remediating with the same supplier removes the independence an auditor is looking for.
Get your ISO 27001 evidence in order
Tell us where you are in the certification cycle and we will scope a test that produces exactly what your auditor asks for. NIS2 penetration testing · Vulnerability assessment · Red teaming
Book a free ISO 27001 call