Prepare for a penetration test: a checklist for your team

If you want to prepare for a penetration test, the most useful work happens before the testers touch your app. A penetration test is a security test where someone tries to find and prove weaknesses in your system, with your permission, so you can fix them first. Good preparation means the time goes on your real risks instead of on login problems and scope questions. This checklist shows you what to get ready, and what the report should look like when it comes back.

Why preparation decides what a test finds

Every test has limits: what is in scope, how long the testers have, and what they can reach. The OWASP Web Security Testing Guide lists the usual limits a report should name, and most of them are things you control: areas left out of bounds, broken functionality, slow answers to questions, not enough time, and missing access or credentials.

Each of those quietly shrinks the test. If the admin test account arrives late, the admin side gets less attention. If staging is half broken, testers spend their time working around it. Preparation is how you make sure the test covers the parts of your system you actually worry about.

How to prepare for a penetration test, step by step

Name your biggest worry. One sentence is enough: "customers seeing each other's data", "someone getting free access to paid features", "our AI assistant leaking documents". This shapes where the testers go deepest.
Write the scope. List the web addresses, APIs and apps that are in scope, and say plainly what is out of scope, such as systems run by your payment or email providers.
Pick the environment. A staging copy that matches production is usually best. Note anything that differs, such as a feature that is switched off.
Create test accounts for every role. At least two ordinary users, so testers can check whether one can reach the other's data, plus each admin or staff role.
Load realistic test data. Use made-up records that look like the real thing. Never load real customer data into a test environment.
Share what you already know. API documentation, a list of user roles, and any issues you already know about. Testers should not spend their time rediscovering them.
Name a contact. One person who can answer questions, reset accounts and fix a broken environment quickly.
Tell the people who need to know. Your hosting team, monitoring and on-call staff should know a test is planned, so alerts are expected rather than alarming.

A worked example: scoping a small web app

Say you run a scheduling app for clinics, with a web app, a mobile app and one API behind both. You are about to launch, and your worry is one clinic seeing another clinic's bookings. Your scope note might read:

In scope: the web app at staging.yourapp.test, the API at api.staging.yourapp.test, and the mobile app's calls to that API.
Out of scope: your payment provider's and email provider's systems, and production.
Accounts: two clinic admins at two different test clinics, two receptionists, and one patient account per clinic.
Focus: data separation between clinics, the booking and cancellation flow, and the admin pages.
Known issues: password reset emails are slow on staging; the export feature is switched off.
Contact: one named engineer who can reset accounts the same day.

That one page answers most of the questions a tester would otherwise ask, and it points them straight at the risk that matters most to you. The two clinics and two accounts per role are what let them test the separation properly. The pre-launch checklist for sign-in and payments is a good way to fix the obvious issues yourself first, so the paid test can go deeper.

Manual depth and automated breadth

Ask how the test will be run. The OWASP guide puts it simply: automated tools give breadth and manual testing gives depth. Scanners are good at known patterns across many pages. They lack the context of your application, so they struggle with business logic flaws, such as a receptionist cancelling another clinic's booking or a discount code being applied twice. Your worry list from step one is mostly business logic, which is why it should guide the manual part.

If your product includes an AI assistant, say so in the scope. Testing it involves different checks, which our guide to prompt injection testing explains.

What a good penetration test report contains

The OWASP guide's reporting chapter describes a structure that works for readers on both sides of the business. Use it to check the report you receive.

Scope, limitations and timeline. What was tested, what was not, and anything that held the test back.
A point-in-time disclaimer. The report reflects the system when it was tested. It cannot promise that every issue was found.
An executive summary. The goal of the test, the key findings in business terms, and broad recommendations, written without jargon.
A findings summary. A table of every finding with its risk level, such as Informational, Low, Medium, High or Critical, with the scale explained.
Finding details. For each one: a reference ID, a title, how likely it is to be exploited, its impact, its risk, a clear description, and specific steps to fix it.
Masked sensitive data. Passwords and personal details in evidence should be hidden.

OWASP also advises securing and encrypting the report, so only you can read it. A report that lists problems without fix steps, or ranks everything as critical, is harder to act on.

What to do when the report arrives

Read the summary together. Product and engineering should agree on what matters most.
Turn each finding into a ticket. Keep the reference ID in the ticket so you can match fixes to findings.
Fix by risk, not by ease. Critical and high findings first, even if a low one is quicker.
Add a test for each fix. An automated check that would have caught the issue stops it coming back.
Ask for a retest. According to OWASP, a retest report should show the updated status of each earlier finding. That is your evidence the fixes worked.

When to bring in an outside tester

You can work through much of this list yourself. An outside test adds a pair of eyes that did not build the system, and a written record you can show customers who ask how you tested.

That is what whitehatstoic offers: hire the builder who also tests it. Its cybersecurity and AI safety testing covers web app and API review and prompt injection tests, ends with a written report and fixes, and includes a retest after the fixes. Testing is scoped after a short call. No test can promise to find every weakness, so the aim is to find the ones that matter and help you close them.

Frequently asked questions

Should we test staging or production?

Staging is usually safer, as long as it matches production closely. If anything must be tested in production, agree the limits in writing first.

Do we need to fix known issues before the test?

Fix the easy ones and list the rest in your scope note. That way testers can spend their time finding what you do not already know.

What if the report finds something critical?

Fix it first, add a test that would catch it again, and ask for a retest to confirm the fix works.

Is a penetration test the same as a vulnerability scan?

No. A scan is automated and broad. A penetration test adds manual work that follows your business rules and tries to prove what an attacker could really do.

Get started

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.