How to choose a penetration testing company: 20 questions, red flags and a report check

To choose a penetration testing company, write down what you need tested, shortlist three to five providers, and put the same 20 questions to each in writing. Then judge them on evidence: the named people who will test, the method they follow, a real sample report, and how they prove a fix. Brand names and badges come last.

A penetration testing company is a firm you pay, with written permission, to find and exploit weaknesses in your software and report them so your team can fix them. The label covers very different businesses, from two senior testers who work by hand to a reseller of scanner output with a cover page. This guide shows you how to tell them apart in about two weeks. If the basics are new, start with what VAPT is or the penetration test entry in the Knowledge Hub.

What are you actually buying when you hire a pentest company?

You are buying a snapshot, the judgement of skilled people, and a document. The UK National Cyber Security Centre (NCSC) frames a penetration test as a controlled attempt to break into a system the way a real adversary would, with the same kinds of tools. It adds that even a well-scoped test is a point-in-time result: it gives confidence about known issues in the tested components on the day it ran, and says nothing about next month's release.

So three things decide whether a provider is good: the people who test, the method they follow and the evidence they hand back. The company name is a shortcut for those three, and often a poor one. A large firm can staff your job with its newest tester. A small firm can put its best person on it.

Why the choice carries real weight

Flaws in software are a leading way in. The Verizon 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way attackers get in. The IBM Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, a 12% rise and a record high. A test that misses the flaws costs the same fee as one that finds them, and it leaves you holding a clean-looking report.

Access control is where weak tests miss most. In the OWASP Top 10:2025 data for Broken Access Control (rank one), 100% of the applications tested had some form of it, with 40 weakness types (CWEs) mapped to the category and 1,839,701 occurrences recorded. Knowing who may see what is business knowledge, so a provider has to be able to test it with several accounts. That is why several questions below probe broken access control.

What should you write down before you shortlist anyone?

Write a one-page brief first. "We need a pentest" gets a generic quote and a generic report, and quotes built on different assumptions cannot be compared. Cover six points.

1. The reason. A customer questionnaire, an audit (SOC 2, ISO 27001, PCI DSS), a regulator, a launch, or your own wish to know. The reason sets the report format and who must sign it.
2. The target. Web apps, APIs, mobile apps, environments and third-party integrations. Say whether testing runs on production or staging.
3. The accounts. The roles your app has (customer, admin, partner, support) and whether tenants must stay apart. This is the biggest cause of quote differences.
4. The depth. A URL only (black-box), signed-in accounts and documents (grey-box), or source code too (white-box). See black, grey and white box compared.
5. The deadline. An audit window or launch date changes who can take the job.
6. Constraints. Data residency, tooling that must stay in your network, quiet hours, or a rule that the firm is accredited or empanelled.

This becomes your pentest scope. It also tells you whether you need one test or a recurring programme; the trade-offs are in continuous penetration testing. For cost drivers once you have a scope, read penetration testing cost.

What kinds of penetration testing company are there?

Most providers fall into six groups, and most real firms blend two or three. Use the table as a map, because real firms straddle categories.

Six provider types and what to watch for

A bug bounty programme is a different product from a pentest. It rewards finders for issues, usually with no guaranteed depth and no written attestation. Many teams run both, in that order.

How do you choose a penetration testing company, step by step?

Six steps over about two weeks are enough. The order keeps the decision about evidence and leaves you a record of why you chose.

The six steps

1. Days 1 to 2: write the brief. Use the six points above and send the same brief to every provider.
2. Days 2 to 4: shortlist three to five. Ask peers, check who has worked on your stack, and read their public writing. Drop anyone who will not say who does the work.
3. Days 4 to 7: send the 20 questions in writing. Written answers compare easily and form a record.
4. Days 7 to 9: get a redacted sample report and a call with the lead tester. Do not accept a call with sales alone.
5. Days 9 to 12: score on one sheet. People, method, evidence, retest and fit. Treat the quote as a tie-breaker, not the first filter.
6. Days 12 to 14: settle rules of engagement and sign. Check the contract points covered later.

If time is short, do not skip steps 3 and 4. Teams that rush usually end up with a report they cannot use. If the stakes are high, add a small paid trial on one application before the full contract.

Which 20 questions should you ask a penetration testing company?

Send these as written questions. A strong answer is specific, names a person or a document, and can be checked. A weak answer is a brand statement. Good providers also tell you when a question does not apply.

People (questions 1 to 4)

1. Who will do the testing, and what have they done on a stack like ours? You want named roles and a real description, not "our team of experts". Ask if the person on the sales call is on the job.
2. Are the testers employees or contractors, and where are they based? Contractors are not a problem. Not knowing who they are is.
3. What do you check beyond certificates? Good answers mention practical exams, past findings and published work.
4. How do you vet and supervise testers who handle our data and credentials? Look for background checks, access controls and a process for secrets you hand over.

Method (questions 5 to 10)

5. Which methodology do you follow? Credible answers name published guides: the OWASP Web Security Testing Guide (stable version 4.2) for web apps and NIST SP 800-115 (September 2008) for general technical testing. Ask how they adapt them to your app.
6. What share of the work is manual, and what is tool-driven? The honest answer is "tools for coverage, people for judgement". Be wary of a refusal to say.
7. How do you test authorisation and business logic? Ask whether they use several accounts and check what one account can reach that it should not (cross-account access).
8. Will you test our APIs, and how do you get the definitions? Many apps expose more through the API than the front end shows. See API security testing.
9. How do you test behind our login, multi-factor and single sign-on? If they cannot test behind your login, they are testing the lobby.
10. Can you work white-box or grey-box if we want it, and what changes? A provider locked to one mode will push that mode on you.

Safety and scope (questions 11 to 13)

11. How do you keep testing safe for production? Ask about rate limits, destructive actions, test data and who you call if something breaks.
12. What is in and out of scope in your quote, and what triggers extra work? Hidden exclusions, such as a second role, an API or a retest, are the main reason two quotes differ.
13. Where is our data stored, who can read it and when is it deleted? Include credentials, screenshots and the report.

Evidence and reporting (questions 14 to 17)

14. Can we see a redacted sample report? A refusal is a red flag.
15. How do you show that a finding is real? You want the request, the response, a screenshot where a person can see it, and steps to reproduce. "The scanner flagged it" is not proof.
16. How do you separate severity from confidence? A serious issue you doubt and a minor one you proved are different things. See how to read a finding.
17. Which references do findings carry? Look for CWE and OWASP mappings and a CVSS vector with its reasoning, so engineers can triage.

After the test (questions 18 to 20)

18. How is the retest done, and is it included? The best answer is that they repeat the exact exploit against the fixed code. A fresh scan that stops showing the issue is weaker. See closed-loop retest.
19. What attestation do you give auditors and customers? Ask what it says, whether it names scope and dates, and who signs. See attestation letter.
20. What happens after the report arrives? Look for a debrief call, a way to ask questions while engineers fix, and a clear end date for support.

Do not accept "we will cover that at kickoff" for questions 1, 14, 15 and 18. Those four decide whether the work is trustworthy, readable and provable, and they belong in the proposal.

How do you review a sample penetration test report?

Read the sample as the engineer who must fix the first finding on a Friday afternoon. A good pentest report lets you do that without calling anyone. The PCI Security Standards Council's Penetration Testing Guidance even includes a report evaluation checklist that asks for the dates of the engagement, the analysts' qualifications and evidence of organisational independence. For the full buyer workflow, see how to read a penetration test report.

Ten things to check in the sample

1. An executive summary a manager can use, stating scope, dates and what was not tested.
2. A method section naming the guide followed and the depth (black, grey or white box).
3. A title, affected URL or component, and plain impact for each finding.
4. Reproduction steps someone else could follow, with the real request and response.
5. Evidence you can see: screenshots, logs or code lines, not only tool output.
6. Severity and confidence stated separately, with the reasoning.
7. CWE and OWASP references on each finding.
8. Fix advice specific to your stack. "Validate input" is generic; "add an ownership check in this controller" is useful.
9. A note of what was tried and found safe, so you know what was covered.
10. A retest section or a defined retest format.

Then ask three awkward questions. Is this a real report, lightly redacted, or a built-for-sale example? How many findings needed a person rather than a tool? How long did the test last? A report with forty low-value items and no business-logic finding often came from a tool run with a cover page. Pages of unproven output are where false positives hide.

What are the red flags when hiring a pentest company?

Each of these is a reason to ask more. Get the explanation in writing, and walk away if it is poor.

Warning signs before you sign

A guaranteed result

"We will find critical issues" or "100% pass" cannot be promised. A test reports what exists.

No sample report, or only a marketing one

If a firm will not show you its work in redacted form, you are buying blind.

A fixed quote with no scoping call

Someone who has not asked about roles, APIs and environments has not read your needs.

Findings that read like scanner output

Long lists, generic text, no request and response, and everything marked "critical" are the signs.

Unclear staffing and unclear data handling

Undisclosed subcontracting, no named lead, or no answer on where credentials and reports are stored.

Testing without written permission, or no retest

Authorisation in writing is the minimum. A retest that is billed as a new project, or not offered, means you cannot know the fix worked.

What do CREST, OSCP and CERT-In empanelment actually mean?

Each credential proves one narrow thing, and none proves your application will be tested well. They are useful filters and poor guarantees. The PCI SSC guidance says certifications "may be an indication" of skill, are not required, and that a certificate cannot stand in for real experience.

CREST

CREST is a not-for-profit accreditation and professional standards body for cyber security. It says it serves over 500 member companies worldwide, that all members undergo audit and accreditation, and that all sign enforceable codes of conduct and ethics. So a CREST member company has been audited against a standard. That does not make every test it sells deep. Ask which CREST-certified person works on your job, and check membership in CREST's own marketplace, not on the firm's website.

OSCP

The OSCP is OffSec's hands-on penetration testing certification, taken after the PEN-200 course. OffSec describes a 24-hour proctored exam with three standalone machines graded on initial access and privilege escalation, plus an Active Directory set simulating a breach across three machines. It is respected because it is practical. Its focus is machines and networks, so a web-application-heavy job still needs web and API experience.

CERT-In empanelment

In India, some buyers ask for an auditor empanelled with CERT-In, the national agency for cyber security under the IT Act. Empanelment is a status granted by that agency; it is not a measure of how deep a test goes. Ask the party that requires it to say so in writing, and check the firm against the current official list, not its own web page. The detail is in CERT-In empanelled VAPT.

Independence of the tester

The PCI SSC guidance says the tester must sit outside the line that manages the systems under test. Its example: a company that performs your PCI DSS assessment cannot also run the test if it helped install, maintain or support those systems. That applies directly to PCI DSS work, and it is sound practice elsewhere. See PCI DSS penetration testing requirements.

Credentials compared

What must the contract and scoping call cover?

Read the paperwork before you sign. These are the clauses that decide who is covered when something goes wrong.

Clauses to check

Written authorisation and scope change

The contract and rules of engagement must say what may be tested, from which IP addresses, on which dates, and who can stop the test. They must also say how extra roles, endpoints or environments are priced and approved.

Data, liability and disclosure

Look for storage, encryption, who can see your data, and deletion at the end. Ask for professional indemnity details. Agree who may mention the test and its results.

Urgent findings and incident duties

Require a promise to tell you straight away about a critical issue. India's CERT-In directions of 28 April 2022 require specified cyber incidents to be reported to CERT-In within 6 hours of noticing them, and ICT system logs to be kept for a rolling 180 days. If a provider holds your data, the contract should say how fast it tells you about an incident, so you can meet your own clock.

Deliverables and retest terms

List the report, raw evidence, executive summary and attestation, and the formats your tracker needs. State the number of retests, the window, and whether the retest repeats the exploit.

Should you choose manual, automated or AI-assisted testing?

Ask the provider where the line sits, because both extreme claims are too simple. Tools are good at breadth and repeat runs. People are good at judgement, chaining weaknesses and understanding what your app is for. A vulnerability scan is not a pentest, and a pentest with no tooling is slower than it needs to be.

Ask which parts are tool-driven, which are human-driven, and how false results are kept out of your report. A sound answer is "we try to exploit it, and if we cannot, we say so". That is also our rule: if we did not break it, we do not report it. The wider argument is in exploited, not suspected.

How should the choice fit your team?

A product company with a small engineering team

You need findings developers can act on, with file and line where possible, and a retest you do not have to chase. Ask how white-box access works, whether the work can run inside your network, and whether tests can run on a schedule or in CI/CD so you are not buying one report a year.

A company preparing for an audit

Your auditor's wording matters more than the brand. Ask the auditor what they accept, then ask providers to show a report and attestation in that shape. See SOC 2 penetration testing and ISO 27001 penetration testing.

An agency or MSSP

You need a provider you can put your name beside. Ask about white-label reports and how client data is kept apart. The VAPT checklist covers the work around the test itself.

How does Cyberlop answer these 20 questions?

Hold us to the same list. Here is how we answer the points that most often decide a purchase.

• Depth modes. Cyberlop finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting. In white-box mode it reads your code while testing the running app, so a finding can point to the file and line.
• Proof. It reports what it actually exploited. Each finding carries the request, the response, a screenshot where a person can see it, and the line of code. See what the evidence looks like.
• Ratings. Severity and confidence are kept apart, and findings carry CWE and OWASP references.
• Retest. A fix is proven by re-running the exact exploit against the new code, not by a fresh scan.
• Coverage. It checks business-logic flaws and cross-account access.
• Where it runs. Private scanning can run inside your own network so your code does not leave it.
• Cadence. It can run on a schedule or in CI/CD and gate a build; see how it works.
• Partners. Agencies and MSSPs can run it under their own brand.

Read our honest page as well. A provider that publishes what it cannot do is easier to trust than one that promises a clean result.

What is the final checklist before you sign?

• Every provider got the same written brief and answered the same 20 questions.
• You know who will test and what they have done on a stack like yours.
• You read a sample report and your engineers could fix from it.
• The method names a published guide, with a clear split between tools and people.
• Business logic and cross-account access are in the scope in writing.
• A retest is included and repeats the exploit.
• The attestation is in a form your auditor or customer accepts.
• Authorisation, data, liability and disclosure are settled in the contract.
• Any required credential was checked at the issuer, not on the firm's site.

If the answers are yes, choose on fit and on how clearly the provider replied. If they are no, you do not need a different provider yet. You need a clearer brief.