The Ultimate Penetration Testing Checklist

A penetration test is only as good as its preparation and its coverage. The difference between an engagement that finds the flaw that would have caused a breach and one that produces a tidy report nobody acts on usually comes down to a handful of decisions made before, during, and after the test. This checklist walks through every stage so nothing important gets missed, whether you are commissioning your first test or tightening up a mature program.

Use it as a working document: copy the sections that apply, and treat each item as a question to answer rather than a box to tick blindly. It also works as a yardstick: hold any vendor’s pentest methodology against it. Ours is on our pentest methodology page.

1. Pre-engagement and scoping

Most failed engagements fail here, not in the testing. Get this right and the rest follows.

• Define why you are testing. Compliance driver, proactive investment, or a specific concern? The trigger shapes everything. If you have not scoped one before, our guide on how to scope your first penetration test breaks it down.
• List what is in scope. Specific applications, domains, IP ranges, cloud accounts, or mobile apps. Be precise.
• List what is explicitly out of scope. Systems you cannot risk, third-party platforms you do not control, anything needing special handling.
• Choose the testing types. Web application, API, external network, internal network, cloud, mobile, hardware penetration testing, thick-client desktop apps, on-site wireless and physical tests, or a combination. Match them to your real attack surface.
• Decide the perspective. Black box (no prior knowledge), grey box (some credentials and context), or white box (full access and source). Grey box usually gives the best value for money.
• Agree the rules of engagement in writing. Permitted techniques, testing windows, escalation contacts, and what happens if a critical flaw is found mid-test.
• Confirm authorization. Written permission from someone who owns the systems, and from your provider if you host on a third party.
• Set the timeline. Any hard deadline (audit, customer deal, renewal) and any blackout windows to avoid.

2. Reconnaissance and mapping

Before exploitation comes understanding. A tester who maps the target thoroughly finds more than one who rushes to attack.

• Enumerate the full attack surface. Every domain, subdomain, endpoint, port, and service, not just the obvious front door.
• Map application roles and workflows. How authenticated and unauthenticated users move through the system, and where trust boundaries sit.
• Inventory technologies and versions. Frameworks, libraries, servers, and third-party components that may carry known vulnerabilities.
• Identify data flows. Where sensitive data enters, rests, and leaves, so testing concentrates where a breach would actually hurt.

3. External and internal network coverage

A network test has two halves: the perimeter the internet sees, and the internal network behind it. Confirm both are covered. Outside, that means every public IP, domain and service found, management interfaces and edge devices tested, and remote access logins checked for weak passwords and missing MFA, with each finding proven rather than exported from a scanner. Inside, from a foothold agreed in writing, it means name-resolution poisoning and relay, the Active Directory paths to Domain Admin, lateral movement, and segmentation tested from the other zones rather than read from the diagram.

Our network penetration testing checklist breaks both halves into line-by-line checks, and the network penetration testing guide explains each phase. Wireless is tested on site, so we scope it as its own engagement. If only the domain needs review, an Active Directory security assessment covers that part on its own.

4. Web application and API checklist

This is where most application findings come from. Coverage should reflect the OWASP Testing Guide and real attacker behavior, not a generic scanner run. Our guide to web application security testing covers the methods, and the API penetration testing checklist goes deeper on APIs. For mobile apps, work through the OWASP Mobile Top 10 2024 as well. Make sure the engagement covers the classes that actually lead to breaches:

• Injection. SQL, command, LDAP, and template injection where untrusted input reaches an interpreter.
• Broken access control and IDOR. Whether one user can reach another user’s data or actions, the single most common serious web finding.
• Broken authentication and sessions. Weak credentials, missing or bypassable MFA, and insecure session handling.
• Cross-site scripting (XSS). Reflected, stored, and DOM-based script injection.
• Business logic abuse. Legitimate features used in unintended ways, which scanners cannot find.
• Security misconfiguration. Insecure defaults, verbose errors, exposed panels, and unpatched components.
• APIs behind the app. The API layer is a favorite target and deserves its own authorization and data-exposure testing.
• The network underneath. The servers behind the application get the checks in section 3: external network penetration testing of the perimeter and, where in scope, internal network penetration testing for lateral movement.
• Cloud and infrastructure. For cloud-hosted systems, add cloud configuration and identity testing.
• Chaining. The best findings connect several small issues into one real impact. Confirm your tester chains, not just enumerates.

5. Exploitation and validation

• Prove real impact. Each finding should demonstrate exploitability, not just flag a theoretical risk. “This endpoint returns extra fields” is weak; “this call sequence exports the customer database” is a finding.
• Test safely. Destructive tests are avoided or scheduled; production is handled with agreed safeguards.
• Escalate criticals immediately. A serious flaw should reach you the same day, not wait for the final report.
• Document evidence as you go. Reproduction steps, requests, and screenshots captured while the issue is live.

6. Reporting

A report you cannot act on is wasted spend. Confirm it includes:

• An executive summary written for non-technical stakeholders.
• Technical findings with reproduction steps an engineer can follow.
• Risk ratings mapped to CVSS and, better, to business impact.
• Prioritized remediation guidance, not just a list of problems.
• Evidence for each finding.
• Compliance mapping if the test supports SOC 2, PCI DSS, HIPAA, or ISO 27001. A report your auditor recognizes saves weeks. See what a real one looks like on our sample report page.

7. Remediation and retest

The engagement is not done when the report lands. It is done when the fixes are verified.

• Prioritize by real risk, using the report’s ratings and your own business context. Our guide to vulnerability remediation covers how to turn that ranking into fix deadlines.
• Fix at the root, not just the reported symptom, so the same class of flaw does not reappear.
• Retest the remediated findings. A good engagement includes a complimentary retest, so your final report shows verified fixes rather than open issues.
• Feed lessons back to engineering so the patterns that caused the findings stop being written.
• Set a cadence. Testing is a snapshot; your environment changes constantly. Most organizations test annually, and after any major change. See our thinking on security between penetration tests.

The short version

If you remember nothing else: scope deliberately, insist on manual testing that chains findings and proves impact, demand a report an engineer can act on, and always retest the fixes. That is the difference between a compliance checkbox and a test that actually makes you harder to breach.

If you want a fixed-scope, fixed-cost engagement that runs this checklist end to end, scope your assessment and we will send back a proposal built around your real attack surface.