How to prepare for your first penetration test: the checklist

You bought a penetration test. The date is booked. What you do in the two weeks before it determines whether you get a report worth reading or two weeks of the tester asking basic questions. This is the checklist we send clients, published so everyone benefits.

1. Decide what actually matters

Write down the three systems whose breach would genuinely hurt: the payments flow, the customer database, the admin panel. A pentest scoped around your real risk beats a broad test of everything. If everything feels critical, nothing is; that is what the threat modeling conversation is for.

2. Prepare the environment (not a perfect one)

• Test accounts: one standard user, one privileged, one with unusual permissions
• Documentation that exists: architecture diagrams, API docs, even rough ones
• Source access if you bought code review, otherwise not needed
• A staging environment that mirrors production closely, or written permission to test production

Do not patch everything the week before. We are testing what you actually run, not a freshly cleaned showcase.

3. Tell exactly the right people

For a pentest: your engineering leads and your SOC should know the window, so our scanning does not trigger an incident response. For a red team: as few people as possible, ideally two. Announcing a red team exercise to the whole company defeats the entire point.

4. Prepare the rules of engagement

Signed before day one: what is in scope, what is explicitly out, working hours if production is involved, the kill-switch contact, and what evidence handling looks like. Any serious firm insists on this; it protects you as much as us.

5. Plan for the findings emotionally

There will be findings. Some will be embarrassing. The correct internal framing, announced by leadership before the report lands: findings are the product. A report with zero findings usually means the test was shallow, not the code was perfect. Teams that punish engineers for findings get teams that hide findings.

The report is not the deliverable. The fixed, retested, closed findings are the deliverable.

6. Block time after, not just during

Reserve engineering time in the two weeks after delivery for remediation, and hold your vendor to the included retest. Findings age like milk: the CVSS 9 you fix this month is a different animal from the one you fix next quarter.

Quick pre-flight summary

• Top three risk systems identified and scoped
• Test accounts and environment ready
• Right people informed, wrong people not
• Rules of engagement signed
• Leadership has set blame-free expectations
• Remediation time reserved, retest booked

Want this tailored to your stack? Book a free scope call and we will hand you the exact version of this list for your environment.