Module 2

2.3

The Kickoff Call

The kickoff call is your first real interaction with the client. It’s where you meet the people behind the engagement, confirm the details from the scope and RoE, and ask the questions that the documents didn’t answer.

Do not see the kickoff like a formality. As something to sit through before the “real work” starts. That’s wrong. The kickoff is where you build credibility, set expectations, and clarify questions about the environment or application.

A good kickoff covers three things:

Logistics: VPN credentials, testing windows, communication channels, who to contact for what. Confirm everything in writing after the call.

Technical context: Are there sensitive systems to avoid? Is there authenticated testing? What credentials are being provided? Are there known fragile systems that could go down under load?

Business context: What triggered this engagement? Is there a compliance requirement? What does the client care most about; availability? Data security? Regulatory findings? This context shapes how you prioritize findings and write the report.

In a lot of instances, I have thought to take a general approach until I ask the client what they care about the most, allowing me to work specifically on that while also covering other test cases.

The kickoff call is tomorrow. Based on the scope and RoE you’ve already reviewed, select the five most important questions from the list on the right.

Challenge

Kickoff Call Preparation

ranking

Rank these five critical kickoff call questions in order of priority — 1 being the most important to ask first. There is a defensible correct order.

  1. 1Can we confirm when to use the emergency contact versus the Teams channel, and that she will be reachable 24/7 during the testing window?
  2. 2Are there any planned maintenance windows or major changes during the testing window that could affect testing or findings?
  3. 3DC01 is the only authorized target — and it's a single-DC environment. Which specific operations on DC01 are highest-risk from a stability perspective (e.g. LSASS dumps, large LDAP queries, replication-based attacks)?
  4. 4Can you confirm that only 10.1.1.0/24 is in scope, and that we should treat any other reachable internal subnets as out of scope unless formally added?
  5. 5Can we confirm VPN connectivity and test that our team can reach the 10.1.1.0/24 subnet before testing starts?