Review
Identify who asked, what they named, what they want to receive, and when they need it.
Customer-required penetration testing
Your customer asked for a pentest.
Start with the request you received. We’ll help clarify the testing and evidence your customer needs, then put the scope in writing before you commit.
What the customer may want
A test, a report, or simply an answer?
A request for a pentest, scan, or recent report can mean different things. We review the exact wording before recommending the work.
- A new test
The customer wants current testing of the product or environment involved in the relationship.
- A recent report
The customer wants to review existing evidence, often with confidentiality or recency requirements.
- A questionnaire response
The customer is asking whether testing occurs, how often, what it covers, or how findings are handled.
- A contract requirement
The agreement may specify systems, timing, testing depth, personnel, report access, or remediation follow-up.
- A security review
The request may be part of procurement, a trust review, a control discussion, or enterprise-sales due diligence.
What to send
The request and a little context.
Do not submit credentials, keys, source code, vulnerability evidence, regulated records, production data, or other secrets through the request form or email.
Useful initial information
Send non-sensitive context. A complete technical package is not required.
- The customer’s exact wording
- Who asked and how they are involved
- The product, application, or environment under discussion
- Any stated deadline or desired timing
- What they asked to receive: testing, a report, a summary, or another form of evidence
- Known restrictions or third-party dependencies
From request to test plan
A scope your customer can review.
Share the statement of work with your customer to confirm that the planned testing addresses their requirements before you commit.
See a statement of workClarify
Confirm whether they need testing, scanning, PCI-specific work, an existing report, or more information.
Write the scope
List the systems, environments, roles, techniques, exclusions, responsibilities, and limitations.
Authorize
Complete the agreements, written permission, Rules of Engagement, and stop conditions.
Test and report
Perform the authorized work and provide the report, findings review, remediation guidance, and retest results.
Report and follow-up
The report helps answer the request.
We confirm the report and sharing requirements during scoping. The customer makes the final decision about whether the evidence meets its needs.
See a sample report- Explain what was tested
The report states the authorized scope, work performed, limitations, findings, and remediation status.
- Choose what to share
The full technical report, executive summary, and answers to follow-up questions may need different handling.
- Protect sensitive details
Sharing depends on the engagement terms, the technical details in the report, access restrictions, and what the recipient needs.
Next step
Let’s start with their request.
A non-sensitive summary and the exact wording are enough to begin. Do not include credentials, secrets, source code, or vulnerability evidence.