ISO 27001 never uses the words penetration test, but if you are heading for certification you will almost certainly need one. Annex A control 8.8 — management of technical vulnerabilities — is where auditors expect to see evidence that you actively identify and address weaknesses, and an independent penetration test is the strongest evidence there is. The trick is scoping it from your ISMS rather than paying to test everything you own.
Where penetration testing fits in ISO 27001:2022
Several parts of the standard converge on testing:
- Annex A 8.8 (management of technical vulnerabilities) requires you to obtain information about technical vulnerabilities in your systems, evaluate your exposure and take appropriate action. Vulnerability scanning contributes, but a manual penetration test demonstrates the control with far more force.
- Annex A 8.29 (security testing in development and acceptance) expects security testing to be built into your development lifecycle.
- Clause 9.1 (monitoring, measurement, analysis and evaluation) requires you to evaluate the performance and effectiveness of the ISMS — and little evaluates technical controls as honestly as someone attempting to defeat them.
ISO 27001 is risk-based, so nothing prescribes frequency or depth. What certification auditors look for is a defensible position: you assessed your risks, decided how testing addresses them, did the testing, and acted on the results.
Right-sizing scope from your statement of applicability
This is where organisations either overspend or underdeliver. Your ISMS has a defined scope, and your statement of applicability (SoA) records which Annex A controls apply and why. The penetration test should map to both:
- Test the systems inside ISMS scope — typically the customer-facing platform, the APIs behind it, the external perimeter and the cloud environment hosting the information assets your ISMS protects.
- Let the SoA and risk register guide depth. If 8.8 and 8.29 are applicable because you build software that handles customer data, a thorough web application and API test is justified. If your risk register flags cloud misconfiguration, add a cloud configuration review.
- Leave out-of-scope systems out. If the corporate wiki sits outside your ISMS boundary, paying to test it adds cost without advancing certification.
A short conversation about your ISMS boundary usually shrinks the engagement compared with a test-everything quote. This is exactly what our ISO 27001 penetration testing service is built around, with engagements typically running AU$8,000–16,000.
Audit-ready deliverables
A pentest only helps certification if the paperwork holds up. Ask any prospective tester for:
- A full technical report with methodology, findings rated by severity, and clear remediation guidance — your primary evidence for 8.8.
- An executive summary that a certification auditor, who may not be deeply technical, can digest quickly.
- Remediation evidence and a retest report. Auditors want to see the loop closed: found, fixed, verified. We retest fixed issues free within 90 days for exactly this reason.
- An attestation letter you can hand to customers and partners without exposing technical detail.
File the report, your remediation tickets and the retest letter against 8.8 in your evidence pack, and reference the testing cycle in your vulnerability management procedure so the document trail is consistent.
When to test in the certification cycle
- Before your Stage 2 audit, with enough time to remediate significant findings first.
- Annually thereafter, feeding surveillance audits and management review.
- After significant change — major releases, new infrastructure, acquisitions.
An annual cadence also keeps you aligned with what enterprise customers expect; we go deeper on timing in how often you should pentest.
What auditors ask about your testing
Certification and surveillance auditors rarely stop at sighting a report. Expect questions like: how did you decide the scope of the test, and can you show the link back to your risk assessment? Who performed it, and how did you assure their independence and competence? What happened to each finding — where are the tickets, and was remediation verified? How does testing feed your management review and continual improvement?
This is why the SoA-driven scoping matters beyond cost. When you can show a straight line from risk assessment to test scope to findings to closed tickets to management review minutes, the 8.8 conversation takes five minutes. When the test was an arbitrary purchase disconnected from the ISMS, auditors notice — and start digging elsewhere.
FAQ
Does ISO 27001 mandate an annual penetration test?
Not explicitly — the standard is risk-based. In practice, annual testing is the cadence auditors are comfortable with and the easiest position to defend at surveillance audits.
Do we have to test everything in our ISMS scope?
No. Prioritise the systems where your key information assets live and where your risk assessment points. Testing should be defensible, not exhaustive.
Will a vulnerability scan satisfy Annex A 8.8?
Scanning is part of managing technical vulnerabilities, but on its own it is weak evidence. A manual penetration test demonstrates the control is genuinely effective, and most auditors expect to see one for internet-facing systems.
Working toward certification? Get in touch for a free scoping call — we will map the test to your ISMS scope and SoA and return a fixed quote within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.