Preparing for Your First VAPT

Most of what determines whether a penetration test goes well is settled before it starts. The failure mode is not a bad tester — it is three days of a ten-day engagement spent waiting for an account that nobody provisioned.

This is the list, in the order it needs doing.

Decide what is in scope, and write down what is not

The scope is the list of what will be tested — applications, hosts, APIs, environments — and the perspectives that will be used.

The exclusions matter more than the inclusions. A scope that lists only what was tested is half a scope. Write down what was deliberately left out and why: a third-party payment page you cannot authorise, a production database, a system frozen for a release, a legacy application being retired in March.

That list is what you will be asked about later — by an auditor, by a customer's security questionnaire, or by your own team next year when nobody remembers why the payment path was omitted. "It was out of scope" without a reason reads as an oversight even when it was a decision. Which things are not yours to authorise at all is covered in what can and cannot be tested.

Pick the environment, and be honest about it

Three options, and the trade-off is real in each direction.

Production reflects reality — real data volumes, real configuration, real integrations. It is also the one where a mistake has consequences, so it needs agreement on timing, on destructive actions, and on what happens if something falls over.

A staging environment that mirrors production is the usual compromise, and it is a good one if it genuinely mirrors. The word doing the work there is "mirrors": same configuration, same integrations, same authentication, and enough data to be realistic.

An empty staging instance is the option that quietly wastes the engagement. An environment with three test records cannot exhibit most access-control flaws, because there is nothing to reach across to. If user A has nothing worth stealing, nobody can demonstrate that user B could steal it.

If staging differs from production in any way that matters — a disabled integration, a different authentication provider, a feature flag set the other way — say so up front. The tester will scope around it. Discovering it in the report is worse for everyone.

Provision accounts before day one

The single most common delay, and the cheapest to avoid.

Two accounts for every role in scope. Not one. Testing whether user A can reach user B's data requires a user B, and there is no way to work around its absence. One account per role turns the most likely serious finding into one that cannot be looked for.

Then, for each account:

• Test them yourself before handing them over. Log in. It takes a minute and it catches the majority of access problems.
• Disable or raise lockout thresholds for the test accounts. A policy that locks an account after three failed attempts will lock it within the first hour of testing, repeatedly.
• Check password expiry against the engagement dates.
• Decide about multi-factor. If it is enforced, the tester needs a workable second factor — a shared secret, a test device, or a documented exemption. This is worth deciding deliberately rather than discovering on the first morning.
• Populate the accounts with data. An account that has never done anything exercises very little.

Where the test includes an API, the same applies with an addition: accounts belonging to two different tenants or customers, because that is what object-level authorisation testing requires.

Name the people

One technical contact who can answer a question the same day, and one decision-maker who can be reached if something serious is found at four on a Friday.

Agree in advance what happens if the tester finds something critical mid-test: whether they stop and call, whether testing continues, and who is on the call. This conversation takes five minutes beforehand and is unpleasant to have improvised.

Tell the people who will see the traffic

Your monitoring team, your managed detection provider, your hosting provider. Otherwise someone spends a night responding to an incident that you paid for.

Two legitimate choices here, and it is worth making it consciously. Telling them tests the systems. Not telling them also tests whether anyone notices, which is genuinely useful information — but that is a deliberate exercise requiring at least one person in the loop, not an oversight.

If a web application firewall or rate limiter sits in front of the target, decide whether the tester works through it or is allowlisted around it. Both are defensible: through it tests your real deployment; around it tests the application. Discovering on day four that the firewall has been silently dropping requests is neither.

Check the calendar against your own

Against change freezes, releases, month-end and quarter-end processing, peak trading periods, and holidays in every location involved.

A test running during a code freeze finds issues nobody is permitted to fix. A test running the week of a major release competes for the same engineers. And a test scheduled to finish two days before an audit deadline leaves no room for the retest, which is the part the auditor actually wants.

Work backwards from the date you need the closure document, not forwards from when you are free.

Sort the paperwork early

The written authorisation is what separates a penetration test from an offence. It names the systems, the dates and the signatory, and it needs to exist before work starts — not be in legal review on the first morning.

Alongside it: a non-disclosure agreement, and — critically — written permission from any third party whose systems are in scope. Your cloud provider's policy, your hosting provider's agreement, and any SaaS vendor whose product falls inside the boundary. Being their customer does not make you able to authorise testing against them.

Allow more time for this than seems necessary. It is the step that most often moves a start date.

Gather what you already have

None of this is mandatory, and all of it converts discovery time into testing time:

• An API specification, even an out-of-date one — the gap between the specification and reality is itself a finding.
• A description of the roles and what distinguishes them.
• Notes on anything unusual: a bespoke signing scheme, a custom authentication flow, a multi-step process with a specific order.
• Which parts are new, and which parts you are already worried about.

That last one is worth saying out loud. Testers ask what keeps you up at night, and a straight answer directs attention where you already suspect it is needed. How much information to hand over is a scoping decision in its own right — see black, grey and white box testing.

Agree the retest before the test

Three questions, all cheap now and expensive later, when the findings are known and your leverage is gone:

• Is retesting included, or billed separately?
• How long does the window stay open — and does that survive your release cycle? A thirty-day window against a quarterly release will expire before the fix ships.
• Does the retest produce its own dated document?

That last one is what an auditor asks for, and "we fixed it" is not it. The full process is in retest, closure and the evidence that ends an engagement.

The short version

Scope written with exclusions. Environment chosen and described honestly. Two accounts per role, tested, with lockout disabled. Contacts named and an escalation path agreed. Defenders told. Dates checked against freezes and worked backwards from the deadline. Authorisation signed, including third parties. Documentation gathered. Retest agreed.

Nine items, most of them an afternoon's work. They are the difference between buying ten days of testing and buying seven days of testing and three days of waiting.

What those days cost is in what moves the price of a penetration test; how the scope gets counted is in how a VAPT scope gets sized.