Penetration Test Preparation Checklist
A penetration testing checklist for small teams: define scope and rules of engagement, prepare accounts and environments, and plan how findings get fixed.
- Typical schedule annually
- The checklist 4 sections, 20 items
- Variables
{{vendor}}{{test_window}}
Use this checklist when you commission an external penetration test, whether a customer asked for it, an auditor expects it, or you are about to launch a major feature. Most of the value of a pentest is decided before the testers start: a vague scope, missing test accounts or a blocking firewall can waste days of paid time.
Who owns it
An engineering or security lead owns the run and is the single contact for the testing firm. Infrastructure staff prepare environments and allowlists. Someone with authority signs the rules of engagement. Adapt this to your jurisdiction and your hosting provider's terms; it is a practical checklist, not legal advice.
Common pitfalls
- Scope by domain name only. Testers need to know which apps, APIs, roles and environments matter, and which are off limits.
- Testing a system you do not own. Third-party SaaS and some managed services need the provider's permission, or must be excluded. Check your cloud provider's testing policy.
- No test accounts for each role. Most serious findings are about one user seeing another user's data. Testers need at least two accounts per role, in separate tenants.
- The security team blocks the testers. Decide whether to allowlist the testers' IPs, and tell on-call staff so alerts are not treated as a real attack.
- A report that sits in a drawer. Plan who fixes findings and book a retest before the test starts.
The checklist: Pentest with {{vendor}} in {{test_window}}
Scope and contract
-
Define the goal of the test: customer requirement, audit evidence or a new feature
-
List in-scope targets: applications, APIs, hostnames and IP ranges
-
List out-of-scope targets and techniques, such as denial of service or social engineering
-
Choose the approach: black box, grey box with accounts, or white box with code access
-
Confirm permission for every target, including third-party and cloud provider testing policies
-
Sign the rules of engagement and a confidentiality agreement with
{{vendor}}Include the test window, contacts, testing source IPs, stop conditions and how data is handled.
Prepare the environment
-
Decide whether to test production or a staging environment that matches production
-
Create test accounts for each role, in at least two separate tenants or organisations
-
Load realistic test data that contains no real personal data
-
Take a backup or snapshot of the target environment before
{{test_window}} -
Allowlist the testers' source IPs in the WAF or rate limits, if agreed
-
Share API documentation and architecture notes with
{{vendor}}optional
During the test
-
Inform on-call staff and monitoring providers about
{{test_window}}and the tester IPs -
Agree a channel for urgent findings that need immediate action
-
Monitor system health and stop the test if the agreed stop conditions occur
After the test
-
Receive the report and review findings with
{{vendor}}in a debrief call -
Create a ticket for each finding with an owner and a due date based on severity
-
Delete test accounts, test data and allowlist entries
-
Book a retest of fixed high-severity findings
-
File the report and the remediation status as audit evidence
Checklist as Markdown
Frequently asked questions
What should be in a pentest scope?
The scope lists the exact targets (applications, APIs, hosts and IP ranges), what is out of scope, the testing approach, the test window and any limits such as no denial-of-service testing. A good scope also explains which data and user roles matter most, so testers spend their time on the real risks.
Should we pentest production or staging?
Testing production gives the most realistic result, but carries some risk of disruption and touches real data. A staging environment that matches production is safer and often good enough. Many teams test staging for the application and production for the external network perimeter.
How often should a penetration test be done?
Many companies test once a year and after major changes to their application or infrastructure. Customers and auditors may ask for a specific interval. Between external tests, automated scanning and code review cover the everyday changes.
Updated