How to prepare
for a pentest

Why preparation matters#

A penetration test is paid for in specialist days. How many of those days go into actual testing, and how many are lost waiting for access, clarifying scope and finding the person who can approve something, is decided before the start. In our practice, the first day of an unprepared test goes almost entirely on accounts and approvals.

The NCSC, the UK’s cyber security authority, describes a penetration test as a way to gain assurance that a system withstands an attempt to breach its security, not as the primary means of finding vulnerabilities ¹. The difference matters for preparation: assurance is sought for a specific objective, and the objective decides everything else.

1. The objective, before the scope#

A test ordered “so we have a report” and one ordered “to find out whether someone can reach customer data” look different from day one. Put the objective in one sentence, and the provider builds the plan around it:

• compliance with a specific framework (PCI DSS, ISO 27001, DORA, Law 48/2023);
• checking a release or a major change;
• a customer’s or partner’s requirement;
• measuring detection: whether the team sees the attack and responds.

2. The scope, in writing and complete#

The NCSC recommends that scoping ends with a document stating, among other things, the technical boundaries of the test ¹. In practice, the document covers:

• the domains, subdomains and IP addresses in scope — and, explicitly, those excluded;
• the applications and APIs, with their version and environment;
• who owns each system: if hosting is with an external provider, you need its consent;
• integrated third-party systems — payments, identity — that are not tested without their consent.

3. Production or a copy#

Testing in production gives real results, but needs precautions and an agreed window. For some organisations it is not optional:

A pre-production copy removes operational risk, provided it is identical: the same versions, firewall rules and authentication setup — otherwise you are testing a system that does not exist. Data matters just as much: an environment with three records does not allow testing authorisation between customers. Prepare a realistic, anonymised dataset.

4. How much information to give the tester#

In practice there are three options: black box — the tester starts with no information, like an outside attacker; grey box — they get test accounts and basic documentation; white box — they also get access to code or configurations. The NCSC warns that a lack of information can leave vulnerabilities undiscovered in the time allocated ¹. In our practice, grey box gives the most per paid day; black box makes sense only when you want exactly an outside attacker’s view.

5. Accounts and access#

• Two accounts for each user role: the OWASP test for insecure direct object references (IDOR) checks whether one user can reach another’s objects, which needs at least two users ⁷⁸.
• Accounts that do not expire or lock after a few failed attempts.
• MFA sorted out in advance — otherwise the first day goes on SMS codes.
• VPN access or addresses allowed in the firewall, if the test is internal.
• Documentation: the architecture diagram, API specification, list of roles. It need not be pretty, it needs to be correct.

6. Rules of engagement#

The rules of engagement say what the tester may and may not do. Without them, a legitimate testing action can trigger an incident procedure or a contractual issue with the hosting provider.

7. The people#

Three roles, with names and phone numbers: a technical contact who can fix blocked access the same day, a decision-maker who can approve extending the scope or stopping the test, and an emergency contact available out of hours. Decide too whether the operations team is told: if not, the test also measures detection, but someone in management must know.

On the provider’s side, the NCSC recommends that third-party tests be carried out only by qualified and experienced staff ¹. Ask for the testers’ names and certifications before signing.

Preparation checklist, by test type#

Each type of test needs something different. Pick yours and tick what you already have; the list comes with you into the quote request.

8. What comes after the report#

A report delivered without time set aside for remediation stays a document. The NCSC recommends that the report include a way to resolve each issue found, but notes that risk assessment and the decision to apply fixes remain the organisation’s ¹. Plan from the start:

1. Report walkthrough

   A session where the technical team asks the testers directly.

2. Remediation window

   Development capacity booked for the period after the test.

3. Retest

   Written confirmation that issues were closed; the PCI guidance also describes a separate retest report ².

4. Keeping the results

   PCI DSS requires keeping test results and remediation for at least 12 months (11.4.1) ³.

Frequently asked questions