2 min read
What to bring to a penetration testing scoping call
The systems, user journeys and business questions that help turn a broad request into a useful security assessment.
A request to “test our application” is a starting point. Before testing begins, both teams need a shared understanding of the systems involved, the boundaries of the work and the decisions the results should support.
You do not need a polished security brief for the first call. Bring the information you have, and identify what still needs an owner.
Start with the reason for the test
A launch, a customer review and a concern about account isolation may lead to different testing priorities. Explain what prompted the request and what your team needs to know when the assessment ends.
If there is a deadline, describe what happens on that date. A report needed for a procurement review is different from a release that can move while a serious finding is fixed.
Describe the product as people use it
Bring a short list of the important journeys. For a SaaS product, that might include account creation, inviting colleagues, changing roles and exporting customer data. For an API, explain who calls it and which actions involve sensitive information.
Include the roles available in the system. Testing a single administrator account gives a different view from testing the boundaries between ordinary users, administrators and separate customer accounts.
A diagram helps, but a clear conversation is enough to get started.
Agree on the testing boundaries
List the applications, APIs, domains and environments you expect to include. Identify third-party systems and anything your organization cannot authorize for testing.
The rules of engagement should cover permitted techniques, excluded activities, working hours, contact points and the circumstances that require testing to stop. These details deserve agreement before anyone starts sending traffic.
Prepare access and a contact path
Decide who will create test accounts, answer product questions and handle an urgent finding. If the test depends on a staging environment, discuss how closely it represents the system you want assessed.
Access problems can consume time that should be spent investigating the product. It helps to verify accounts and permissions before the testing window starts.
Ask what you will receive
A useful handoff should explain the finding, the evidence behind it and the practical next action. Ask about the report format, the technical review meeting and whether retesting is included in the proposed scope.
Your engineers need enough detail to investigate. Your decision-makers need to understand the impact and the choices in front of them. Agree on both audiences at the start.