Skip to content
Sovereign SecureSovereign Secure

ISO/IEC 27001:2022 Annex A

ISO 27001 Penetration Testing (Annex A 8.8 and 8.29)

ISO 27001 penetration testing scoped to your ISMS and mapped to the Annex A controls your certification auditor will sample, from a UK firm that is ISO 27001 certified itself.

Prefer to talk? Call +44 161 523 5276

  • Mapped to Annex A 8.8, 8.29 and 8.34
  • Evidence pack built for your auditor
  • From an ISO 27001-certified UK firm

The short answer

ISO 27001 does not explicitly require penetration testing. But Annex A control 8.8 requires you to identify, evaluate and fix technical vulnerabilities, and 8.29 requires security testing during development and acceptance. For most organisations, a test every 12 months and after significant change, with a retest of fixed findings, is the clearest evidence of both.

On this page
  1. Does ISO 27001 require penetration testing?
  2. ISO 27001 penetration testing requirements by control
  3. What do ISO 27001 auditors ask for?
  4. How do we scope a penetration test for ISO 27001?
  5. How often should you pen test for ISO 27001?
  6. Is penetration testing required for PCI DSS and Cyber Essentials Plus?
  7. What goes in your ISO 27001 evidence pack?
  8. Penetration testing alongside ISO 27001 consultancy
  9. How much does a pen test for ISO 27001 cost?
  10. Why Sovereign Secure
  11. Get a quote for your ISO 27001 test

ISO 27001 does not name penetration testing as a requirement, but it expects what a test proves. Annex A control 8.8 requires you to find, evaluate and fix technical vulnerabilities, and 8.29 requires security testing before systems and changes go live. ISO 27001 penetration testing is the most direct way to evidence both, and a recent report with a retest is what certification auditors commonly ask to see.

Sovereign Secure is ISO 27001 certified and provides both ISO 27001 consultancy and penetration testing services. We scope each test from your ISMS scope and risk assessment, and report against the controls your auditor will sample.

Does ISO 27001 require penetration testing?

Not in so many words. Neither the ISO 27001 requirements in clauses 4 to 10 nor the Annex A controls of ISO/IEC 27001:2022 use the phrase, because the standard sets outcomes and leaves methods to you. Three things still make a test the expected answer:

  • The guidance points to it. ISO/IEC 27002:2022, the guidance behind Annex A, lists planned, documented and repeatable penetration tests or vulnerability assessments by competent, authorised people as a way to identify vulnerabilities under 8.8.
  • Your own policy binds you. Clause 9.2 requires internal audits to check you meet your own ISMS requirements. If your policy says “annual penetration test”, the auditor will check you had one.
  • Customers ask. Security questionnaires, tenders and insurers regularly ask for the date of your last independent test.

A missing report is not a nonconformity in itself, unless your own policy or risk treatment plan commits you to a test. Auditors will ask how you identify vulnerabilities and test security before release, and if you run internet-facing systems or build software, a manual test is the most credible answer. The NCSC’s penetration testing guidance frames it the same way: a test gives assurance that your vulnerability management works, rather than replacing it.

ISO 27001 penetration testing requirements by control

One test evidences several Annex A controls. The 2013 numbers are shown because many policies still quote them, although every certificate has had to use the 2022 version since 31 October 2025.

2022 control 2013 equivalent What it asks for How a penetration test helps
8.8 Management of technical vulnerabilities A.12.6.1, A.18.2.3 Identify technical vulnerabilities, evaluate your exposure and act Finds exploitable weaknesses scanners miss; the retest proves they are closed
8.29 Security testing in development and acceptance A.14.2.8, A.14.2.9 Define and run security testing in the development life cycle Independent application and API testing before go-live or a major release
8.34 Protection of information systems during audit testing A.12.7.1 Plan and agree tests of live systems between tester and management Signed rules of engagement, test windows and contacts
8.20 Networks security and 8.22 Segregation of networks A.13.1.1, A.13.1.3 Secure networks and keep groups of systems and users apart Internal testing shows whether segregation actually holds
5.35 Independent review of information security A.18.2.1 Independent review at planned intervals or after significant change Third-party technical assurance on your controls

If your Statement of Applicability (SoA) excludes 8.29 because you develop no software, record why; an unexplained exclusion invites a finding.

What do ISO 27001 auditors ask for?

They want evidence that vulnerabilities are found, judged against your risk criteria and dealt with. Expect these questions at Stage 2 and each surveillance audit:

  • How do you identify technical vulnerabilities, and how often? Show me the last scan and the last test.
  • Does the test scope match the ISMS scope and your asset inventory?
  • What happened to the high and critical findings? Where is the retest?
  • Who accepted the risks you chose not to fix?
  • How is security tested before a release goes live?
  • Who authorised testing of live systems?

Evidence usually falls short on the same points: a report older than your policy allows, a scope that misses a certified system, findings with no retest, or unsigned residual risks.

How do we scope a penetration test for ISO 27001?

Start from your ISMS scope statement (clause 4.3) and asset inventory (control 5.9), not a list of IP addresses. Then prioritise the systems behind your highest risks and anything your certificate names.

Part of your ISMS Test that evidences it Main controls
Websites, VPN, remote access and other internet-facing services External infrastructure test 8.8, 8.20
Office network, servers and Active Directory Internal infrastructure test 8.8, 8.22
Customer-facing web applications and SaaS platforms Web application penetration testing following the OWASP Web Security Testing Guide 8.29, 8.8
APIs, integrations and mobile apps API and mobile application tests 8.29
AWS, Azure or Microsoft 365 tenancy Cloud configuration review and test 8.8, 5.23
Staff Phishing and social engineering test 6.3
Everything, between tests Vulnerability scanning 8.8

Before touching live systems we agree rules of engagement with you: dates, contacts, out-of-bounds actions and data handling. That signed agreement is your 8.34 evidence.

Building a SaaS product? Our guide to ISO 27001 for startups shows where an application and API test fits in a lean ISMS alongside the secure development controls 8.25 to 8.29.

How often should you pen test for ISO 27001?

ISO 27001 sets no interval: your risk assessment decides, and your policy then binds you. A defensible baseline:

Activity Suggested frequency Control
Automated external and internal vulnerability scans Monthly or continuous 8.8
External and internal infrastructure test Every 12 months and after significant change 8.8
Web application and API test Every 12 months and before major releases 8.29
Social engineering test Every 12 months if phishing is a top risk 6.3

Define “significant change” in your policy, such as a new platform or cloud migration, so the auditor can check you applied it.

Is penetration testing required for PCI DSS and Cyber Essentials Plus?

PCI DSS requires it outright; Cyber Essentials Plus does not. One well-scoped test can serve several frameworks.

Framework Penetration test required? How often
ISO/IEC 27001:2022 Not explicitly; expected under 8.8 and 8.29 where risk justifies it Set by your risk assessment and policy
PCI DSS v4.0.1 Yes: Requirement 11.4 internal, external and segmentation tests Every 12 months and after significant change (segmentation six-monthly for service providers)
Cyber Essentials Plus No: vulnerability scans and device tests against the five technical controls At each annual certification

Taking card payments? PCI DSS penetration testing scoped to Requirement 11.4 can evidence 8.8 as well.

What goes in your ISO 27001 evidence pack?

We map findings to the Annex A controls above and help you complete the records an auditor samples:

Evidence What it proves Clause or control
Signed scope and rules of engagement Testing was planned, authorised and matched the ISMS scope 4.3, 8.34
Report: methodology, dates, tester and risk-rated findings A competent, independent tester looked for vulnerabilities 8.8, 8.29, 5.35
Risk register and treatment plan entries Findings were assessed against your risk criteria 6.1.2, 6.1.3
Retest letter Fixed issues are confirmed closed 8.8, 10.2
Residual risk acceptance Risk owners signed off what was not fixed 6.1.3
Management review minutes Leadership saw the results 9.3

Penetration testing alongside ISO 27001 consultancy

Test after your risk assessment, early enough to fix and retest before Stage 2. With our consultancy, the sequence is:

  1. ISO 27001 gap analysis.
  2. Risk assessment and Statement of Applicability.
  3. Penetration test of the in-scope systems.
  4. Remediation, retest and residual-risk sign-off.
  5. Internal audit and management review.
  6. Stage 1 and Stage 2 certification audits by MQA International.
  7. A repeat test each year, ahead of each surveillance audit and recertification in year three.

How much does a pen test for ISO 27001 cost?

It depends on scope, so we quote a fixed price after scoping. The drivers are external IPs, internal hosts, applications, APIs, user roles and cloud accounts. Published UK pricing guidance we reviewed in September 2026 put typical tester day rates at about £1,000 to £1,500. Our guide to penetration testing cost shows how scope turns into days.

Why Sovereign Secure

  • ISO 27001 certified ourselves. We work to the same standard we help you meet.
  • Consultancy and testing in one team. Findings go straight into your risk register and SoA, while certification audits stay independent with our partner certification body, MQA International.
  • Every test type. Network, web, API, cloud, mobile, wireless, IoT, social engineering and red team testing.
  • Assessor credentials. A PCI SSC-approved QSA, Qualified PIN Assessor and Card Production Security Assessor company, PCI SSC GEAR member for 2026 to 2028, and IASME-licensed Cyber Essentials certification body.
  • UK based, international reach. Head office in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka. Clients include Accor, Fiserv, Ticketmaster and Cashplus.

Get a quote for your ISO 27001 test

Send your ISMS scope statement, a list of in-scope systems and your next audit date. We will reply with a fixed scope, price and test dates that leave time to fix and retest. Use our penetration testing quote form, call +44 161 523 5276 or email [email protected].

Last reviewed October 2026 by the Sovereign Secure assessment team.

Trusted by banks, payment providers and global brands

  • Accor
  • Fiserv
  • JCPenney
  • Ticketmaster
  • Nitecrest
  • Cashplus
  • Ahli United Bank
  • Kuwait Finance House
  • AYA Bank
  • Bank of Palestine
  • Liquid Pay
  • DataFlow Group
  • Wilmington
  • The Growth Company
  • Wahyukart

FAQ

Frequently asked questions

Can't find your answer? Call us on +44 161 523 5276 or send us a message.

Does ISO 27001 require penetration testing?

Not explicitly: neither the clauses nor the 93 Annex A controls use the words. But control 8.8 requires you to find and fix technical vulnerabilities and 8.29 requires security testing before go-live, and a penetration test is the most direct evidence of both.

Is a vulnerability scan enough for ISO 27001?

It can be, if your risk assessment supports it and you develop no software. Scans find known weaknesses, but they miss logic flaws, broken access control and chained attacks, so if you build applications or hold sensitive customer data, a manual test is the stronger evidence for 8.8 and 8.29.

How often should we pen test for ISO 27001?

The standard sets no interval, so your risk assessment and policy decide. Every 12 months and after significant change is a defensible baseline. Whatever you write in your policy is what the auditor will check you against.

Does the tester need a particular accreditation?

ISO 27001 names no tester scheme such as CREST or CHECK. The ISO/IEC 27002 guidance asks for competent, authorised people, and an auditor will look for independence from the systems tested. Check your customer contracts, as some set their own tester requirements.

Will our auditor want the full penetration test report?

Not always. Auditors need to see that the test happened, covered the right scope and that findings were dealt with. The executive summary, scope, control map and retest letter usually show that, and the technical detail can be shown on screen if asked for.

Should the pen test happen before the Stage 2 audit?

Ideally, yes, with enough time to fix and retest. A test after your risk assessment but before Stage 2 lets you show findings flowing into risk treatment and corrective action, which is exactly what the auditor samples.

What was A.12.6.1 in ISO 27001:2013?

A.12.6.1, management of technical vulnerabilities, is now control 8.8 in ISO 27001:2022, and system security testing (A.14.2.8) is now part of 8.29. The transition deadline was 31 October 2025, so policies that still quote 2013 numbers should be updated.

Free consultation

Talk to an assessor

We aim to reply within one working day, and send a fixed quote once your scope is confirmed.

  • PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
  • IASME-licensed Cyber Essentials certification body
  • Clients across the UK, US, Europe, Middle East and Asia since 2012

“The Cyber Security Services were delivered on time and price was competitive.”

Beverley McGowan, Director, Specialists Hub. Read the full testimonial

By sending this form you agree to us contacting you about your enquiry. See our privacy policy.

We aim to reply within one working day. The first consultation is free.