12 Questions to Ask a Penetration Testing Company Before You Hire Them

Oct 7, 2026 • 8 min read

You may be hiring a penetration testing company to meet a customer requirement, prepare for an audit, or assess an application before it goes live. Whatever prompted the search, you need a clear understanding of what the provider will test and what your team will receive when the work is done.

Comparing proposals can be harder than finding providers. Each may promise experienced testers, thorough testing, and a detailed report, while leaving you to work out what those promises mean for your systems, budget, and deadline.

Suppose two proposals cover the same application. One includes several user roles, time to investigate business workflows, and a retest after fixes. The other leaves those details unspecified. Before comparing prices, you need to establish whether you are buying comparable work—and resolve the gaps before testing begins.

The 12 questions below will help you examine the people, scope, testing approach, deliverables, and follow-up behind a proposal. Use them to start a discussion, ask for evidence, and put the agreed terms in writing. The comparison worksheet at the end gives you a place to record each provider’s answers and outstanding questions.

Before the conversation, bring your testing objective, a rough scope, and your deadline. Include the customer request or audit requirement if one prompted the test. You do not need a finished specification to start.

Jump to a question

Who will actually perform our penetration test?
Have you tested environments like ours?
What will you test? (And what will be excluded?)
What work will people, automated tools, and AI perform?
How much active testing is included?
What access and preparation will you need from us?
How will you protect our systems and testing data?
Can we communicate directly with the testers?
Can we review a sample report?
Will the deliverables address our customer or audit request?
What happens after we receive the findings?
What is included in the price, and what could change it?

1. Who will actually perform our penetration test?

Ask who will do the hands-on testing, who will lead the engagement, and who will review the findings. You need relevant experience for the people assigned to your project; a company’s credentials describe a larger organization.

Request short tester biographies and an explanation of each person’s role. Certifications can inform the conversation, but ask what comparable work the assigned testers have done. If staffing is not final, agree on the required experience and when you will meet the team.

Clarify whether subcontractors participate, what access they receive, and who remains responsible for quality. Also ask how staffing changes will be communicated.

2. Have you tested environments like ours?

Look for experience with comparable technologies, architecture, and business workflows. A provider that has tested websites may still need to explain its approach to your mobile application, API, or internal network.

For a software company, useful details might include experience testing customer data separation, single sign-on, and different permission levels. Ask for an anonymized example that explains the testing problem, the investigation, and how the finding was verified.

A provider should be able to discuss its methods without exposing another client’s confidential information. Follow up with: “What would you need to learn about our environment before deciding how to test it?”

3. What will you test? (And what will be excluded?)

Request a written scope that names the applications, APIs, network ranges, user roles, and environments included. Check it against what you discussed; a product name alone can hide different assumptions about coverage.

Suppose your portal includes customer accounts, an administrator console, and an API. Confirm whether all three are included, which permissions will be tested, and whether the work covers staging, production, or both.

Illustrative exchange — example only:

Vague: “We test the whole application.”

More useful: “The proposal includes the customer portal and API with two customer roles. The administrator console is excluded. We can quote that separately.”

Before signing, resolve any difference between your expectations and those boundaries. Agree on how newly discovered assets will be considered and authorized.

4. What work will people, automated tools, and AI perform?

Ask the provider to describe the testing process and who is accountable for the findings. Tools can support discovery and repeatable checks; you also need to understand how testers investigate workflows, validate results, and pursue unexpected behavior.

Ask for a specific example: “How would you test whether one customer can access another customer’s records?” A useful answer explains the accounts, permissions, and evidence involved, not just the names of tools.

If AI is used, clarify its tasks, human review, and whether your code, credentials, or testing data leave the agreed environment. Avoid treating either AI use or unfamiliar terminology as a verdict on quality.

Halo’s penetration testing service combines manual investigation with tools whose results are validated by testers.

5. How much active testing is included?

Ask how much effort is allocated to testing and how it will be distributed across your scope. A two-week project window might also contain setup, reporting, and review; it does not necessarily mean two weeks of active investigation.

Request a breakdown that distinguishes testing from project administration, report preparation, and retesting. If the quote uses tester-days, ask what that unit includes and how many people will participate.

Hours alone do not establish quality. Relevant experience, usable access, and a sensible allocation of effort also affect coverage. Ask: “Which areas will receive the most attention, and what would receive less attention if we keep this budget?”

6. What access and preparation will you need from us?

Get a preparation checklist with owners and deadlines. Depending on the engagement, testers may need accounts for multiple roles, separate customer organizations, API documentation, application builds, network access, and a walkthrough of business workflows.

Ask who will verify that access works before testing starts. If authentication or test data is incomplete, find out whether the provider will reschedule, revise coverage, or spend part of the testing allocation resolving it.

For example, one administrator account may not let testers assess restrictions between ordinary users. Clarify how missing access and other limitations will appear in the final report so readers know what could not be assessed.

7. How will you protect our systems and testing data?

Request documented testing restrictions, stop procedures, and data-handling arrangements. “We take security seriously” does not tell your operations team what will happen during the engagement.

Agree on permitted techniques, testing windows, limits on disruptive activity, and who can pause and restart work. Confirm the emergency contacts on both sides and how they will be reached.

Ask who can access credentials, screenshots, captured data, and reports; how those materials are transferred and stored; and when they are deleted, including any backup exceptions. Include subcontractors and external tools in that discussion.

Where evidence could contain sensitive records, ask how the tester will demonstrate impact while limiting collection. The written arrangements should reflect your environment and obligations.

8. Can we communicate directly with the testers?

Confirm how your technical team can reach the people doing the work. Direct discussion can resolve questions about intended behavior, access, and findings before misunderstandings reach the report.

Ask which channel you will use, how progress updates arrive, and who covers questions when the lead tester is unavailable. Agree on how urgent findings are escalated and who acknowledges them; do not assume every provider offers the same response times.

Halo gives clients direct access to its US-based testers. When comparing providers, ask what that access looks like during testing and after report delivery, including whether a technical findings discussion is included.

9. Can we review a sample report?

Request a redacted or representative sample and read it with someone who will fix the findings. Look for enough evidence to understand the issue, its practical impact, and what to change.

Choose one finding and check whether it identifies the affected asset, explains prerequisites and reproduction steps, supports the severity rating, and gives usable remediation guidance. The report should also describe the tested scope and limitations.

Illustrative exchange — example only:

Vague: “You get a detailed report with risk scores.”

More useful: “This sample shows the affected function, the access needed, evidence of the behavior, and recommended remediation. It also records testing limitations.”

For a closer review, see Halo’s guide to pentesting deliverables.

10. Will the deliverables address our customer or audit request?

Share the actual request before buying the test. Ask the provider to map the proposed coverage and documents to that request, including any required testing period, methodology, or retest evidence.

Confirm whether you need a full technical report, an executive summary, an attestation letter, or a combination. Establish who will receive each document and whether a version suitable for customer sharing is included.

A completed pentest does not guarantee compliance or customer acceptance. Resolve unclear requirements with the requesting customer or auditor before the engagement starts. “We provide compliance reports” is incomplete unless the proposed work and documentation match what you must submit.

11. What happens after we receive the findings?

Clarify the support available for understanding findings, discussing fixes, and verifying remediation. Guidance can help your engineers choose a solution; implementing and deploying that solution remains separate work unless explicitly included.

Ask which findings qualify for retesting, how soon you must request it, how many rounds are included, and what happens if the application changes substantially. Confirm whether verification produces an updated report and how unresolved or partially fixed issues are recorded.

Illustrative exchange — example only:

Vague: “Retesting is included.”

More useful: “The quote includes one verification round for the reported findings. We’ll document the request deadline, scheduling terms, and charges for additional rounds.”

Halo walks clients through recommended fixes. Ask us the same questions about support and retesting when reviewing your proposal.

12. What is included in the price, and what could change it?

Request a written breakdown of the quoted scope, deliverables, support, and retesting terms, plus exclusions and optional charges. Compare proposals against the same requirements before comparing their totals.

Ask what happens if you add an application, need another user role tested, delay access, or request additional verification. Find out how changes are approved and whether they affect delivery dates as well as cost.

A lower price can reflect a narrower scope, a different allocation of effort, or different commercial terms. Ask the provider to explain the difference rather than treating price as proof of quality.

Before signing, reconcile the quote with the statement of work so promises made during the conversation appear in the agreement.

Compare the answers before you sign

Use the worksheet below for each provider. Record the answer, the document or example that supports it, and anything still unresolved. A confident answer without supporting detail is a follow-up item. An unfamiliar term is a reason to ask for an explanation.

Before selecting a provider, check that you can identify the assigned team, agreed coverage, testing effort, access requirements, safeguards, delivery dates, report contents, retest terms, and total price. Resolve gaps that could prevent the engagement from meeting your objective.

Bring these questions to Halo Security

Bring us your testing goal, rough scope, and deadline. We’ll help you work through coverage and deliverables so you can evaluate a concrete proposal.

Talk through your next pentest with Halo Security.

Vendor comparison worksheet

Use one copy per provider. Keep supporting evidence specific: a proposal section, tester biography, sample finding, or written term.

Provider: ____________________ Reviewer: ____________________