Methodology
The Penetration Testing Checklist
A checklist will never replace real expertise, but it catches the mundane gaps that even experienced teams occasionally miss under deadline pressure. This one is organized by phase.
Before the engagement starts
- Rules of Engagement signed, with explicit scope, exclusions, and testing window. See what a solid ROE includes.
- Named emergency contacts confirmed on both sides.
- Testing approach agreed: black box, gray box, or white box, and why. See the difference between them.
- Whether exploitation is authorized at all, and if so, whether it is confirmation-only or extends further.
During reconnaissance and detection
- Every target independently checked against scope before being touched, not assumed to be in scope because it looked related.
- Passive recon completed before active scanning begins against the same target.
- Findings recorded with severity and confidence, not just a description.
During exploitation and confirmation
- Every proposed exploit action reviewed by a named person before it runs, with the exact request, module, or payload visible, not summarized.
- Scope and the testing window re-checked at execution time, not just when the action was first proposed.
- Payloads restricted to what is actually needed to confirm a finding, never more destructive or persistent than necessary.
Every one of these steps should leave a record. A checklist followed with no
corresponding log entry is indistinguishable, after the fact, from a checklist that was never
followed at all. See tamper-evident
audit logs.
Before delivering the report
- Every finding mapped to a recognized framework, such as the OWASP Top 10, and to compliance controls if relevant.
- Confirmed findings clearly distinguished from possible or unconfirmed ones.
- Scope and exclusions restated in the report itself, not just in the original ROE.
- A retest plan agreed, if remediation verification is expected as part of the engagement.
See it in an actual tool
Shieldome Siege enforces scope on every action and gates exploit confirmation behind a human approval, with a tamper-evident audit log of the whole engagement.
Read the documentation