How to prepare
for a penetration test
Everything settled before day one — scope, access, rules, contacts — and why each skipped item costs a paid day of testing.
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 hunting for the person who can approve something — that is decided before the start. This guide walks through exactly what to prepare, in the order that matters.
1. Set the objective, not just the scope
A test ordered "so we have a report" and one ordered "to find out whether anyone can reach customer data" look different from day one. State the objective in one sentence: compliance with a specific framework, validating a release, answering a customer requirement, or measuring detection capability. The provider builds the plan around that sentence.
2. Define the scope, in writing and completely
- The list of domains, subdomains and IP addresses included — and, explicitly, those excluded.
- The applications and APIs in scope, with their version and the environment they run on.
- Who owns each system: if hosting is with a third party, you need their consent.
- Integrated third-party systems — payment processors, identity services — that cannot be tested without their consent.
3. Choose the environment: production or a copy
Testing in production gives real results but requires precautionary rules and an agreed window. A pre-production copy removes the risk, provided it is identical in configuration — otherwise you are testing a system that does not exist. If you choose the copy, verify three things: same versions, same firewall rules, same authentication configuration.
Data matters just as much: a test environment with three records does not allow verifying authorisation between customers. Prepare a realistic, anonymised data set.
4. Prepare accounts and access
- Two accounts per user role — authorisation between same-level users can only be tested with two accounts.
- Accounts that do not expire and do not lock after a few failed attempts.
- Multi-factor authentication sorted out in advance — otherwise day one goes into SMS codes.
- VPN access or firewall allow-listing, if the test is internal.
- Documentation: architecture diagram, API specification, role list. It need not be pretty, it needs to be accurate.
5. Write the rules of engagement
The rules of engagement are the document stating what the tester may and may not do. It is not a formality: without it, a legitimate testing action can trigger an incident procedure or, worse, a contractual problem with a hosting provider.
| Item | What is agreed | Why it matters |
|---|---|---|
| Testing window | Days and hours when testing may run | Avoids impact on users at peak traffic |
| Excluded techniques | Usually DoS, data deletion, attacks on staff outside hours | Protects continuity and people |
| Stop criteria | What triggers an immediate stop and who decides | A real incident during the test must be told apart from the test |
| Immediate reporting | Which severity is reported on the spot, not in the final report | A critical vulnerability does not wait two weeks |
| Tester source addresses | The IPs the test traffic comes from | Lets the team separate the test from a real attack |
| Data handling | What data may be extracted, how it is stored, when it is deleted | A GDPR obligation, not an option |
6. Name the people
You need three roles, with names and phone numbers: a technical contact who can unblock access the same day, a decision-maker who can approve scope extension or stop the test, and an emergency contact available out of hours. Also decide whether the operations team is informed — if not, the test also measures detection, but someone in management must know.
The checklist, in short
- The objective, written in one sentence.
- Complete scope, with explicit exclusions and hosting provider consent.
- Environment chosen and confirmed identical to production, with realistic data.
- Two accounts per role, non-expiring, with MFA sorted.
- Architecture documentation and API specification, sent before the start.
- Signed rules of engagement, with stop criteria and tester IPs.
- Three named contacts, with out-of-hours availability.
- The remediation window and re-test date, agreed up front.
Frequently asked questions
How long does preparing a penetration test take?
Usually one to three weeks from signature to day one, and most of that goes into creating accounts and obtaining consent from external hosting providers. If you already have the scope documented, accounts ready and rules of engagement agreed, it can start within days.
Should I tell the internal team a test is happening?
It depends on the objective. If you want to measure detection and response capability too, the operations team is not told — otherwise the result says nothing about how they would react to a real attack. If the objective is strictly finding vulnerabilities, informing the team saves time and avoids false alarms. In both cases, at least one person in management and the emergency contact must know.
Is the test run on production or on a test environment?
Both options are valid, with different trade-offs. Production gives real results but requires an agreed window and precautionary rules. A pre-production environment removes operational risk, but only if it is identical to production in versions, firewall configuration and authentication mechanisms — otherwise you are testing a system that does not exist in reality. Data matters just as much: an environment with three records does not allow testing authorisation between customers.
Why does the tester need two accounts per role?
To test authorisation between same-level users — the class of flaws where one customer can view or modify another customer’s data by changing an identifier in a request. It is one of the most common and most costly problems in real applications, and it cannot be checked with a single account, no matter how much time the tester has.
What happens after the report is delivered?
Three stages follow, all of which should be planned up front: a walkthrough meeting where the technical team can question the testers directly, a remediation window for which you have already reserved development capacity, and a re-test that confirms in writing that the issues were closed. Without the last stage, the compliance file stays incomplete and remediation remains a claim.
Related guides
- What a pentest costs — what drives the price, how effort is estimated, and what makes two quotes comparable.
- DORA & TLPT — digital operational resilience in finance and threat-led penetration testing.
- ISO 27001 & SOC 2 — which controls require technical testing and what evidence the auditor accepts.
- Moldova’s Law 48/2023 — the national cybersecurity framework: who is in scope and what obligations it brings.
- OWASP Top 10 — the ten web risk categories, explained with examples and what gets tested in each.
- PCI DSS 4.0 — requirements 11.3 and 11.4, segmentation testing, and what it means for payment processors.
- Pentest vs vulnerability scanning — what each one finds, what it misses, and what auditors accept as evidence.
This material is informational. Concrete preparation requirements differ by test type and organisational environment.
Ready to start?
Book a free consultation: we walk the preparation list together and settle scope, rules and timeline.