Penetration testing at Trespass
See how Trespass reviews the request, defines scope, performs the test, reports findings, and handles retesting.
Read nextProvider-selection guide
How should you compare penetration-testing companies?
Look for a company that will review the actual request, write a specific scope, require written authorization, explain how the test will be run, investigate findings before reporting them, protect sensitive information, and clearly describe reporting and retesting.
Claims such as human testing, good reports, retesting, or US delivery are not enough on their own. Ask exactly what each claim means for your test.
Published by Trespass Security
Questions to ask
Find out exactly how the company will run the test.
Requirement and scope
- Will the company review the requester’s exact language before defining the work?
- Does the proposal list the systems, environments, roles, exclusions, responsibilities, limitations, and deliverables?
- Can the company explain why the proposed coverage fits the requirement?
- Does it address system ownership and third-party permissions?
Authorization and safety
- Are written authorization and Rules of Engagement required before testing?
- Are permitted techniques, restrictions, contacts, escalation paths, and stop conditions defined?
- How are production risks and data-handling requirements addressed?
- What happens if the scope, systems, access, or conditions change?
Testing approach
- How will the company organize the test and report?
- How does the company decide what technical areas to test?
- How are potential findings checked before they reach the report?
- How can your team ask questions during the work?
Report and retesting
- What will the report say about scope, testing, findings, evidence, risk, and limitations?
- How are sensitive files and evidence handled?
- Is a live findings review included?
- How are remediation questions and retesting handled?
Requirement interpretation
A strong provider should help prevent you from purchasing the wrong activity.
The provider should be able to explain whether the request appears to call for penetration testing, vulnerability scanning, PCI-specific activity, existing evidence, or further clarification.
That judgment should remain tied to the requester’s words, your systems, the expected evidence, and what your organization can authorize—not to a preselected package.
Check the details
Ask each company to explain its claims.
You should know how the work is run, what is documented, and where each promise ends.
- Human testing
Ask who directs the work, how tools are used, and how application behavior or attack paths are investigated.
- Investigated findings
Ask what must be observed before an issue is included in the report.
- Communication
Ask how questions, updates, material issues, the findings review, and retesting will be handled.
- Retesting
Ask which findings qualify, how to submit fixes, when retesting must happen, and how results are recorded.
- Reports for customers or auditors
Ask what the report contains, how limitations are stated, how it is protected, and how third-party questions are handled.
- US-based delivery
Ask which parts of the work are done in the United States and by whom.
Warning signs
Be cautious when important details are missing.
Promises of universal acceptance
No provider controls every customer, auditor, assessor, insurer, or partner decision.
A scan presented as the same as a pentest
The company should explain the differences in purpose, method, investigation, authorization, and reporting.
Unclear authorization
Testing should not begin with vague permission or assumptions about third-party systems.
Undefined scope
The systems, roles, environments, exclusions, techniques, restrictions, and deliverables should be listed.
Vague deliverables
You should know what the report, findings review, remediation support, and retest include.
Unsupported claims
Credentials, performance claims, and guarantees should be specific, current, and supported.
Compare the same request
Give each company the same requirement and system summary.
Use the same systems, user roles, environments, deadline, report needs, and restrictions for every company.
If the proposed scopes differ, ask why. More items do not always mean better coverage, and a shorter scope may be correct if it matches the actual requirement.
Next step
Compare Trespass against the requirement you received.
Send a non-sensitive summary of the request, likely systems, and deadline. We’ll tell you what still needs to be confirmed before the test can be scoped.