A strong penetration test starts with the right question—not the IP count.
Test quality is determined before the first request reaches a system. Objective, surface, access, constraints and success criteria decide whether the outcome changes risk or merely produces a report.
Decide before requesting a quote
- Risk objective and service under assessment
- Included assets, dependencies and exclusions
- Access level and attack scenarios
- Rules of engagement, monitoring and stop conditions
- Deliverables, remediation and retesting stated explicitly
1. Define the decision the test must support
“We need a pentest” is not an objective. A useful question asks whether an external attacker can reach customer data, a standard user can escalate toward administration, segmentation protects a critical service, or a new application is ready for launch.
A clear objective focuses time on relevant attack paths and helps management interpret the result: what assumption was tested, what remains unknown and what decision follows.
- Service and business consequence
- Plausible actor and starting point
- Security assumption being tested
- Success and stop criteria
- What this test cannot demonstrate
2. Map the surface and trust relationships
An IP list misses identity, APIs, supplier integration, cloud environments and business logic. Include enough context to reflect the real system while avoiding an unlimited scope that sacrifices depth.
Decide how assets discovered during testing are handled and who can authorize expansion. For applications, specify roles, tenants, data types and environments. For infrastructure, describe segments, access points and operationally sensitive systems.
- Domains, IPs, applications and APIs
- Cloud accounts, identities and roles
- Production or representative environment
- Suppliers and assets outside direct control
- Procedure for newly discovered assets
3. Choose access based on the risk question
Black-box, grey-box and white-box are starting conditions—not quality levels. No-information testing can assess external exposure but may spend time on discovery. Authenticated access enables authorization, role separation and business-logic testing. Configuration or code review answers different questions.
Complex organizations often benefit from stages: external exposure, limited-role access, then validation of paths toward critical assets. Document which credentials are provided and how they are created, transmitted and revoked.
4. Write rules of engagement that protect operations
NIST defines rules of engagement as guidelines and constraints established before the security test. They authorize approved activity and reduce ambiguity when a sensitive finding appears.
Include timing, test sources, contacts, monitoring, prohibited techniques, data handling, critical escalation and stop conditions. For live systems, define who decides whether testing continues and how test effects are separated from a real incident.
- Authorization and asset ownership
- Windows, source addresses and emergency contacts
- Allowed and prohibited techniques
- Evidence protection, retention and deletion
- Critical escalation and emergency stop
5. Contract for the outcome—not only testing days
The report should separate executive context from technical evidence and connect every finding to assets, conditions, impact and applicable remediation. CVSS helps, but priority must also consider exploitability, exposure, consequence, compensation and effort.
Include a technical debrief, prioritized backlog and retest conditions. Define whether retesting covers original findings only or side effects of remediation, and how risks accepted by management remain traceable.
- Executive summary and limitations
- Reproducible evidence and impact
- Recommendations and prioritized backlog
- Debrief with responsible teams
- Retest, closure criteria and residual risk
Penetration-test scoping questions
How many days should a penetration test take?
Duration follows objective, surface, roles, complexity and depth. Choosing days before scope risks shallow coverage or cost disconnected from the decision.
Is an automated scan enough?
Not to show vulnerabilities combining into an attack path. Scanning supports continuous coverage; pentesting adds manual validation, context and controlled exploitation.
Can production be tested?
Yes, when operational risk is controlled through rules, monitoring and stop conditions. Some techniques may require a representative environment or phased execution.
What information is needed first?
Objectives, owners, assets, relevant architecture, test roles, exclusions, timing, contacts and authorization. Sensitive data should only use agreed secure channels.
Official technical sources
The final method must reflect the system, operating risk and explicit authorization.
Have a risk question? Turn it into a testable scope.
We define scenarios, boundaries and deliverables before testing touches your systems.