What to send a testing company first
Build the first handoff without writing the scope or sending sensitive material.
Read nextCustomer request guide
A customer asked for a pentest. What are they actually asking for?
They usually want credible evidence that the product or environment involved in the relationship has been independently tested. But the request alone does not tell you whether they expect a new assessment, an existing report, a particular system in scope, or a specific deliverable. Treat “we need a pentest” as the start of the conversation—not as a finished test plan.
The person making the request may not own every technical detail. Clarify the business requirement first, then confirm scope and testing details with the appropriate technical and contractual contacts.
Published by Trespass Security
Why the wording matters
“Pentest” can be shorthand for several different jobs.
You can respond faster when you identify which job the customer is trying to complete.
- Run a new assessment
The customer expects current testing of the product, application, environment, or service involved in the relationship.
- Review existing evidence
The customer wants a recent report, executive summary, retest status, or another controlled form of confirmation.
- Complete a security review
A questionnaire or procurement process may ask whether testing occurs, how often it happens, what it covers, and how findings are handled.
- Satisfy written language
A contract, control, policy, or assurance requirement may name testing, timing, independence, scope, or follow-up.
- Confirm remediation
The customer may already know about prior findings and want evidence that fixes were reviewed or retested.
Your first response
Confirm the outcome before you promise the work.
The customer may know exactly what its process requires, or it may be using “pentest” as a general label for security evidence. Either way, the original wording is useful.
Keep the request intact. Do not replace it with a technical interpretation before the people responsible for the requirement and the systems have reviewed it.
Ask these questions before defining the test
You are clarifying the request, not asking the customer to design the engagement.
- Are you asking for new testing, or evidence from testing already completed?
- Which product, application, service, or environment should the request cover?
- Does the testing or evidence need to be from a particular period?
- What do you expect to receive: a full report, executive summary, attestation, questionnaire response, or something else?
- Is there contract, control, framework, or assessor language we should review?
- What decision or deadline is this supporting?
A practical customer response
Ask for the missing details without making the customer do your scoping.
You can acknowledge the request and keep the commercial conversation moving.
Example response: “Thanks—we can work through this with you. To make sure we address the right requirement, can you confirm whether you need new testing or existing evidence, which product or environment this should cover, what you expect to receive, and the date you need it? If there is contract, questionnaire, or control language behind the request, please send that wording as well.”
This response does not promise that an existing report will fit, that new testing can meet an unreviewed deadline, or that a particular deliverable will be accepted.
What clarification changes
The answer determines what you buy, prepare, authorize, and deliver.
Skipping this step can create the wrong scope, the wrong evidence, or a timeline built around assumptions neither side intended.
Clarification is not delay. It is how the engagement starts cleanly.
- The activity
Clarification may distinguish a new penetration test from an existing report review, vulnerability scan, questionnaire response, or retest.
- The scope
The relevant target may be one application, its supporting APIs, a defined environment, or another bounded system—not the company in the abstract.
- The timing
The customer’s deadline, acceptable evidence age, and any planned product changes affect whether existing work is useful and when new work should occur.
- The deliverable
A full technical report, executive summary, retest update, and questionnaire response answer different questions and carry different sharing considerations.
- The engagement plan
Once the requirement is understood, the systems, roles, exclusions, access, authorization, testing window, report, and retest path can be written down.
Before you commit
Do not let urgency turn an incomplete request into an unsupported promise.
You can move quickly without guessing.
- Do not say an existing report fits the request before confirming its scope, age, sharing terms, and expected evidence.
- Do not assume a vulnerability scan and a penetration test are interchangeable.
- Do not describe the entire company as tested when the authorized scope covers defined systems.
- Do not commit to a testing date before confirming scope, access, dependencies, and readiness.
- Do not begin testing without written authorization, Rules of Engagement, named contacts, and stop conditions.
Next step
Bring us the request before you turn it into a test plan.
Send the exact wording, the product or system involved, who asked, and the deadline. A brief, non-sensitive summary is enough to begin.