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 it as 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.
On TadiSec’s kickoff call with Navigating Security Corp, you’ll be on the call with Oliver Whitaker (CISO), Aarav Patel (IT Director), and Cathy Williams (SOC Manager). Each has different concerns, and part of your job is to hear all of them.
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.
Kickoff Call Preparation
ranking
You're preparing for TadiSec's kickoff call with Navigating Security Corp. Based on the scope and RoE you've reviewed, select the 5 most critical questions to ask. Drag your top 5 to the priority list.
- 1Can we confirm VPN connectivity and test that Tadisec can reach the 10.1.1.0/24 subnet before testing starts?
- 2Can we quickly reconfirm key dates (testing window, draft report, final report, and readout) so everyone is aligned?
- 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 (for example LSASS dumps, large LDAP queries, replication-based attacks)?
- 4Are there specific compliance frameworks (for example SOC 2 or applicable state privacy regulations) you want findings explicitly mapped to in the report?
- 5Are there any planned maintenance windows or major changes between March 24 and April 3 that could affect testing or findings?
- 6Are there any additional restrictions on tools or techniques beyond those already listed in the SOW and RoE (for example prohibitions on specific EDR bypass techniques)?
- 7Can you share any relevant previous pentest or vulnerability scan reports from the internal network or AD, if available?
- 8Can we confirm when to use the emergency contact (Cathy Williams) versus the Teams channel, and that she will be reachable 24/7 during the testing window?
- 9Can we confirm the t.chigubhu test account is provisioned, has the expected low-privilege access, and is not used for any production workflows?
- 10Can 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?
- 11Just to confirm, this engagement does not include wireless testing or onsite Wi-Fi assessments, correct?
- 12Are there any stakeholders who need tailored readouts (for example exec-only summary versus deep-dive for the AD team)?