Cybersecurity · Checklist

Pre-VAPT Readiness / Scoping Checklist — ask these before you request a test.

The questions a VAPT provider will ask you anyway — answer them up front and your engagement starts scoped correctly, on schedule, and without surprise change requests.

Mapped to current published standards & statute text
14
Checklist items, each with a test procedure & evidence example
5
Stages, organized the way a real implementation unfolds
Free to use. Work through it here, no form needed. To get your readiness score, submit it for expert review below.
Expert review

Get your readiness score

Work through the checklist, then submit it — an expert scores it using Self-Compliance and emails you the result.

Check off at least one item below to unlock
Open "How to verify this" on any item for the exact test procedure & evidence an auditor would want Progress saves only in this browser — nothing is sent anywhere until you submit it for review
0 of 14 items checked off
Browsing:
  • How to verify this →

    Test procedureCross-check the submitted asset list against your actual DNS records, cloud inventory and API gateway config for anything left off.

    Practical example / evidenceSigned-off asset/scope list with owner confirmation.

  • How to verify this →

    Test procedureConfirm the scoping document has an explicit exclusions section, not just a list of what's included.

    Practical example / evidenceScoping document's exclusions/out-of-scope section.

  • How to verify this →

    Test procedureVerify the agreed environment is reachable and representative, or that the production test window is confirmed with the hosting/ops team.

    Practical example / evidenceEnvironment access confirmation or signed production test-window agreement.

Stage 1 of 5
  • How to verify this →

    Test procedureCheck the rules of engagement names the test type and that it matches the stated objective (e.g. simulate external attacker vs. insider).

    Practical example / evidenceRules of engagement document naming the test type and rationale.

  • How to verify this →

    Test procedureConfirm the network diagram marks which segments are in scope and whether testing originates internally or externally.

    Practical example / evidenceNetwork scope diagram or statement.

  • How to verify this →

    Test procedureCheck the statement of work line-items against the asset list to ensure every claimed layer actually has corresponding assets.

    Practical example / evidenceStatement of work with layer-by-layer scope breakdown.

Stage 2 of 5
  • How to verify this →

    Test procedureLog in with each prepared test account before the engagement starts to confirm it works at the intended privilege level.

    Practical example / evidenceCredential handover sheet (shared securely) listing accounts and privilege levels.

  • How to verify this →

    Test procedureCheck the notification email or ticket went to ops/security/on-call with the exact test window and source IPs.

    Practical example / evidenceSent notification (email/ticket) with timestamp and recipient list.

  • How to verify this →

    Test procedureConfirm the SOC/monitoring team acknowledged the briefing and tagged the tester's source IPs as expected traffic.

    Practical example / evidenceSOC acknowledgment or allow-list entry for tester IPs.

Stage 3 of 5
  • How to verify this →

    Test procedureCheck the kickoff notes name a specific person (not a team alias) responsible for triage.

    Practical example / evidenceKickoff meeting notes or RACI naming the remediation owner.

  • How to verify this →

    Test procedureConfirm the contract or SOW includes a scheduled retest window, not an open-ended 'we'll get to it'.

    Practical example / evidenceSOW clause or calendar booking for the retest window.

Stage 5 of 5

Frequently asked questions

How often should we run a VAPT?

An annual penetration test alone is increasingly insufficient — most teams now pair an annual deep assessment with continuous or quarterly lighter-touch testing and automated scanning in between.

What's the difference between black-box and grey-box testing?

Black-box testing simulates an attacker with no prior knowledge of your systems; grey-box gives the tester some internal knowledge (like valid credentials), simulating an insider or a post-compromise scenario — useful for testing deeper, not just perimeter, defenses.