A useful penetration test begins with a precise scope.

01

Describe what is being tested

List the applications, interfaces and environments in scope. Identify important user roles and trust boundaries. A hostname alone rarely describes authorization, integrations or business workflows.

Decide whether the exercise considers unauthenticated access, authorized roles or both. Explain which assumptions will be supplied to the testing team. The scope determines what the report can meaningfully say.

02

Agree rules of engagement

Testing requires explicit authorization and agreement about timing, restrictions and escalation. Identify exclusions, stop conditions, emergency contacts and third-party approvals. An application owner may not be able to authorize testing against every supplier service.

Use agreed test identities and avoid unnecessary customer data. Define how evidence is protected and delivered. Destructive activity, availability testing and social engineering need specifically agreed boundaries and qualified delivery.

03

Follow the application’s decisions

Examine how the application handles identity, permissions, input, state and sensitive operations. Scenarios depend on architecture. Reference material such as the OWASP Web Security Testing Guide can support methodology discussion without defining the whole engagement.

Record what was tested and what could not be tested. Missing access, unavailable functionality and excluded interfaces belong in the limitations. A clean result in a narrow scope is not a guarantee of organizational security.

04

Make findings actionable

Connect each observation to its affected component, impact, evidence and remediation direction. Explain prerequisites and distinguish demonstrated behavior from a hypothesis. Protect secrets and sensitive records in evidence.

Agree an owner and acceptance criterion for remediation. Priorities should consider exposure and operational context rather than relying on a severity label alone.

05

Close the loop with verification

Define whether verification is included, what it covers and which changed components need a new assessment. Verification checks an agreed correction; it does not convert a point-in-time exercise into continuous assurance.

Handover scope, methods, limitations, findings and verification status. No website demonstration or downloaded sample is evidence that an actual test occurred.

Continue exploring