How to Prepare for a Penetration Test

The single most common reason a test delivers less than it could is not the tester and not the scope. It is that the first day and a half went on access. Everything below exists to stop that happening.

The five things to have ready

1. Working accounts, one per role, tested the day before. Not "we will create them on the morning". Log in as each of them yourself and confirm they work from outside your network. If multi-factor is enforced, decide how the tester enrols, because a code going to somebody else’s phone stops a day dead.
2. The environment decided and named. Production or a staging copy, and if staging, an honest statement of how it differs. Different data, stubbed integrations and a WAF that is off in one and on in the other all change what a test means.
3. A named contact who is actually available. Not a shared mailbox. Somebody who can answer at four in the afternoon and can authorise a rollback if something goes wrong.
4. Written authorisation. Signed by somebody with the authority to grant it, naming the targets and the window. If any system is hosted by a third party, check whether their terms require notice.
5. Allowlisting decided. If a WAF or rate limiter sits in front, decide deliberately whether the tester works through it or around it. Both are legitimate; which one you chose belongs in the report.

Two decisions to make in advance

How much do you tell them? A black-box test simulates an outsider with no knowledge and spends days rediscovering your architecture. A grey-box test hands over documentation and accounts and spends those days testing instead. Unless you are specifically exercising your detection capability, grey box finds more per day, and most buyers who ask for black box are paying for reconnaissance they already had the answers to.

Does your operations team know? An unannounced test is a legitimate exercise of your monitoring. An accidentally unannounced test is an incident, with somebody paged at 2am and a scramble that costs more than the test. If you want the detection exercise, plan it as one and tell exactly one person.

What to tell your own team

Engineering needs to know the window and that spikes in errors are expected. Support needs to know so a customer report of odd behaviour is triaged correctly. Whoever watches the logs needs to know unless you are deliberately testing them.

Say plainly that the point is to find problems, and that finding them is a good outcome rather than a verdict on anybody’s work. Teams that believe they are being audited hide things, and a test where somebody quietly excluded the service they are worried about is worth much less than the invoice.

Get the scope conversation right

Five answers move an estimate more than anything else: how many distinct user roles, whether the application changes state or only reads, how much is bespoke versus framework, how many external integrations, and whether an API is in scope separately from the interface in front of it.

Answer those honestly, including the parts that make the number bigger. A test scoped against an optimistic description finds less, runs over, or quietly stops at the boundary of what was described.

Data, and what you are handing over

A test against a system holding real customer data means a tester will see real customer data, and that has consequences beyond the engagement. Decide in advance whether the environment can be populated with realistic but synthetic records instead, because it removes a whole category of problem at the cost of some fidelity.

Where it cannot, agree what evidence may be captured. The usual answer is that proofs are built against records the tester created themselves, and access to real ones is described rather than screenshotted. Ask what the firm holds afterwards, for how long, and how it is deleted. A firm that has not thought about this will say so by hesitating.

The week before

• Log in as every account you have supplied, from outside your network, and confirm each works.
• Check the accounts will not expire or lock during the window.
• Confirm any allowlisting is in place and tested, not merely requested.
• Take a backup of anything the test could plausibly alter, and know how long a restore takes.
• Tell support and operations the window, unless you are deliberately testing detection.
• Confirm the named contact is not on leave. This happens more than you would think.

Prepare for the results, not just the test

Decide before the report arrives who owns remediation, what your internal severity thresholds mean in days, and whether there is budget for a retest. Reports that sit unread for six weeks are almost always reports nobody had been assigned to receive.

And agree what happens if something critical is found mid-test. The tester should tell you immediately rather than saving it for the report, and you should know in advance who they call.