Before VAPT: define the engagement

Begin with the business objective

A useful security test starts with a question: which business systems and risks should this engagement help you understand? List the services that matter to customers, staff and operations. Explain whether the goal is a launch review, a periodic assessment or a focused investigation. ## Make the asset list explicit Record applications, domains, environments and interfaces that are proposed for testing. Identify an owner for each. Separate production and test environments and note any third-party systems that require separate permission. ## Agree authorisation and boundaries Testing should begin only after the authorised parties approve the scope and rules of engagement. Define permitted methods, exclusions, testing windows, escalation contacts and stop conditions. Give the team a route to report unexpected issues. ## Plan for findings, not just a report Decide who will receive technical evidence, who will prioritise remediation and how changes will be tracked. Agree whether retesting is included and what it covers. ## Your preparation list - Named business and technical owners - Agreed assets and environments - Written authorisation and exclusions - Testing windows and escalation contacts - Report recipients and remediation owners - Agreed retest scope ## Next step Use the security assessment checklist in Resources to organise the first conversation. A consultation establishes scope; it is not permission to test.