Your Stage 2 audit is on the calendar. Your ISMS documentation is in good shape, the Statement of Applicability has been signed off, and your risk register finally makes sense beyond the security team. However, one gap remains: technical evidence that the controls you’ve documented work in practice.
A penetration test can provide that evidence. However, the firm you choose will determine whether the report supports your audit or creates more questions. Auditors often challenge reports that look like scanner exports or fail to connect findings to your Statement of Applicability. A weak report can lead to a nonconformity, a revised scope, or a last-minute retest just days before your assessment.
In this guide, we cover both halves of the problem. We start with the criteria that separate an audit ready test from a generic one, and then apply those criteria to ten penetration testing companies that can help you achieve ISO 27001 compliance.
What ISO 27001 asks for
ISO 27001 doesn’t use the phrase “penetration test” in any clause or control. That can mislead compliance teams into treating testing as optional. Certification auditors tend to look at the standard differently.
The 2022 revision brought technical requirements into a more focused set of Annex A controls. Two controls carry most of the weight.
A.8.8 covers the management of technical vulnerabilities. You need to gather information about weaknesses that affect your systems, assess your exposure, and take appropriate action. A scan shows that you’ve looked for issues. A penetration test shows that you’ve investigated them and confirmed which ones create a genuine risk.
A.8.29 covers security testing during development and acceptance. It combines two controls from the 2013 edition (A.14.2.8 and A.14.2.9) into one clearer requirement. Rather than treating testing as a one-off task before release, you need to build it into the development lifecycle. As a result, dynamic application security testing and security checks inside the development lifecycle sit alongside your annual engagement.
Two other controls may also apply. A.8.28 covers secure coding, while A.5.7 covers threat intelligence. Whether they fall within your scope depends on what you build and who you serve.
You also need to consider the clause-level requirements that buyers often overlook. Clauses 6.1 and 8.2 cover risk assessment, Clause 8.3 covers risk treatment, Clause 9.1 covers monitoring and measurement, and Clause 9.3 covers management review. A strong penetration test supports all four. It works best when it starts from the same risk picture as your ISMS, which makes threat modeling the systems in scope a practical first step rather than an optional extra.
Your scope should follow your Statement of Applicability and ISMS boundary, not your organisational chart or a generic asset inventory. Get this wrong and you may pay to test systems outside the certification scope while leaving an in-scope system untouched. Understanding the different kinds of test you can commission helps you match the engagement to that boundary and avoid wasting money in either direction.
None of this replaces the management system itself. If you’re still putting yours together, how an ISMS is built and certified explains the process, while the wider ISO 27000 family of standards places ISO 27001 in context.
How to choose an ISO 27001 penetration testing partner
Start with accreditation that your auditor will recognise. CREST company accreditation carries weight, and accredited firms are expected to align with ISO 27001 and ISO 9001, which gives you a useful early signal. CHECK matters for UK public-sector work. At an individual level, look for credentials such as OSCP among the people who’ll actually work on your engagement.
Next, ask how much of the engagement involves manual testing. Automated scanners can find many known issues, but scanner output alone rarely provides strong evidence for A.8.8. In addition, the risks automated tooling misses often appear in business logic and access control areas where the consequences can be serious. That’s why manual testing matters.
A provider should also explain its methodology clearly. If they can’t walk you through the phases a test moves through or explain what access it needs, it may struggle to communicate its findings later. When you discuss access, remember that white box testing usually provides stronger evidence than a purely black-box assessment. Your auditor cares more about coverage than how convincingly the tester played an outsider.
Coverage must match your ISMS boundary. External perimeter testing gets booked most often, but certified scopes rarely end there. Applications, APIs, cloud configurations, and internal networks commonly sit inside the boundary, so testing from inside the network forms part of many serious engagements.
Finally, look for commercial clarity. When your audit date can’t move, a fixed scope agreed during a proper scoping call gives you more certainty than an open-ended day rate. What a test typically costs depends heavily on scope. You should also understand how PTaaS pricing models compare when you’re comparing a platform subscription with a one-off engagement.
However, one criterion sits above the rest, and buyers often overlook it.
The independence question most buyers get wrong
Certification bodies operate under ISO/IEC 17021-1. Clause 5.2.5 prevents a certification body, and any entity under its organisational control, from providing management-system consultancy. Clause 5.2.7 goes further: when a client receives consultancy from a body related to the certification body, that certification body must wait at least two years before certifying the management system.
Now compare that rule with your supplier list. If one corporate group builds your ISMS, runs your penetration test, and later certifies you, the impartiality issue won’t remain the provider’s problem. It may become yours during the audit.
The distinction matters. A penetration test counts as technical assurance rather than management-system consultancy, so it doesn’t automatically trigger the restriction. The risk becomes more relevant when a bundled package combines penetration testing with ISMS implementation from a group that also operates an accredited certification arm.
You can clarify the position with two questions. First, ask whether the vendor’s group owns or operates an accredited certification body. Then ask whether using that body later would create a waiting period under Clause 5.2.7.
The same principle applies, in a simpler form, to internal teams. Your engineers know your systems better than an external provider ever will. However, an auditor may give their findings less weight, and whether the test has to come from outside explains the trade-off in more detail.
With these criteria in place, you can compare the providers below on a consistent basis.
The 10 best penetration testing companies for ISO 27001 compliance in 2026
To begin, the table gives you the shape of the market at a glance.
| Provider | Headquartered | Founded | Reviews |
|---|---|---|---|
| CYBRI | New York, USA | 2017 | G2, Clutch |
| Dionach | Oxford, UK | 1999 | |
| Integrity360 | Dublin, Ireland | 2005 | |
| Prism Infosec | Cheltenham, UK | 2006 | |
| CyberCX | Melbourne, Australia | 2019 | CloudTango |
| HALOCK Security Labs | Illinois, USA | 1996 | |
| Truvantis | California, USA | 2010 | |
| Blaze Information Security | Berlin, Germany | 2016 | Clutch |
| Cure53 | Berlin, German | 2016 | |
| Pentest Limited | Manchester, UK | 2001 |
1. CYBRI
CYBRI delivers penetration testing from New York, combining senior manual testers with automated scanning and a PTaaS platform. Their coverage includes web applications, mobile apps, APIs, cloud environments, networks, infrastructure, LLMs, and red teaming.
Their platform adds practical value for compliance teams. Blue Box shows findings in real time, so your team can begin remediation before the final report arrives. In addition, CYBRI works alongside your testers during remediation to reduce the time between discovery and closure. Their scanner, WraithScan adds automated DAST, external attack-surface monitoring, cloud-configuration analysis, and CI/CD pipeline alerts. Together, these capabilities support the ongoing evidence expected under A.8.8 and the lifecycle approach described in A.8.29.
CYBRI supports SOC 2, ISO 27001, PCI DSS, HIPAA, and GDPR. Their ISO 27001 penetration testing services are scoped around your certification boundary rather than a generic asset list.
2. Dionach
Dionach has operated as an independent UK consultancy for years, delivering globally through separate specialist teams for penetration testing, audit and consultancy, and incident response. The firm holds CREST and NCSC CHECK accreditation, works as a PCI QSA, and carries ISO 27001 certification of its own.
3. Integrity360
Integrity360 ranks among Europe’s larger independent security services groups, running CREST certified testing alongside a substantial ISO 27001 consulting practice that supports organizations from roadmap through certification.
4. Prism Infosec
Prism Infosec has worked as an independent UK consultancy since 2006, covering penetration testing, red teaming and governance work. The firm holds CREST and CHECK credentials and has delivered assessments across healthcare, finance and the UK public sector, including work for NHS bodies.
5. CyberCX
CyberCX operates as the largest independent cyber security firm across Australia and New Zealand, with a UK presence as wel. The offensive team runs a very high annual volume of penetration tests, and the group maintains a dedicated ISO 27001 certification, compliance and audit practice next to that testing capability.
6. HALOCK Security Labs
HALOCK has run penetration testing since 1998 and worked as a PCI QSA since 2006, implementing ISO 27001 programs since 2009 from a base in the US Midwest. Its people served as principal authors of the CIS Risk Assessment Method and helped establish Duty of Care Risk Analysis.
7. Truvantis
Truvantis combines penetration testing with compliance program work across ISO 27001, PCI DSS and SOC 2, operating as a PCI QSA from the US. Testing sits alongside virtual CISO services and ongoing security program operation, so engagements can run on a managed compliance calendar instead of arriving as isolated events.
8. Blaze Information Security
Blaze started in 2016 and now works from offices in Germany, Portugal and Brazil, holding CREST certification and taking a manual first approach. The firm has served more than 200 organizations across 25 countries, and it publishes detailed guidance on ISO 27001 testing, which tells you the compliance context sits inside its core practice rather than at the edge of it.
9. Cure53
Cure53 has operated from Berlin since 2007, building a reputation for rigorous application, cryptography and infrastructure audits. The firm offers black box and white box testing plus code review, and it publishes reports whenever clients agree to release them, which gives you an unusually direct look at the work before you commit.
10. Pentest Limited
Pentest Limited works from the UK with CREST accredited consultants, and it writes reports for two audiences deliberately: your internal security team and your certification body. Findings arrive mapped to Annex A controls, with severity ratings aligned to your risk criteria as standard rather than as a paid extra.
Matching a provider to your certification stage
If you’re preparing for Stage 1 and Stage 2 for the first time, prioritize a provider who’ll help define scope against your Statement of Applicability. First timers overspend on testing that falls outside the certified boundary far more often than they underspend.
If Stage 2 has a fixed date and it’s coming up fast, prioritize fixed scope pricing, a committed delivery window, and a retest included in the quote rather than priced later. Ambiguity costs time you don’t have.
Between surveillance audits, the priority shifts toward continuity. Your certification body will evaluate whether controls operated effectively across the whole period and not just on audit day, so evidence spread through the year beats a single artifact from month two.
If you’re approaching a three year recertification, look for a provider who can show change over time. Assessors at that stage want to see a program maturing rather than a snapshot repeating itself.
Certifying a multi entity or multi region scope pushes geographic coverage and reporting consistency to the top of the list. Three firms producing three report formats creates work for your compliance team that nobody budgeted for.
Product led companies where the application is the scope should weight application depth and architecture review above broad infrastructure sweeps.
Timing the test around your audit calendar
Work backwards from your audit date. You should allow time for the test itself, the report, remediation, and the retest. Six to ten weeks of runway makes a reasonable planning assumption for a moderate scope, though your own numbers will depend on how quickly your engineering team can turn around fixes.
Retest before the audit rather than after it. A closed critical finding gives your assessor something to tick. An open one with a remediation plan attached gives them something to question.
Annual testing satisfies the baseline expectation, but it leaves most of the year without technical evidence behind it. Testing continuously instead of once a year keeps gaining ground with assessors who look at surveillance periods rather than single dates. Even if you stay annual, setting a testing cadence you can sustain beats an ambitious schedule that slips.
Significant change resets the clock regardless of your calendar. A major release, an architecture change, a new cloud region, or an acquisition all warrant testing outside the annual cycle.
Once the timing works, procurement becomes the last hurdle.
Questions to ask before you sign
The questions below separate providers who’ve sat through an ISO audit from providers who’ve only read about one. Ask them on the scoping call rather than over email, because the hesitation tells you as much as the answer does.
- Will findings arrive mapped to Annex A 2022 control numbers as standard, and can you see a redacted sample report?
- Who performs the test? Ask for the credentials of the specific people assigned to your engagement.
- Does a retest come included, and does it produce a separate document your auditor can review without wading through pre remediation findings?
- Does the provider’s group own or operate an accredited certification body, and would engaging that body later create an impartiality issue for you?
- How does the firm scope against a Statement of Applicability rather than an asset list?
A couple of things to be aware of in terms of the questions above include:
- Refusing to share any sample report may suggest the report isn’t the strong part of the offering.
- Scoping done purely by web form with no conversation usually produces a scope that misses something important.
- Pricing quoted before scope gets understood tends to change later.
In addition to asking the questions above, getting your team ready before kickoff prevents the first two days of a test disappearing into access issues, and handing the work to an external team involves more coordination than most first time buyers expect.
Frequently asked questions
Does ISO 27001 actually require a penetration test?
On paper, no. The standard never mentions so. In practice, A.8.8 and A.8.29 make a test the evidence certification auditors expect, and organizations with internet facing systems rarely clear Stage 2 without one.
How often does ISO 27001 expect testing to happen?
The standard sets no fixed interval. Annual testing aligned to your surveillance audit cycle has become the working norm, with additional testing after significant change to systems inside your scope.
Can our internal team run the test?
They can contribute, and their findings still count toward vulnerability management evidence. Assessors weigh independent testing more heavily, though.
Is a vulnerability scan ever enough on its own?
For low risk internal systems with limited exposure, sometimes. For anything internet facing or handling sensitive data, assessors generally want validated findings rather than raw scanner output.
Does the test need to cover our cloud provider’s infrastructure?
No. Your provider’s underlying infrastructure sits outside your ISMS boundary and inside theirs. Your configuration of their services sits squarely inside yours, and that’s what gets tested.
What if the test finds something critical right before the audit?
Fix it and retest. A critical finding discovered, remediated and verified inside your own ISMS process demonstrates the system working exactly as designed. Concealing it does the opposite.
Making your shortlist
The provider you want is the one whose report survives contact with your auditor. Brand recognition and headline price both matter less than that.
Several firms on this list would do well by you. The deciding factors usually turn out to be practical ones: whether their coverage matches your ISMS boundary, whether they work in the regions where your systems actually live, and whether they can deliver before your audit date without quietly trimming the scope. Work through the criteria in the first half of this guide, ask the procurement questions on your scoping calls, and the shortlist tends to sort itself out quickly.
If you’d like to talk through your scope against your Statement of Applicability before committing to anyone, that conversation costs nothing and often saves a few weeks.
