How to Choose Penetration Testing Companies
How to compare penetration testing companies: the accreditations that mean something, a weighted scorecard, RFP questions and the NIS2 and DORA rules that bind.
Most guides to penetration testing companies are ranked lists written by one of the companies on them. This one is a buying method: what to put in scope, which accreditations carry weight, the questions that separate a real test from an automated scan with a PDF, and the two EU regulations that turn "pick a good supplier" into a documented legal duty. Use it to build a shortlist you can defend to an auditor, not just to a budget holder.
What are you actually buying?
Scope before shortlist. A supplier is only "the best" relative to what you asked for, and the wrong scope is the most expensive mistake in the process — more expensive than paying too much per day.
Decide four things in writing first:
- The target. External perimeter, internal network, a specific web application and its APIs, a mobile app, a cloud tenancy, firmware, or an OT/SCADA environment. Each needs different testers.
- The information model. How much you tell the testers. This is the black box, grey box and white box testing decision, and it changes both cost and what the test can find.
- The objective. Compliance evidence, pre-release assurance on a new product, validation that last year's fixes held, or a genuine "could someone reach the customer database" question.
- The constraint. Production or staging, testing windows, whether denial-of-service and social engineering are in or out, and who can stop the test.
NIST's SP 800-115 is blunt about why this matters: penetration testing "is labor-intensive and requires great expertise to minimize the risk to targeted systems", and systems may be damaged or rendered inoperable during a test. A supplier who does not press you hard on scope and rules of engagement before quoting is telling you something about how they run engagements.
What do penetration testing accreditations actually mean?
Two different things get called "certified", and buyers conflate them constantly.
Company accreditation assesses the firm. CREST publishes what its member accreditation examines: "their quality processes and procedures; compliance with standards compliance (e.g. ISO27001, ISO9001); professional indemnity insurance; contract management; informational security processes; complaint handing and conflict of interest policies", along with "the policies, processes and competencies that member companies have in place for delivery of their services". CREST members also "abide by our enforceable Codes of Conduct and Ethics and our Complaints and Resolution Measures".
Read that list again, because it tells you what company accreditation is for. It is not evidence that the individual walking into your network is brilliant. It is evidence that there is insurance behind the engagement, a contract process, a documented way to handle your data, and somewhere to complain that is not the salesperson's inbox.
Individual certification assesses the tester. CREST describes its certifications as candidates "demonstrating their capabilities in time-boxed written and lab-based examinations", and states that member companies delivering accredited services "must used suitably competent and qualified individuals who are registered and issued with CREST IDs". Lab-based is the operative word: an exam where you have to actually compromise something tells you more than a multiple-choice paper.
So ask for both, and ask for them specifically: the firm's accreditation for the service you are buying, and the named certifications of the people who will be assigned. "We are CREST certified" as a website badge is not an answer to either question.
What does NIS2 or DORA require you to check?
If you are in scope of either, supplier selection is not purely commercial.
NIS2, Article 21(2)(f), lists policies and procedures to assess the effectiveness of cybersecurity risk-management measures among its minimum measures, and Article 21(2)(e) covers security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure. Testing is how most entities evidence both.
DORA is far more prescriptive, and its tester criteria are the most useful buying checklist published anywhere — including for organisations DORA does not cover. Article 27(1) states financial entities shall only use testers for threat-led penetration testing that:
| DORA Article 27(1) criterion | What to ask the supplier for |
|---|---|
| (a) are of the highest suitability and reputability | Named references in your sector, and any past engagement terminated early |
| (b) possess technical and organisational capabilities and specific expertise in threat intelligence, penetration testing and red team testing | CVs and certifications of the assigned team, plus who supplies the threat intelligence |
| (c) are certified by an accreditation body in a Member State, or adhere to formal codes of conduct or ethical frameworks | The accreditation certificate and its scope, or the named code of conduct |
| (d) provide independent assurance, or an audit report, on sound management of the risks of carrying out the test, including protection of your confidential information | Their most recent independent assurance report, and how findings data is stored and destroyed |
| (e) are duly and fully covered by relevant professional indemnity insurance, including against risks of misconduct and negligence | The certificate of insurance, with the limit and whether misconduct and negligence are covered |
Three related duties set the rhythm. Article 26(1) requires identified financial entities to carry out advanced testing by means of TLPT at least every three years, and Article 26(2) requires each test to cover several or all critical or important functions and to be performed on live production systems. Article 24(6) requires appropriate tests at least yearly on all ICT systems and applications supporting critical or important functions. Article 24(4) requires tests to be undertaken by independent parties, internal or external, with conflicts of interest avoided throughout design and execution.
That last one deserves emphasis outside finance too: if the firm that built or manages the system also tests it, you have bought an opinion, not an assessment.
How should you score a shortlist?
Use a weighted scorecard and fill it in before the pricing conversation. Weights we use for a typical buyer-side engagement:
| Criterion | Weight | What a strong answer looks like |
|---|---|---|
| Methodology, written down | 20% | A named standard applied to your scope, not a generic phase diagram |
| Assigned team's credentials | 20% | Named testers, lab-based certifications, relevant sector work |
| Report quality | 20% | A full redacted sample report, not a two-page extract |
| Scoping rigour | 15% | They challenged your scope and wrote rules of engagement |
| Retest and remediation support | 10% | Retest included, with a stated window |
| Independence and insurance | 10% | No conflict with your build/managed-service suppliers; insurance evidenced |
| Price | 5% | Comparable on a per-tester-day basis |
Price at 5% is deliberate. Penetration test quotes vary by more than the work does, because effort is hidden inside a day rate. Normalise every quote to tester-days for the same scope and the cheap quote usually turns out to be fewer days, less senior people, or a vulnerability scan with manual triage on top.
What should a penetration testing RFP ask?
Send this with the scope, and score the answers, not the brochure:
- Which methodology will you apply to this scope, and which phases will be manual? Compare against the Penetration Testing Execution Standard and OSSTMM so you can tell a methodology from a marketing diagram.
- Who exactly is assigned, what are their certifications, and are they employees or subcontractors?
- Provide a full redacted sample report for an engagement of this type.
- How do you distinguish exploited findings from theoretical ones, and how do you handle false positives?
- What is your severity rating method, and does it account for our business context or only CVSS?
- What are your rules of engagement, escalation path and stop conditions?
- Is a retest included after remediation, and for how long?
- Where is our data stored during and after the test, and when is it destroyed?
Question 3 does more work than the rest combined. Read the sample report as the person who will have to act on it: does each finding have reproduction steps, evidence, business impact and a specific fix, or does it have a CVSS score and a link to a vendor advisory? A report you cannot hand to an engineer is a report you will pay someone else to interpret.
Red team or penetration test?
They are not interchangeable, and suppliers will sell you either.
| Penetration test | Red team engagement | |
|---|---|---|
| Question answered | What can be exploited in this scope? | Would we detect and stop a capable adversary? |
| Scope | Defined targets, broad coverage | Narrow objective, any path to it |
| Detection | Usually not a goal; the blue team often knows | Central; the blue team usually does not know |
| Prerequisite | None | Basic hygiene already fixed, and a functioning detection capability |
| Threat intelligence | Optional | Required, and usually externally supplied |
Buy a red team engagement only when you already patch reliably and have someone watching alerts. Otherwise you pay senior people to prove what a cheaper test would have told you. If adversary emulation is genuinely what you need, the scenarios should be built on a public library of adversary behaviour — see MITRE ATT&CK for red teams.
ResilientX offers both, including threat-led testing and objective-based red teaming, and applies PTES, OWASP Top 10 and OSSTMM across internal and external networks, web applications and APIs, legacy software, firmware and SCADA. You can book an expert-led penetration test to scope the right one.
What does the engagement look like once you have chosen?
NIST SP 800-115 section 5.2.1 sets out four phases — planning, discovery, attack and reporting. In the planning phase, "rules are identified, management approval is finalized and documented, and testing goals are set", and "no actual testing occurs in this phase". Reporting runs alongside the other three rather than arriving at the end.
Two practical consequences for a buyer. First, if a supplier's plan has no distinct planning phase with written approval, the risk of an out-of-scope incident sits with you. Second, expect interim communication: SP 800-115 describes periodic reports to administrators and management during discovery and attack, so a supplier who disappears for three weeks and returns with a PDF is not following the methodology they cited. Where both internal and external testing is in scope, SP 800-115 notes external testing usually runs first.
Frequently asked questions
Does a company need to be CREST accredited to do good work?
No, and treating it as a hard filter will exclude strong specialists. What accreditation gives you is assurance about the wrapper — insurance, contract handling, data handling, complaints — which CREST states its accreditation examines. Where you have no other way to verify a supplier, that wrapper is worth a lot. Where you can check references and read a sample report, judge the work directly.
How many testers and days should a test take?
Ask each supplier to quote tester-days for an identical scope and compare those, not totals. There is no published universal figure, and any supplier quoting days before understanding your scope is guessing. Large variance between comparable quotes usually signals a different depth of work rather than a better price.
Should we use the same company every year?
Continuity helps with retests and context; rotation reduces blind spots, since testers have habits. A common compromise is to keep one supplier for recurring scoped testing and bring in a second for periodic independent validation of the same estate.
Can our managed service provider test the systems it runs?
Not if you need the result to be independent. DORA Article 24(4) requires tests by independent parties with conflicts of interest avoided throughout design and execution. Even outside finance, the same logic applies: the party that configured a control is the worst-placed party to judge it.
What is threat-led penetration testing?
It is DORA's term for advanced testing built on real threat intelligence about actors likely to target you. Article 26(1) requires identified financial entities to do it at least every three years, covering several or all critical or important functions, on live production systems, and Article 27 sets the tester criteria in the table above.
The short version
Write the scope first. Ask for company accreditation and named individual certifications separately. Use DORA Article 27's five criteria as your evidence list whether or not DORA binds you. Score methodology, team and report quality at 60% combined and price at 5%. Read a full sample report before you read a proposal.
When you are ready to scope one, book an expert-led penetration test with ResilientX, or work through the testing methodologies in the ResilientX Learning Center first.