Pentest Checklist

Pentest Checklist - End-to-End Penetration Testing Planning Checklist

Skill Overview

Pentest Checklist is a complete penetration testing planning and execution checklist that helps security teams and enterprises systematically prepare, conduct, and follow up on penetration testing projects from scratch. It covers the entire workflow, including scope definition, environment preparation, team selection, test monitoring, and vulnerability remediation.

Applicable Scenarios

1. Enterprise Security Assessment Planning

When a company needs to perform an annual security assessment, compliance-focused security testing (e.g., requirements such as 等保, PCI-DSS, GDPR), or a pre-IPO security review, this skill provides a full project-planning framework. It helps define the testing scope, select testing types (external testing, internal testing, web application testing, social engineering testing, or red-team exercises), and ensure that all legal authorizations and cloud provider permissions are in place.

2. Penetration Testing Project Preparation

Before officially starting a penetration test, use this skill to complete environment preparation: decide the testing environment (production, staging, or cloned environment), run pre-scans to fix obvious vulnerabilities, freeze code deployments, notify cloud providers (AWS/Azure/GCP), configure log monitoring and IDS/IPS, prepare test accounts, and verify backup availability—so the testing process does not disrupt normal business operations.

3. Vulnerability Remediation and Follow-Up Verification

After the penetration test ends, this skill provides a complete remediation follow-up workflow: analyze the test report and prioritize vulnerabilities by risk level, assign remediation owners, plan remediation time windows, avoid ad-hoc fixes during the test (maintain environment consistency), create a remediation verification plan, clean up test accounts and residual artifacts, and plan the next testing cycle (annual/quarterly/continuous testing).

Core Functions

1. Five-Stage Test Framework

Break the penetration testing project into five clear stages: scope definition (define goals, test type, threat surface, budget), environment preparation (environment selection, pre-scanning, compliance review, provider notification), expert selection (assess qualifications, define methodology, agree on report format), real-time monitoring (deploy IDS/IPS, centralize logs, trigger anomaly alerts), and remediation follow-up (prioritize vulnerabilities, implement fixes, verification testing, environment cleanup). Each stage includes detailed check items and operational guides.

2. Guidance on Test Types and Methodologies

Clearly distinguish the application scenarios and coverage areas of five common test types: external penetration testing (public-facing attack surface), internal penetration testing (internal network threats), web application testing (application-layer vulnerabilities), social engineering testing (people-focused security), and red-team exercises (end-to-end adversarial operations). It also provides recommendations for choosing black-box, gray-box, or white-box testing, and a comparison reference for mainstream testing standards (PTES, OWASP, NIST) to help the team select an appropriate testing strategy based on real needs.

3. Risk Control and Compliance Assurance

Includes a complete set of risk control mechanisms: alternatives for testing production environments (staging/clone), restrictions on DoS testing, cloud provider authorization request workflow (including links to AWS/Azure/GCP official policies), legal authorization document requirements, sensitive data handling guidelines, recommendations to freeze development during testing, test account management rules, and a post-test environment cleanup checklist. This ensures security testing activities are legal and compliant and do not affect business continuity.

Common Questions

What preparations are needed before a penetration test?

Pre-penetration-test preparation includes five key steps: first, clearly define the test scope and objectives—decide which systems, IPs, domains, and applications to test, and specify what is excluded; second, obtain formal written authorization, including management approval and permission from cloud providers (e.g., AWS, Azure); third, prepare the test environment—prefer staging or cloned environments. If production testing is unavoidable, set strict restrictions and avoid business peak hours; fourth, run initial vulnerability scans and remediate obvious issues to avoid wasting time on known vulnerabilities; fifth, configure monitoring and log collection to help distinguish test activities from real attacks.

How do you define the scope and boundaries of a penetration test?

Defining penetration test scope requires planning from multiple dimensions: first, clarify the testing goals—whether to find vulnerabilities, meet compliance requirements, or obtain customer certification; second, list all assets included in the test, including IP ranges, domains, web application URLs, and mobile apps; also specify items excluded—such as third-party systems, production databases, or critical business services that cannot be interrupted; finally, agree on testing methods and constraints—such as whether DoS testing is allowed, whether social engineering testing is required, and the permitted testing time windows. It is recommended to record all of this information in formal authorization documents, and any scope changes must be confirmed in writing.

Can penetration testing be performed in a production environment?

Penetration testing can be performed in a production environment, but additional risk controls are required: prioritize testing during low-traffic periods or non-business hours; clearly define testing restrictions, such as prohibiting DoS attacks, prohibiting large data exports, and prohibiting actions that impact user experience; ensure complete backups and a rapid recovery plan; strengthen real-time monitoring and be ready to interrupt testing at any time; communicate thoroughly with the operations team to ensure test activities can be distinguished from real attacks; and if possible, test first in staging or a cloned environment, then execute on a limited number of production instances after verification. For high-risk operations, strongly recommend using non-production environments.

What should a penetration testing report include?

A complete penetration testing report should include the following core sections: an executive summary for management that outlines the high-risk vulnerabilities found, business impact, and the overall security posture; a technical findings section that details each vulnerability, including CVE identifiers, CVSS scores, reproduction steps, screenshots/evidence, affected assets, and remediation recommendations; a risk assessment table sorted by severity for all findings; a methodology section describing the testing standards used (e.g., OWASP, PTES) and the test scope; and finally, provide remediation verification guidance explaining how to verify that the fixes are effective. It is also recommended to provide machine-readable formats (e.g., CSV, XML) to facilitate importing into vulnerability management systems.

How often should penetration testing be conducted?

The frequency of penetration testing depends on several factors: regulatory requirements (e.g., PCI-DSS requires annual testing and testing after major changes), the speed of business changes (organizations with frequent product releases need more frequent testing), risk tolerance (high-sensitivity industries require denser testing), and past test results (if severe vulnerabilities are found, retesting should be done as soon as possible after remediation). Generally, it is recommended to perform comprehensive penetration testing at least once per year, and conduct targeted tests after major system changes, new application launches, or security incidents. Organizations with suitable resources can consider continuous testing approaches, such as vulnerability reward programs or quarterly rolling assessments.