ISO 27001
ISO 27001 Penetration Testing
Manual, tester-led testing mapped to Annex A.8.29 and your Statement of Applicability - evidence designed to support your auditor and feed your ISMS.
UK-based testers · ISO 27001 / Cyber Essentials Plus certified ourselves · Findings tagged against Annex A controls
Why this matters
Why ISO 27001 expects penetration testing.
ISO/IEC 27001:2022 doesn't say "thou shalt pentest" in those words - but in practice, your certification body expects it. Annex A.8.29 (Security testing in development and acceptance) and A.8.8 (Management of technical vulnerabilities) are the controls that make pentesting effectively non-optional for any organisation with internet-facing systems or developed software in scope.
Your Statement of Applicability has to justify which Annex A controls apply, and how. If A.8.29 is in scope (it almost always is) and you can't show evidence of regular technical testing, your Stage 2 audit gets uncomfortable. Surveillance audits in years 2 and 3 expect to see continued evidence - which is why most ISO 27001-certified organisations run an annual pentest cycle aligned to their audit calendar.
A pentest also feeds your risk treatment plan. Findings become risks; risks get treated; treatment gets evidenced; evidence supports your next audit. The cycle works in your favour if it's set up properly.
What gets tested - and which Pentiq service covers it.
Your scope is determined by your ISMS scope statement and Statement of Applicability - not a fixed checklist. We work from your SoA during scoping to define a proportionate test plan.
| Control area | What's assessed | Pentiq service |
|---|---|---|
| A.8.29 - Security testing in development and acceptance | Evidence of pre-release and periodic testing of applications | Web Application & API Testing |
| A.8.8 - Management of technical vulnerabilities | Regular identification and remediation of vulnerabilities | External & Internal Infrastructure Testing, Vulnerability Scanning |
| A.8.9 - Configuration management | Secure baseline verified, drift detected | Build Reviews, Internal Infrastructure Testing |
| A.8.28 - Secure coding | Code-level review of in-house developed software | Code & Build Reviews |
| A.5.7 - Threat intelligence | Awareness of relevant threats; periodic adversary simulation | Red Teaming |
| A.6.3 - Information security awareness | Tested human controls | Social Engineering & Phishing Simulation |
Scope my test
Get a tailored ISO 27001 test scope.
Tell us what's in your ISMS scope and we'll come back with a proportionate engagement aligned to your SoA - usually within one working day.
What's in scope?
Select everything you'd like tested. Pick more than one if it applies.
Prefer to talk first? Book a 20-minute scoping call ->
Engagement
What a Pentiq ISO 27001 engagement looks like.
Scoping
A short call with your technical contact to confirm scope, agree the test plan, and book delivery dates against your ISO 27001 timeline.
Testing
Testing runs against the agreed scope. Findings appear in your Pentiq portal in real time, so your team can start triaging without waiting for a final report.
Reporting & remediation
Final report delivered through the portal: executive summary, technical findings mapped to ISO 27001 control areas, and remediation guidance for each issue.
Optional re-test
We re-test fixed findings before your ISO 27001 assessment so you walk in clean.
Engagement length depends entirely on scope - we confirm a realistic timeline during the scoping call.
Common questions
Frequently asked questions.
Does ISO 27001:2022 require penetration testing?
Not by literal name - but Annex A.8.29 and A.8.8 effectively require it for any organisation with software or internet-facing systems in scope. Certification bodies expect to see pentest evidence; lack of it is a common nonconformity.
How often should we pentest for ISO 27001?
At minimum annually, aligned to your surveillance audit cycle. Higher-risk systems (internet-facing, processing sensitive data, recently changed) often warrant more frequent testing - quarterly scans plus an annual deep test is a common pattern.
We're going for initial certification - when in the process should we test?
Before your Stage 2 audit. Stage 2 is where the auditor verifies controls are actually implemented; walking in with a recent pentest report (and remediation evidence) is significantly stronger than promising one is coming.
Our SoA excludes some controls - can the pentest scope be narrower?
Yes. We scope to your ISMS boundary and SoA. If A.8.28 is excluded because you don't develop software, we don't test code. The test scope follows the certified scope.
What about the new 2022 version - does it change anything?
The control numbering changed (A.8.29 was A.14.2.8 in 2013) and threat intelligence (A.5.7) and secure coding (A.8.28) became more explicit. The practical pentesting implications are similar; what changed most is the SoA expectations around justifying control selection.
Will the report be acceptable to our certification body?
Reports are designed to support certification body review - findings tagged against Annex A controls, an executive summary suitable for management review, and a clean post-remediation export your auditor can review without seeing the pre-remediation noise. Final acceptance is always at the certification body's discretion, but reports are written with their expectations in mind.
Do you also do ISO 27001 consultancy?
We're a testing firm, not a certification consultancy. We can introduce you to ISO 27001 implementation consultants and certification bodies. Stick with one firm for testing and a different firm for ISMS implementation - auditors prefer the separation.