Share the requirement
Provide a non-sensitive summary and the exact language you received.
Your first penetration test
You do not need a finished scope to start.
Send us the request, likely systems, and deadline. We’ll separate what matters now from what can wait, then write a scope your company can understand and approve.
No finished scope requiredRequirement reviewed firstYour responsibilities explainedPreparation in stages
Where do we start with our first penetration test?
Start with who asked, what they said, which product or systems may be involved, what they want to receive, and when they need it. A provider should use that information to propose a scope rather than require you to design the test alone.
A short summary is enough to start. Scope, authorization, access, and safety details are completed before testing.
Before contacting a provider
Start with what you already know.
You do not need to delay the conversation while you collect every technical detail.
Helpful initial information
- The original customer, auditor, adviser, or internal request
- The business reason for the test
- The product, application, network, or environment likely involved
- The intended report recipient
- Any stated deadline
- Known technical or operational restrictions
Requirement versus scope
The customer’s request is not the final test plan.
A customer may ask for “a recent pentest” without naming the application, environment, user roles, testing methods, report contents, or deadline. We confirm those details during scoping.
The requirement explains why the test is needed. The scope states exactly what Trespass is allowed to test.
Questions we help answer
These details determine the test.
- What did they ask for?
A penetration test, vulnerability scan, PCI-specific work, or another type of security evidence.
- Which systems are included?
Applications, APIs, user roles, tenants, networks, environments, and integrations.
- What is your company allowed to authorize?
System ownership, third-party permissions, production restrictions, permitted techniques, exclusions, and stop conditions.
- What must your team prepare?
Accounts, access, contacts, backups, monitoring, approvals, and testing restrictions.
- What should the report contain?
The scope, work performed, findings, evidence, limitations, remediation guidance, and retest status.
Working with your team
We will explain what we need from you.
Your team provides system context, permissions, access, contacts, operating restrictions, and remediation. Trespass documents those responsibilities during scoping so there are no surprises before testing.
What your team will provide or confirm
- Confirming system ownership or obtaining appropriate authorization
- Providing accurate system, workflow, and business information
- Preparing the agreed access, roles, accounts, and environment
- Naming primary and escalation contacts
- Disclosing restrictions, sensitive operations, and third-party dependencies
- Maintaining appropriate backups, monitoring, and internal coordination
- Remediating findings and submitting eligible items for retesting
Typical stages
Here is what happens before and after testing.
Write the scope
List the systems, roles, techniques, exclusions, responsibilities, and deliverables.
Authorize and prepare
Complete agreements, written permission, Rules of Engagement, contacts, access, and safety controls.
Test and communicate
Perform the authorized work and follow the agreed escalation process.
Review, fix, and retest
Review the findings, complete remediation, and submit eligible fixes for consolidated retesting.
Common first-time mistakes
Avoid these common scoping and scheduling problems.
Buying a scan when a pentest was expected
Use the requester’s exact wording and confirm the intended activity.
Assuming every connected system is included
List the systems, environments, integrations, and third-party limits.
Leaving user roles undefined
Authentication, privilege, administration, and tenant models can change what must be tested.
Omitting production restrictions
Disclose sensitive workflows, prohibited actions, monitoring, and stop conditions before testing.
Treating the report as guaranteed acceptance
The report may answer the request, but the requesting party makes the decision.
Leaving no time for remediation and retesting
Allow time for engineering work and the approved retest window.
Next step
Start your first test with the requirement you have.
Tell us who asked, what they said, which systems may be involved, and whether there is a deadline. We’ll make the next scoping questions clear.