A penetration-test kickoff should convert a signed scope into a testable system model. Engineering should leave the meeting knowing which applications, APIs, roles, tenants, environments and high-risk workflows the testers will exercise—and which assumptions still need evidence. If the discussion is limited to dates and IP addresses, important scope gaps usually appear only when the report arrives.

Use the kickoff to make coverage observable. The objective is not to prescribe every tester action. It is to give the testing team the access and context needed to investigate the real trust boundaries while retaining a clear record of inclusions, exclusions and operational constraints.

Start with the architecture the testers will actually encounter

Ask the vendor to restate the system in their own words. Include browser and mobile clients, public and private APIs, gateways, identity providers, background workers, storage, third-party callbacks and administrative consoles. A diagram is useful only when its trust boundaries and data flows match the deployed test environment.

  • Which hosts, applications, API versions and mobile builds are in scope?
  • Where are authentication, authorization and tenant boundaries enforced?
  • Which services trust headers, tokens, gateway context or internal network position?
  • Which integrations can be exercised, simulated or observed safely?
  • Which legacy endpoints or alternate clients still reach production logic?

Ask what the tester will not be able to infer from discovery. Bespoke workflows and server-to-server interactions often require an engineering walkthrough before meaningful adversarial testing can begin.

Make roles and identity states explicit

A list of role names is not a test plan. Provide accounts and explain the permissions, lifecycle state and expected relationships represented by each one. For multi-role systems, ask which role pairs will be tested for vertical and horizontal privilege movement.

  • Unauthenticated, newly registered and verified users.
  • Standard, privileged, support and administrative roles.
  • Invited, suspended, deactivated and recently changed accounts.
  • Service accounts, API clients and machine identities.
  • Users who own records and peers who must not access them.

Confirm who creates accounts, resets credentials and restores locked identities during testing. Lost access can silently remove an entire authorization branch from coverage.

Define tenant relationships, not just tenant IDs

For a multi-tenant product, supply at least two controlled tenants and describe isolation expectations. Include parent-child organizations, cross-tenant collaboration, support access, migration, mergers, delegated administration and any shared catalogue or analytics features.

Questions that expose tenant blind spots

  • Can the same person belong to more than one tenant?
  • Can identifiers be guessed, imported, shared or transferred?
  • Which queues, exports, search indexes, caches or object stores contain tenant data?
  • How is tenant context established for asynchronous jobs and internal APIs?
  • What should happen when membership or ownership changes mid-session?

Reconcile the API inventory before testing starts

Ask which source will define API coverage: an OpenAPI specification, gateway export, client traffic, code routes or a combined inventory. Record versioned, deprecated and undocumented interfaces. Identify protocols beyond HTTP, including WebSockets, GraphQL, webhooks and file-processing endpoints.

  1. Provide the best available machine-readable specification.
  2. Mark endpoints that are incomplete, internal or generated dynamically.
  3. Map authentication schemes and required headers to each interface.
  4. Identify high-value state changes and bulk operations.
  5. Agree how newly discovered routes will be added to the coverage record.

A vendor cannot test an API merely because its hostname is in scope. Credentials, request examples, state prerequisites and business meaning determine whether the interface can be exercised deeply.

Prioritize critical business workflows

Walk through the actions whose abuse would matter most: onboarding, approval, payment, entitlement, password recovery, export, deletion, configuration, support impersonation and administrator operations. Ask the tester to explain how those workflows will be tested across roles, states and sequence changes.

Share important invariants such as “a user may approve but never initiate the same transaction” or “support may view metadata but not customer secrets.” These statements direct testing toward logic that scanners cannot discover.

Confirm the environment is representative and ready

  • Build or release identifier and configuration differences from production.
  • Feature flags, integrations and background jobs enabled for testing.
  • Seed data and record ownership needed for workflows.
  • Rate limits, web application firewalls and monitoring that could distort results.
  • Logging available to distinguish a blocked attempt from an untested path.

If a production control is disabled in the test environment, document how the resulting risk will be interpreted. If a production-only path cannot be tested, record the limitation rather than assuming an equivalent path covers it.

Set safe operational boundaries

Discuss destructive operations, denial-of-service techniques, automated concurrency, social engineering, data exfiltration, persistence and third-party systems. For each restricted activity, agree on a safe substitute or a controlled validation window. A prohibition without an alternative creates an invisible evidence gap.

  • Approved test windows and source addresses.
  • Maximum request rates and concurrency.
  • Data that may be created, modified, downloaded or retained.
  • Stop conditions and the people authorized to invoke them.
  • Handling and deletion of screenshots, logs, tokens and exports.

Agree communication and escalation before the first finding

Define a primary engineering contact, a security decision-maker and an emergency operational contact. Ask how critical evidence will be communicated without waiting for the final report, how duplicates will be handled and when scope ambiguities will be escalated.

Schedule short coverage checkpoints for a complex engagement. Review access blockers, discovered interfaces, untested workflows and emerging scope changes—not vulnerability counts. This lets engineering repair testability while useful time remains.

Ask what evidence the final report will contain

Confirm that each finding will identify the affected asset, role, tenant or state, preconditions, reproducible steps, observed impact, evidence and remediation direction. Ask for a coverage and limitations section that names material paths not exercised. This is essential for interpreting a clean result.

The OWASP Web Security Testing Guide and NIST SP 800-115 provide useful testing structure, but the kickoff must translate general methods into your specific identities, workflows and architecture.

Close the kickoff with accountable actions

  1. Read back the final in-scope asset and interface list.
  2. Confirm the account and tenant matrix and its owner.
  3. Record operational restrictions and their safe alternatives.
  4. Assign every missing credential, document or data dependency.
  5. Set the process for additions, exclusions and risk acceptance.
  6. Circulate the coverage record to engineering, security and the vendor.

The practical decision

A strong kickoff gives the tester enough context to challenge the system rather than merely enumerate it. Make architecture, identities, tenants, APIs, business invariants, environmental differences and test limits explicit. Then keep the coverage record current throughout the engagement so that the final report contains no surprise omissions.

Plan a coverage-led penetration test with WIMD and begin the engagement with a documented engineering kickoff.