Trespass SecurityTrespass Security
Menu

First-contact guide

What should you send a penetration-testing company first?

Send the exact request you received, who made it, the product or system it appears to concern, the deadline, the evidence they named, and whether relevant testing already exists. If some of that is unknown, say so. The provider should use this first handoff to identify the next questions—not expect you to arrive with a finished scope.

Keep credentials, keys, source code, vulnerability details, production data, regulated records, and customer-confidential material out of ordinary email and intake forms. A testing company should arrange an approved secure transfer method later if sensitive information becomes necessary.

Published by Trespass Security

The five-minute handoff

Start with the information already sitting in front of you.

An imperfect original request is usually more useful than a polished summary built on assumptions.

  • The exact wording

    Forward or paste the customer email, questionnaire item, contract sentence, control language, or assessor request without translating it into testing jargon.

  • Who asked

    Name the customer, prospect, partner, assessor, internal owner, or other legitimate requester and how they are involved.

  • The likely target

    Identify the product, application, API, environment, network, or service you think the request concerns. “We are not sure yet” is a valid answer.

  • The deadline

    Include the date and what it supports—a customer review, contract, renewal, audit step, launch, or another business decision.

  • The requested evidence

    Note whether they mentioned a full report, executive summary, retest result, questionnaire response, attestation, or simply “proof.”

  • Existing work

    Say whether relevant testing may already exist and, if known, when it happened and what it covered. Do not attach the report automatically.

Forward before you translate

The original sentence can change the entire engagement.

“Send the latest report,” “complete this questionnaire,” and “perform testing before launch” are different jobs. Rewriting all three as “we need a pentest” removes the detail a provider needs most.

Add context, but keep the source wording intact. If the request lives in a sensitive contract or customer record, send only the relevant non-sensitive excerpt first.

Example first message:

“A customer asked us for ‘our latest pentest report’ for the Acme product. They need an answer by September 18 for a vendor review. We completed testing last year, but I am not sure whether it covered the current production application or whether they need a full report. What do you need from us to determine the right next step?”

That message gives a provider something useful to interpret without pretending the scope is already settled.

Not required on day one

You should not have to write the testing company’s Statement of Work.

The first handoff gives the provider enough context to separate what is known from what still needs to be decided. Detailed system boundaries, access, safety rules, authorization, and deliverables follow during scoping.

If a provider cannot tell you which questions come next without a finished technical package, it is handing its intake work back to you.

What can wait until scoping

These details matter, but they do not belong on your pre-call homework list.

  • Final asset and endpoint inventory
  • Every application module and integration
  • Complete user-role and tenant matrix
  • Test accounts, VPN access, and allowlisting
  • Permitted techniques, exclusions, and stop conditions
  • Final testing dates, reporting details, and retest terms

Keep the first exchange safe

Context belongs in the first message. Secrets do not.

A normal email or website form should be enough to explain the business request. When scoping requires sensitive material, agree on what is necessary, who may access it, how it will be transferred, and how it will be handled.

Sending more files does not make an unclear request clearer.

  • Passwords, API keys, private keys, recovery codes, or session tokens
  • Source code, exploit material, or unreviewed vulnerability evidence
  • Production databases, customer records, regulated data, or confidential logs
  • A full prior report before sharing permission and recipient need are confirmed
  • Broad architecture exports or internal documents that are not necessary to clarify the request

What should come back

A useful response reduces your next round of work.

The provider should turn the first message into a short list of decisions—not a request for everything your company knows.

  • An interpretation

    What the request appears to mean and which points still need confirmation.

  • The next questions

    Only the details needed to choose the activity, define the likely target, and understand the timing.

  • A staged information request

    What is useful now, what will be needed during scoping, and what must be ready only before testing.

  • A safe path for sensitive material

    A defined transfer and handling method if later stages require information that should not travel through ordinary intake.

  • The next concrete step

    A clarification call, evidence review, scoping session, or another bounded action with a clear owner.

Related information

Next step

Start with the message you already have.

Send a brief, non-sensitive summary of the request, deadline, and likely systems. We will identify what needs to be clarified next.

Get a pentest