ISO 27001 Penetration Testing

Manual penetration testing that gives your information security management system practical evidence for technical vulnerability management and security testing.

Get a Pentest Quote Book a Scoping Call

Accreditations and memberships

Why ISO 27001 Teams Come to Us

What brings an ISO 27001 team to a penetration test

ISO 27001 doesn't mandate penetration testing by name, so the request usually comes from an auditor, a risk assessment or a customer. These are the most common triggers.

A first certification audit

Before your first audit, an independent test gives you evidence for technical vulnerability management and a list of fixes to complete before the auditor arrives.

Surveillance audits and recertification

Certification runs on annual surveillance audits and a three-year recertification cycle. A recent test helps to show that your technical controls keep working between audits.

A customer or tender asks for both

Procurement questionnaires often ask for your ISO 27001 certificate and for evidence of recent independent testing. See our guide to penetration testing for customer security reviews.

A significant change

A new product, a major release, a migration or a change to your ISMS scope changes your risk picture, and your risk assessment may call for a fresh test before the next audit.

Annex A Controls

How a penetration test supports your ISMS

Which evidence you use for each control is your decision, recorded in your risk treatment, and your certification body decides whether it is enough. These are the 2022 Annex A controls a penetration test most often supports. See all of our penetration testing for compliance guidance for other frameworks.

A.8.8 Management of technical vulnerabilities

Expects you to obtain information about technical vulnerabilities, evaluate your exposure and take appropriate measures. A penetration test finds the weaknesses that scanning misses and shows which of them an attacker can exploit. Pair it with vulnerability scanning for regular coverage between tests.

A.8.29 Security testing in development and acceptance

Applies where you build or buy software, and expects security testing to be defined and carried out within the development life cycle. Testing a release before it goes live is one form of acceptance testing. See our web application and API penetration testing services.

A.8.20 to A.8.22 Network controls

Cover network security, the security of network services and the segregation of networks. External and internal testing check whether your firewall rules, exposed services and network segmentation work as designed.

A.5.35 Independent review of information security

Expects the way you manage information security, and how it is implemented, to be reviewed independently at planned intervals and when significant changes occur. An external test is one independent source of evidence for your technical controls. It doesn't replace your internal audit or your certification body's audit.

How It Works

From first contact to final report

You don't need a finished scope document before reaching out.

Tell us your ISMS scope

Submit a quote request or book a scoping call with your ISMS scope statement, or a description of the products, networks and sites it covers, and your audit date. We reply within one business day to confirm the scope, usually with a short questionnaire or a call.

Receive a written, fixed-price proposal

The proposal confirms the scope, methodology, timing, rules of engagement and a fixed price. You accept when you're ready, and there's no obligation at any stage.

Testing timed around your audit

Count back from your audit date and leave room for the report, remediation and retesting, not just the days of testing. Your consultant is your direct contact throughout, and critical findings are escalated the same day they're discovered.

Report delivery and debrief

Technical and executive reports are delivered within 2 business days of testing completion, followed by a debrief call. Retesting of remediated findings is included for remotely delivered web application, API, website and external network testing, and is agreed at scoping for internal testing.

Typical Scope and Price

A worked example from our published prices

An organisation whose ISMS scope covers one standard web application and a small internet-facing network. Prices are indicative, exclude VAT and are confirmed as a fixed price after scoping. Where your corporate network is inside the ISMS boundary, internal network testing from £3,600 can be added. See the pricing guide for every service, or use the cost calculator.

Asset in your ISMS scope	Testing	Indicative price
Customer-facing web application, standard complexity	Web application penetration testing	£3,600 to £6,000
Internet-facing network, up to 25 IP addresses	External penetration testing	£2,400 to £3,350

What You Receive

Included in every engagement

Executive and technical reports, and attestation letter
A summary for leadership and your auditor, every finding with evidence, CVSS scoring and remediation guidance, and an attestation letter confirming the scope, testing dates and methodology.
Debrief session
A video call or presentation to walk through findings and remediation priorities with your technical and security teams.
Retesting and platform access
Retesting where included for the service, and findings tracked in the Exploitr platform at no extra cost.

Common Questions

ISO 27001 penetration testing: frequently asked questions

How testing relates to ISO 27001, answered before you request a quote.

Not by name. Controls such as A.8.8 expect you to find and manage technical vulnerabilities, and you decide how to evidence that in your risk treatment. A penetration test is a common choice, and your certification body decides whether the evidence is enough.

If your auditor or certification body has told you what they expect to see, share it with us during scoping and we'll reflect it in the scope and the report.

They do different jobs. A vulnerability scan checks systems against known weaknesses and suits regular, repeatable coverage. A penetration test is manual: a consultant tries to exploit weaknesses, chain them together and find the logic flaws that scanners can't.

Many ISMSs use both, with scanning for regular A.8.8 coverage and a periodic test for depth. Our article on vulnerability scanning vs penetration testing explains the differences, and our vulnerability assessment service covers scanning.

The standard sets no frequency, so your risk assessment decides. Many organisations test annually, ahead of their surveillance audit, and we recommend testing again after any significant change, such as a new product, a major release, a migration or a change to your ISMS scope.

If you release frequently, our Penetration Testing as a Service (PTaaS) offering provides ongoing testing aligned with your release cadence. Our guide to how often to get a penetration test covers cadence by situation.

The scope follows your ISMS boundary and your risk assessment. Send us your scope statement, the systems inside it and anything your auditor has asked to see, and we'll map them to tests: external for internet-facing infrastructure, internal for the corporate network, and web application and API testing for the products you build or run.

If the boundary is large, we'll talk through where testing adds the most evidence during scoping. Exploitr provides the testing and the evidence. We don't provide ISO 27001 consultancy or certification, so your certification body makes the final call on what it needs.

Ready to scope your ISO 27001 penetration test?

Tell us about your ISMS scope and your audit date, and we'll reply within one business day to confirm the scope, then send a fixed-price proposal. No obligation at any stage.

Request a Quote