Security Guide
Questions to Ask Before a Pentest
A good pentest does not start with tools, but with clear decisions. When you clarify scope, goals, and expectations, you save time, reduce friction, and get results you can act on.
From practice: the most common delays come from unclear test windows, missing access, and inconsistent expectations around reporting and re-tests.
Short version
Which systems, access paths, and boundaries apply?
How will testing, documentation, and prioritization work?
Rights, RoE, time windows, and contacts.
Is this guide a fit for you?
- an external test is planned or already running
- scope, time windows, and goals are still unclear
- reporting and re-test terms must be defined
- you want a long-term red-team exercise
- you need specific tool choices or exploit details
- you require legal advice for a specific case
When is a pentest needed?
- before go-live, audits, or certifications
- after major architecture changes
- with external access and sensitive data
- when risks are no longer assessable
| Format | Goal | Typical output |
|---|---|---|
| Pentest | Deep test of defined systems | Findings + prioritization |
| Vulnerability scan | Broad, automated detection | Lists of vulnerabilities |
| Red team | Goal-driven attack exercise | Operations report + lessons learned |
Preparation in 5 steps
Name critical data and processes.
Define systems, access paths, exclusions.
Test windows, abort criteria, approvals.
Accounts, VPN, IP allowlisting.
Set reporting format and re-test.
Preparation: the key questions
- Which systems and assets are in scope?
- Which access paths (external, internal, VPN, cloud)?
- Which goals are critical (data, processes)?
- Which areas are explicitly excluded?
- Which methodology is used (OWASP, PTES, ASVS)?
- Are PoCs and reproduction steps described?
- Is there an executive summary and prioritization?
- Is a re-test planned and scheduled?
- Which test windows apply (prod vs. staging)?
- What abort criteria exist?
- Are NDA/AVV/DPA required?
- Who approves critical tests?
- Are there test accounts or staging access?
- Who is the technical point of contact?
- How will debriefing/reporting work?
- How are findings prioritized internally?
Security, engineering/operations, product, legal/privacy, and possibly compliance. This reduces back-and-forth around access, RoE, and data flows.
Decisions you should make beforehand
Depth vs. breadth:
prefer a few systems deep, or many systems shallow?
Technical focus: web, network, cloud, or combined?
Ownership: Who implements findings and in what time window?
More systems in scope often means less depth per system. Decide consciously whether you prioritize coverage or depth.
What you should get from the provider
- Executive summary (risk, impact, priority)
- Technical findings with reproduction steps
- Concrete recommendations per finding
- Re-test conditions and timelines
- Current asset list and network boundaries
- Test accounts and contact chain
- Change windows and emergency contact
- Approvals for critical tests
Practical pitfalls (from practice)
- Test windows collide with deployments or maintenance.
- Staging differs too much from production.
- Accounts have unclear roles or too few rights.
- Incident response is unaware of the test and escalates.
Define a single contact chain (primary/backup). This reduces waiting time when testers need quick answers.
Scope note
This checklist helps prepare a pentest. It does not replace individual legal advice, red teaming, or a compliance assessment.
Next steps
- Document scope and goals in writing
- Approve test windows and RoE
- Prepare accounts, VPN, and IP allowlists
- Align on reporting format and re-test date
Briefly describe your scope. We help with classification and selecting suitable providers. Note: we advise on preparation and selection, but do not conduct tests ourselves.
Submit request