Penetration Testing Checklist 2026: Before, During & After
Most "penetration testing checklist" content online is really a methodology outline written for testers, not a checklist written for the person coordinating the engagement. This one is for the latter: what to have ready before testing starts, what a competent tester is actually checking during each phase, and what to verify once the report lands — whether you're running this in-house, buying it from a vendor, or evaluating one.
Before: scoping and preparation
Most engagement delays and disputes trace back to something that wasn't nailed down before testing started. Confirm these before a tester touches anything:
Written scope — exact domains, IP ranges, applications and environments that are in bounds, and an explicit statement of what's excluded.
Written authorization — signed rules of engagement confirming you're legally permitted to test the in-scope systems, especially critical if any of them run on third-party infrastructure.
Third-party notification — your cloud provider, CDN, or hosting partner may require advance notice before testing against infrastructure they manage.
Testing window and blackout periods — agreed dates/times, and any periods to avoid (peak traffic, a release freeze, a sensitive business event).
A point of contact available during testing — someone who can be reached if the tester finds something urgent or needs a decision made quickly.
Destructive-action boundaries — explicit agreement on whether denial-of-service testing, data deletion, or production database writes are permitted.
Test accounts and credentials — if authenticated testing is in scope, provisioned accounts at each relevant privilege/role level.
A target framework — know upfront which compliance standard (if any) the report needs to map to, since that shapes what "done" looks like.
During: what a tester actually checks
The specifics vary heavily by surface — a web application test and a network test check very different things — but across most engagements, a competent tester is working through something close to this list, verified with real exploitation attempts rather than pattern matching alone:
| Category | What's being tested |
|---|---|
| Authentication | Weak password policy, credential stuffing resistance, session fixation, multi-factor bypass |
| Authorization & access control | Cross-user data access (BOLA/IDOR), privilege escalation, role boundary enforcement |
| Input validation | Injection (SQL, command, template), XSS, deserialization, every entry point — forms, headers, file uploads, API parameters |
| Business logic | Workflow bypasses, price/quantity manipulation, race conditions, flows that assume good-faith use |
| Configuration | Verbose error disclosure, missing security headers, default credentials, exposed debug endpoints |
| Session management | Token entropy and expiry, logout invalidation, concurrent session handling |
| Known vulnerability classes | Mapped to OWASP Top 10, CWE, and framework-specific CVE history |
| Chained attack paths | Whether individually low-severity issues combine into a critical outcome |
The last row is the one automated scanning structurally can't do well — chaining requires judgment about what a specific combination of findings actually enables, not just a list of what each one is individually.
"A checklist tells you what got tested. It doesn't tell you whether anything on it was actually exploited — that's what the report has to prove."
After: evaluating the report
Scope matches what you expected. Confirm the tested assets line up with what was agreed — a narrower-than-expected scope is the most common source of post-test surprise.
Each finding has evidence. Reproduction steps, a request/response pair, a screenshot — not just a severity label and a generic description.
Severity reflects real exploitability. A raw CVSS score without business context can both overstate and understate actual risk — check that severity accounts for what the finding actually enables in your environment.
Remediation guidance is actionable. Specific to your stack, not a generic "patch the vulnerability" line.
A retest is scheduled. A fix marked "done" without verification is a belief, not a confirmed fact — retesting is what converts it into one.
Framework mapping is present if you need it. Check the report ties findings to the specific standard (OWASP, PCI-DSS, ISO 27001, SOC 2) your audit actually requires.
Checklist vs. methodology
Worth being precise about the distinction: this checklist is a coordination and evaluation aid for whoever is commissioning or managing a test. A methodology — like PTES (the Penetration Testing Execution Standard) or the OWASP Testing Guide — is the structured technical process a tester actually follows to conduct the engagement: reconnaissance, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting. The checklist helps you participate in and judge a test well; the methodology is what's actually being executed behind it. See our full methodology for how we structure ours.
Where ComplyArmor fits
Every item on the "after" checklist above is a default, not an upsell, with ComplyArmor's Smart PTaaS: every finding ships with reproduction evidence, is verified by a human tester before it reaches your report, maps to OWASP Top 10, ASVS, PCI-DSS, ISO 27001 and SOC 2, and includes retesting as part of the engagement. See our attack surface coverage and PTaaS page for how scoping and continuous testing work in practice.
Frequently asked questions
What should I prepare before a penetration test?
A clear, written scope of in-bounds assets, written authorization to test them, a point of contact available during testing, a list of anything that should be excluded or treated carefully (payment processing, production databases, safety-critical systems), and advance notice to any third party whose infrastructure sits in scope, such as a cloud provider or CDN.
What does a penetration tester check during a web application test?
Authentication and session management, authorization and access control (including cross-user/BOLA checks), input validation across every entry point (forms, headers, file uploads, API parameters), business logic flaws, known vulnerability classes mapped to the OWASP Top 10, and configuration issues like verbose error messages or missing security headers — tested with actual exploitation attempts, not just pattern matching.
What should I check once I receive a penetration test report?
Confirm the scope tested matches what you expected, check that each finding includes reproduction steps or evidence (not just a severity label), prioritize remediation by actual exploitability and business impact rather than CVSS score alone, and schedule retesting to verify fixes before marking anything closed.
Is a penetration testing checklist the same as a methodology?
No. A checklist is a practical preparation and verification aid for buyers and teams coordinating a test. A methodology (such as PTES or OWASP's testing guide) is the structured technical process a tester follows to actually conduct the engagement. The checklist helps you participate in and evaluate a test; the methodology is what the tester is executing.
How often should I run through a penetration testing checklist?
At minimum, before every scheduled or triggered engagement — annually for most compliance-driven testing, and after any significant change to the system. Teams running continuous or PTaaS-style testing should still revisit scope and preparation checks periodically, since what counts as in-scope tends to drift as new features and infrastructure get added.
If you're preparing for your first engagement and want a second set of eyes on scope before you send an RFP, that's a quick conversation worth having early rather than after the report lands.