Pentest readiness checklist
Everything to have in place before a web application or API penetration test window opens, from the reviewer's requirements to test accounts, environment freeze, signed authorisation and agreed retest terms.
Most lost testing time comes from things that could have been sorted out the week before: an admin account nobody created, a VPN rule nobody requested, a staging build three releases behind production. This checklist is meant to catch them.
Work through it once when you start scoping and again a few days before the window opens. Each item has a short reason attached, so you can decide what applies to your application rather than ticking boxes. Not every item fits every test. A single-tenant internal tool has no tenants to isolate, and a test with no external reviewer has fewer documents to plan. Where something does not apply, write that down in the scope rather than leaving it blank. An unanswered field reads as unknown, not as excluded.
How to use it
- Software companies testing their own product can run through the list with the engineering lead and whoever owns the customer security review.
- Agencies testing a client’s application should pair this list with the agency client handoff checklist, which covers authorisation, report routing and attribution between agency and client.
- Anyone preparing an AI feature should also work through the AI feature launch checklist.
Notes
Completing the checklist does not authorise testing. Testing starts only once a written scope is agreed and the system owner has signed an authorisation. Do not put credentials, private target details or existing findings into an enquiry form. Those are exchanged through a channel agreed once the engagement is set up.
For the reasoning behind the inventory items and the trade-offs between environments and testing approaches, read how to scope a web application and API penetration test. When you are ready, start a scope.
Purpose and audience
- Write down why the test is needed and who will read the report.An enterprise reviewer, an auditor and an internal release gate each need different coverage and deliverables.
- Ask any external reviewer or auditor for their scope, recency and provider requirements in writing.Discovering a missed requirement after testing usually means commissioning a second engagement.
- Decide which documents you expect to share, such as a full report, a shareable summary or a coverage record.Deliverables have to be agreed before testing so the engagement produces them.
- Name the internal owner who will triage findings and approve risk acceptance.Findings without an owner stay open, and reviewers read open findings with no status as a red flag.
Inventory
- List every web front end and API in scope, with base URLs and a one-line purpose for each.A domain name alone does not tell the tester what the application does or where its boundaries are.
- Provide a current API specification, or state that none exists.Undocumented endpoints have to be discovered before they can be tested, which consumes testing time.
- Write a short permission matrix of what each role can and cannot do.Authorisation testing checks behaviour against intended permissions, so the tester needs to know the intent.
- List integrations, webhooks and third-party services, marking which are in scope and which are excluded.Third-party platforms usually need their own permission to test, and exclusions must appear in the report.
- Identify the critical workflows, such as invitations, password reset, payments, exports and role changes.Manual effort goes where abuse would hurt most, rather than being spread evenly across low-risk pages.
Accounts, tenants and data
- Create at least one test account per role, and two in the roles that matter most.Horizontal access, where one user reads another user's records, cannot be tested with a single account.
- Set up at least two test tenants, each with its own admin and standard user.Cross-tenant isolation is one of the first things enterprise reviewers look for in a multi-tenant product.
- Populate each tenant with realistic synthetic records, files and transactions.Empty tenants hide object-reference flaws because there is nothing to try to reach.
- Settle MFA handling for test accounts and record any exemption in the scope.Accounts the tester cannot log into turn grey-box testing into black-box testing.
- Agree a secure channel for credential transfer, separate from email and enquiry forms.Credentials in email threads or documents outlive the engagement and widen exposure.
Environment
- Confirm which environment will be tested and record how it differs from production.Configuration drift can make findings fail to transfer and lets real issues go unseen.
- Freeze or tag the build for the testing window.Deployments mid-test make findings hard to reproduce and fixes hard to attribute.
- Arrange IP allow-listing or VPN access if the environment is restricted.Blocked access on day one loses testing time that cannot always be recovered.
- If production is in scope, list off-limits actions, testing hours and rate limits.Explicit limits keep testing from sending real emails, charging real cards or disturbing customers.
Authorisation and contacts
- Agree a written scope covering assets, roles, tenants, environment, methods and exclusions.The report refers back to the scope, so readers who missed the scoping call can see what was covered.
- Obtain signed authorisation from the system owner before any testing starts.Testing without the owner's written permission can be unlawful, and no enquiry or quote substitutes for it.
- Check hosting, cloud and other platform testing policies, and record what applies.Some platforms restrict test types or require notice, even for resources you own.
- Name a stop contact who can be reached throughout the testing window.Someone with authority must be able to pause testing if something unexpected happens.
- Agree how critical findings are reported while testing is still running.A serious issue should reach the owner through an agreed route rather than waiting for the final report.
Deliverables and retest
- Confirm the report contents, coverage record and any readout in the proposal.Clear deliverables avoid disputes over what the engagement was meant to produce.
- Agree which findings a retest covers, how it is requested and what counts as new scope.Reviewers ask about fix status, and undefined retest terms leave that question open.
- Reserve developer time for fixes between the report and the retest.Without reserved time, remediation competes with feature work and the retest slips.
- Agree where evidence is stored, who can access it and when it is deleted.Test evidence can contain sensitive data and should not be kept longer than needed.
Get a fixed quote for your release.
A short form about the product and the deadline. We reply with scoping questions, then a fixed written quote.