2026-07-19 · GUIDE · The Offensive Technology team

How to prepare for your first penetration test

Most of the value of a penetration test is won or lost before anyone touches a keyboard. A team that shows up to a vague scope, no test accounts, and a nervous engineering lead will spend the first two days on logistics instead of finding the things you paid them to find. If this is your first test, a few hours of preparation buys you a meaningfully better result. Here is the checklist we wish every first-time client had in front of them.

Know why you are testing

Everything downstream flows from this. Are you testing because a customer contract or an auditor demands it, because your insurer asked, or because you genuinely want to know how exposed you are? A compliance-driven test may have a scope dictated by the standard. A risk-driven test should aim at whatever would hurt most if it broke. Write your reason down in one sentence. It settles a dozen later arguments about what is in scope.

Define the scope, in writing

Scope is the single most important input. It is the list of exactly what the testers may touch: which domains, which applications, which IP ranges, which APIs, and which techniques are off the table. The open Penetration Testing Execution Standard (PTES) treats this pre-engagement step as its own phase for a reason, because a fuzzy scope produces a fuzzy test.

Be specific and be honest about boundaries. If a system is run by a third-party provider, you usually cannot authorize testing against it without their permission, and no reputable tester will hit it on your say-so alone. Decide what is in, what is out, and get it recorded and signed. That document, often called the rules of engagement, protects you as much as it protects the testers.

Pick the environment: production or staging

You will be asked whether to test against production or a staging copy. Both have tradeoffs.

Production is the real thing, so findings are real, but there is a small chance testing causes slowness or side effects. Good testers work carefully, but you should still expect and plan for it.
Staging is safer to hammer, but only useful if it genuinely mirrors production. A staging environment three versions behind, with fake data and different configuration, produces findings that may not apply to the system your customers actually use.

If you choose staging, make sure it is a faithful copy. A misleading environment is worse than a slightly risky one.

Prepare access and test accounts

If you want the test to cover what a logged-in user or customer can do, and you almost always should, the testers need working credentials. Unauthenticated testing only sees the front door. Most real damage happens behind a login.

Before the test starts, prepare:

User accounts for each role that matters: standard user, admin, and any tier in between.
More than one account per role, so testers can check whether one user can reach another user's data.
Any API keys, tokens, or documentation needed to exercise the application the way a real client does.
A note of anything that will trigger lockouts, billing, or emails, so nobody is surprised.

Sort out timing and communication

Agree on a testing window and who gets told. Name a single technical contact who can answer questions fast and who has the authority to halt the test with one message if something goes wrong.

Decide in advance what to do about your own defenses. If a web application firewall or monitoring system will block or alert on the testing traffic, you and the testers should agree whether to allowlist their source, since a firewall that simply blocks the test can hide the very weaknesses sitting behind it. Warn your operations and support teams so a burst of odd traffic does not spark a 3 a.m. incident call.

Have your documentation ready

Testers ramp faster when you hand them context. The OWASP Web Security Testing Guide, a widely used open methodology, treats information gathering as the foundation of a good test. You can shorten that phase by providing an architecture overview, API documentation, a list of user roles, and notes on anything unusual or fragile. You are not doing their job for them; you are making sure their time goes into finding problems, not rediscovering how your app is wired.

Resist the urge to tidy up

A quiet temptation before a first test is to quickly patch and clean everything so the report looks good. Do not. The point is to learn your real state, not to stage a clean room. Fixing known issues is fine and encouraged in general, but do not hide or disable things solely to dodge the test. You would only be paying to fool yourself.

Know what you are getting at the end

Confirm the deliverable before day one: a written report with ranked findings and clear reproduction steps, and ideally a call to walk through it. Ask whether a retest of your fixes is included or costs extra, because a finding is not closed until someone has confirmed the fix actually works.

A cheaper first step, if you are not ready

If a full penetration test still feels like a big first commitment, it is reasonable to start smaller and learn your external exposure first. That is what our $100 check is for: a focused look at your external attack surface, on scope you have verified you own and authorized in writing, reviewed by a senior operator and delivered with a 30-minute readout.

Be clear on what it is and is not. The check is a first look, not a full engagement, and it will not satisfy an auditor who asked for a penetration test. What it will do is show you what an attacker sees from the outside and help you scope the real test properly, so that when you do book one, you walk in prepared.