Preparing for a pentest: a checklist for your team
A pentest does not start on the first day of testing. Most delays happen before that: test accounts that don't work, a firewall that blocks the tester after ten minutes, a scope that turns out to shift halfway through. You pay for testing days, so every hour the tester spends waiting is an hour nobody is testing. Below you can read how a pentest with Resync runs from first contact, and what your team arranges in advance.
Agree on what gets tested and what doesn't, set up working test accounts for every role, make a deliberate choice between production and staging, get written authorisation and appoint one point of contact. That covers most of the preparation. We go through the rest in the intake, so you don't have to figure anything out on your own.
Why preparation saves testing time
A pentest is bought in testing days. Every hour the tester waits for an account, VPN access or an answer comes out of the time spent actually testing. On a multi-day test that is annoying. On a test of one or two days it can cost a large share of the coverage.
Preparation also determines how deep the test goes. A tester with only one account cannot check whether user A can reach user B's data. And that kind of authorisation flaw has topped the OWASP Top 10 for years. Get the access right, and you get a test that goes further than the front door.
How a pentest runs, from first contact
Every multi-day penetration test follows the same path. The Launch Check is booked directly online and has its own, shorter route.
- Reply within one business day
You get in touch
Through the contact form, by email or by booking an intake straight away. A few sentences about your application and the reason for the test are enough. If you have a deadline, such as an audit or a customer waiting for a report, mention it right away. It drives the schedule.
- Day 1
Free 30-minute intake
We discuss what needs testing, why, and what stays out of scope. Think of: which applications and environments, which user roles exist, how login works and who the report is for. After the intake you know whether and how I can help, even if the answer is that you don't need a pentest right now.
- Day 2–3
Fixed-price quote
You receive a quote with the scope, the schedule and a fixed price, retest included. Before any technical details are shared, we sign an NDA.
- Between sign-off and start
Preparation
Once you sign off, we schedule the start, usually within one to two weeks. In that time your team takes care of the checklist below: scope, access, test accounts, authorisation and agreements.
- Week 1–2
The test
I test manually, within the agreed scope and test windows. During that period you have direct contact with me, with no account manager in between. If I find something critical, such as a flaw that lets outsiders retrieve customer data, I report it immediately rather than waiting for the report.
- End of week 2
The report
You receive a report with an executive summary and technical findings with reproduction steps, prioritised by impact and exploitability. The report is digitally signed, so you, a customer or an auditor can check for yourselves that it is genuine. Questions about a finding go straight to the tester. Curious what such a report looks like? See the sample pentest report.
- Post-patching
Remediation and retest
Your team fixes the findings. I then test again to confirm the fixes work, and you close with a retest statement you can share with customers, your board or a regulator. The retest is included in the price.
From intake to report, a multi-day pentest typically takes one to three weeks, depending on scope. For large or complex environments that can run to four or five weeks. You receive an exact schedule after the intake.
Is a pentest on the roadmap, or is a customer or auditor waiting for a report? In a free 30-minute intake we pin down scope, schedule and price.
Book a free intake →The checklist for your team
Your team arranges the points below between sign-off and start. Not everything applies to every test. If you are unsure about a point, we discuss it in the intake.
1. Scope and goal
- Exactly which systems. URLs, APIs, IP addresses or IP ranges. "Our web application" is too vague. "app.example.com and the API at api.example.com" is a scope.
- What is out of scope. Think of third-party systems, such as a payment provider, an email service or an external customer portal. I don't test those without the owner's permission.
- The reason. An audit, a customer, a release or an incident. The reason determines where the emphasis lies and who the report is written for.
- Documentation that already exists. An OpenAPI or Swagger specification, a Postman collection or a short explanation of the roles. You don't need to write anything specially: whatever exists already helps.
2. Access and test accounts
- At least two accounts per role. With two accounts in the same role, I can test whether users can reach each other's data. With one account, I can't.
- Accounts in two tenants for multi-tenant software. The biggest risk of a SaaS platform is customer A seeing customer B's data. That can only be tested with accounts in two different customer environments.
- Accounts that work on day 1. Log in with every test account yourself the day before. An expired password or an account that still needs activating can easily cost half a testing day.
- MFA as in production. Keep multi-factor authentication switched on the way your real users have it, and agree how I receive the codes. If MFA is off on the test accounts, I am testing a situation that doesn't exist in real life.
- Share passwords securely. Not in the same email as the username, and not in a ticket. We agree on a secure channel in the intake.
- VPN, IP filter or WAF. If the application sits behind a VPN or an IP filter, arrange access for my test IP address in advance. With a WAF you make a deliberate choice: if you want to know how the application itself responds, allowlist the test IP. If you want to know what the WAF stops, leave it on.
3. The environment: production or staging?
Both work, but it is a choice you make up front, not during the test.
| Staging or test environment | Production | |
|---|---|---|
| Advantage | No risk to real users or data, so more intrusive tests are possible | Exactly the configuration an attacker sees |
| Drawback | Often differs from production: another version, other settings | Care needed with tests that change data or generate a lot of traffic |
| Choose this if | The environment matches production in code and configuration | There is no representative test environment, or the infrastructure itself is in scope |
If you test on staging, make sure it holds no real personal data. Under the GDPR that is wise anyway. If you test on production, take a backup beforehand and agree which actions are off-limits, such as sending emails to real customers or placing real orders.
4. Authorisation and agreements
- Written authorisation. Breaking into systems without the owner's permission is a criminal offence in the Netherlands and most other countries, even with good intentions. So put in writing what may be tested, by whom and when. If your application is hosted or managed by an external party, you may need their permission as well.
- Cloud platforms. AWS, Microsoft Azure and Google Cloud don't require prior approval for most services, but they do have testing rules. With a managed hosting provider it is often different. Ask.
- Test windows. May testing happen during office hours, or only outside them? Are there moments when it really doesn't suit, such as a release or a peak in usage?
- What is off-limits. Denial of service is not part of a regular pentest. Also agree whether data may be changed or deleted, and how to handle features that trigger emails, text messages or payments.
5. People and communication
- One point of contact. Someone who can answer questions quickly or pass them on, and who is reachable during the testing days.
- A technical contact. A developer or administrator who knows how the application fits together. Five minutes of explanation can save hours of searching.
- Inform your IT operations, SOC or hosting provider. Otherwise a pentest looks like a real attack, with a blocked IP address or an incident report as a result. If you specifically want to test whether your detection works, that is a deliberate choice we agree on up front.
- An emergency phone number. For the rare case that something goes wrong, or a critical finding can't wait.
6. After the test
- Plan capacity for remediation. A report without time to patch just sits there. Reserve development time for the weeks after delivery.
- Decide who reads the report. The executive summary is for the board and customers; the technical findings are for the team that will patch.
- Schedule the retest. The sooner you fix, the sooner you have a retest statement for the customer or auditor asking for one.
Test accounts that don't work on the first testing day, and a security layer that blocks the tester without anyone knowing. You prevent both with fifteen minutes of work: log in with every test account yourself the day before, and let your administrator know when and from which IP address the testing will happen.
What you don't need to do
Preparation is not a project in itself. A few things you can safely skip:
- Fixing everything first. A pentest is not an exam you need to pass. You can report known issues in advance. The testing time then goes to what you don't know yet.
- Running a scanner yourself first. You can, but it is not a requirement. The manual test focuses on what a scanner doesn't find: logic, authorisation and combinations of small weaknesses.
- Writing documentation. What exists is enough. If something is missing, I will ask for it in a short conversation.
- Rearranging your team's schedule. Apart from a point of contact and a technical contact, your team will notice little of the test.
Conclusion
A good pentest starts with good preparation, and that is less work than it seems. A clear scope, working test accounts for every role, a deliberate choice of environment, written authorisation and one point of contact: that covers most of it. The result is a test in which every day is a testing day, and a report that goes deeper than the front door. Unsure about any of the points? We go through them together in a free intake.
Frequently asked questions
Does a pentest have to take place on the production environment?
Not necessarily. A staging environment is safer and allows more intrusive tests, but only if it matches production in code and configuration. If it doesn't, or if the infrastructure itself is in scope, production is the better choice, with clear agreements on what is and isn't allowed.
How many test accounts does a pentester need?
At least two per user role, so it can be tested whether users can reach each other's data. For multi-tenant software you also need accounts in two different tenants, to test whether customers are separated from each other.
Do I need to inform my hosting provider about a pentest?
Often, yes. AWS, Microsoft Azure and Google Cloud don't require prior approval for most services, although testing rules apply. With a managed hosting provider, or an external supplier of part of your environment, it is different. Check in advance whether they need to give permission and whether their monitoring expects a heads-up.
How long does it take from first contact to report?
You get a reply within one business day and a quote within a few days of the intake. The start usually follows within one to two weeks of sign-off. The test and report then typically take one to three weeks, depending on scope. The retest follows as soon as you have fixed the findings.
Start well prepared.
In a free 30-minute intake we settle scope, test accounts and schedule, so the first testing day is a testing day from the start. Fixed price, retest included.
Book free intake →