Buyer's guide

Choosing a pentest provider: how to recognise a good one

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

A good penetration testing provider agrees the scope with you before quoting, tests manually rather than just running a scanner, backs every finding with reproducible evidence, offers a retest and insists on written authorisation before any testing starts. Certifications and standards help you compare providers, but they do not replace a sample report and straight answers in the first call. This guide gives you a checklist, the warning signs to watch for, ten questions for the first conversation and what a complete proposal should contain.

What a penetration test has to deliver

Before comparing providers, be clear about what you are buying. "Pentest" is used for very different services, from an automated scan with a logo on the cover page to an in-depth manual review of an application.

An automated vulnerability scan looks for known patterns: outdated software, missing security headers, exposed services. It is fast and useful, but what you get is a list of possible weaknesses, often with false positives. A penetration test goes further. It checks whether weaknesses can really be exploited, chains individual findings into attack paths and looks precisely where scanners are blind: in your application logic, in roles and permissions, and in flows such as sign-up, password reset or checkout. No scanner will notice that one customer can download another customer's invoices, because technically every request looks valid.

We explain the difference in detail, and when a vulnerability assessment is enough to start with, in Vulnerability Assessment: what it is and when you need one. The phases of a test, how long it takes and what drives the cost are covered in Penetration Testing: Process, Duration and What It Costs. This guide starts one step earlier, with the question of who should get the job.

Selection criteria as a checklist

These ten criteria separate dependable providers from those that mainly produce reports. No single criterion settles it. Taken together, they give you a clear picture.

1. There is a real scoping conversation

A good provider wants to know what is to be tested before quoting: which applications, APIs and environments, which roles, which data is especially sensitive and what must not be touched. They ask why you want the test, for example a customer requirement, a release or an audit finding, because the reason shapes where the test should focus. If none of these questions come up, the quote can only be an estimate.

2. Manual testing is the core, not an add-on

Every test uses tools. What matters is how much of the work is done by a person. Ask directly which parts are automated and which are tested manually, especially permissions, business logic and chaining of findings. An honest answer is a good sign, even if it is not "everything is manual".

3. Every finding comes with evidence

A finding should be written up so that your developers can reproduce it: the affected component, steps to reproduce, the observed impact, a severity rating and a concrete fix. Without evidence a finding is just a claim, and your team ends up spending time separating false alarms from real issues. Severity is usually rated with a transparent scheme such as the Common Vulnerability Scoring System (CVSS), complemented by an assessment in the context of your system.

4. A retest is planned

Only a retest shows that a fix actually works. Clarify upfront whether retesting fixed findings is included, within what time frame, and whether the result is documented in the report. If you share the report with customers or auditors, the documented state after remediation often matters more than the original list.

5. The report works for two audiences

A good report has an executive summary that makes sense without technical background, and a technical section your developers can work from. It also states the scope tested, the testing window, the methodology, what was explicitly out of scope and any limitations. Ask to see an anonymised sample report. It tells you more about a provider's quality than any service description.

6. Methodology and standards are named

A provider should be able to explain how they work. Widely used public references are the OWASP Web Security Testing Guide (WSTG) for web applications, currently at stable version 4.2, and NIST SP 800-115, a guide to technical security testing. In Germany, the federal security agency BSI has published a practical guide to IS penetration testing that is explicitly aimed at organisations commissioning a test as well. What counts is not that a standard appears in the proposal, but that the provider can show how they apply it to your project.

7. Confidentiality and data handling are agreed

A pentest provider sees vulnerabilities before they are fixed and, depending on scope, handles credentials and personal data. Before testing starts, agree on a non-disclosure agreement, how credentials are handed over and deleted afterwards, where test data and reports are stored, who on the team has access and whether subcontractors are involved. If personal data is processed, a data processing agreement may also be required.

8. Liability and insurance are addressed

Even a careful test can cause disruption, for example when an application reacts badly to unusual input. Ask whether the provider carries liability insurance that covers their testing work, how liability is handled in the contract, and how they limit risk to live operations, for instance by testing against a staging environment or in agreed time windows.

9. Experience with your technology stack

A single-page app with an API, a multi-tenant SaaS platform, a mobile app, a cloud environment or an AI agent with tool access each require specific knowledge. Ask what comparable systems the team has worked on, without asking for client names, and who exactly will run your test. "We test everything" says less than a concrete description of typical findings in systems like yours.

10. Written authorisation before the first test

A serious provider only starts once scope, testing window, test accounts, contacts and boundaries are agreed in writing and the system owner has authorised the test. This protects both sides: German criminal law, for example, penalises unauthorised access to specially protected data (Section 202a StGB). Check whether third-party systems are involved, such as your hosting or cloud provider. Major cloud providers publish their own rules for security testing on their platforms, for example AWS and Microsoft, and these rule out denial-of-service testing among other things. A good provider raises this without being asked. This section is a factual overview, not legal advice.

The checklist

Putting certifications in context

Certifications are a verifiable signal, and it helps to know what each one actually says.

• Company certification by the BSI. Germany's Federal Office for Information Security certifies IT security service providers on application in several scopes, including "IS penetration testing". The BSI publishes a list of certified providers with validity dates, so you can check a claim yourself.
• Competence of individual testers. The BSI has discontinued its former personal certification for IS penetration testers and now assesses competence through a competence review based on external, practice-oriented certificates. The certificates it accepts give you a useful reference for which credentials are common evidence of hands-on testing skills.
• Management system certificates. A provider's ISO 27001 certificate says something about their own information security management, not about the quality of their penetration tests.

Whether you need a certified provider depends on your situation. If a tender, a customer or an internal policy requires a specific certification, that settles it. If not, assess providers against the criteria above as well, above all the sample report and the answers you get in the first call. For transparency: CyberSec42 provides independent technical security testing and is not a BSI-certified body.

Red flags

10 questions for the first call

Ask every provider the same questions in the same way. That makes the answers easy to compare side by side.

1. What information do you need from us to define the scope?
2. Which parts of the test are automated, and which do you test manually?
3. What does a finding look like in your report? Can you show us an anonymised sample report?
4. Which methodology and standards do you follow, and how will you apply them to our system?
5. Is a retest included, within what time frame, and is the result documented?
6. Who will actually run the test, and what experience do they have with systems like ours?
7. How do you handle credentials, test data and the report, and when are they deleted?
8. How do you limit risk to our live operations, and who do you contact if something goes wrong?
9. If you find a critical vulnerability during testing, do you wait for the report or tell us straight away?
10. What written agreements do you need before you start, and how do we handle third-party systems such as hosting or cloud providers?

What a proposal should contain

A complete proposal makes providers comparable. If any of the following is missing, ask before you compare prices.

To get comparable proposals quickly, prepare a few points in advance: what should be tested, why now, who uses the application and with which roles, whether there is a test environment and when you need the result.

How CyberSec42 can help

We run penetration tests on web applications, APIs, SaaS platforms and AI applications within a scope agreed in writing. It starts with a scoping call in which we work out with you what should be tested and which scope fits your reason for testing. Every finding we report comes with executed proof and a recommended fix. Anything we cannot confirm is discarded rather than used to pad the list. Once you have fixed the issues, we retest the remediated findings. Learn more about penetration testing and, for SaaS companies, SaaS penetration testing.

Frequently asked questions

Further reading

• Penetration Testing: Process, Duration and What It Costs
• Vulnerability Assessment: what it is and when you need one
• NIS2 supply chain requirements: what your customers will now ask of you as a supplier
• Service: penetration testing with verified findings

Sources

• BSI: IS penetration tests (certification of IT security service providers)
• BSI: List of certified IT security service providers for IS audit and IS penetration testing (German)
• BSI: Penetration testers, competence review (German)
• BSI: IS penetration tests and IS web checks
• OWASP: Web Security Testing Guide
• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• FIRST: Common Vulnerability Scoring System
• German Criminal Code, Section 202a (German)
• AWS: Penetration Testing Policy
• Microsoft: Penetration Testing Rules of Engagement