One of the most common scenarios in pentesting practice: a company orders a test and needs the result as fast as possible, to pass an audit or for other reasons. Yet the first few days go not into finding vulnerabilities, but into sorting out access: getting into the test environment, figuring out which accounts were issued and why the database is empty.
The good news is that this can be avoided by preparing for the pentest in advance. What's more, the quality and depth of a penetration testing engagement depend not only on the pentester, but also on how well the client company has prepared beforehand. Here's a concrete checklist to go through before your next penetration test to get the best results in the shortest time.
What to check before a pentest
1. A test or staging environment as close to production as possible
That means an environment with realistic data volumes, not an empty one. A pentest on an empty test environment with, say, three test records gives a false sense of security: many vulnerabilities simply don't show up without a realistic volume and structure of data. For example, a SQL injection that runs in milliseconds and looks harmless with three users in a table can bring down the database for several minutes on a real dataset of a million rows. It's better to catch all of this in the test environment than to find out about it for the first time in production, at three in the morning, from the support team.
A note on terms. SQL injection is one of the most common web app vulnerabilities: it's when an application trusts user input so much that it inserts it directly into a database query, letting an attacker slip in their own command instead of the expected username or password.
2. Prepared test accounts for every role
A regular user, an administrator, guest access, a partner API key: the more roles you cover, the wider the field for testing access rights and ways to escalate them. Providing only one admin account "because that should be enough" is an approach worth reconsidering. The most interesting bugs, and the ones most costly for the business, are usually found right at the boundaries between roles, for example when a regular user suddenly gains access to someone else's account through a carelessly written endpoint.
3. Up-to-date API documentation
The client isn't obligated to provide this, but it significantly speeds up the mapping phase, the stage when pentesters study the structure of the application. Without documentation, this stage simply takes more time.
4. Defined critical business processes that should be checked separately
Payment, changing an email or password, deleting an account: these are exactly the points where logical vulnerabilities most often hide, the kind that automated scanning misses but an agent or a human review doesn't.
5. A designated point of contact
A critical vulnerability shouldn't have to wait until the results presentation, even when the pentest itself takes only four days. It needs to reach the developers for remediation the same day, because vulnerability remediation timelines have shortened dramatically now that AI-driven cyberattacks are the norm. That's why it's worth specifying in advance exactly who to contact if a critical finding needs to be closed immediately, without waiting for the final report.
6. An agreed testing window with the monitoring team
This matters so that SOC analysts don't mistake pentester activity for a real threat. Without this coordination, here's a scenario that can play out: the security team is woken up in the middle of the night, spends an hour tracking down an "attacker," and by morning finds out it was the pentest, running on a schedule that was simply never communicated to the SOC. No one was harmed, but the security team lost both time and sleep.
Why this actually matters
There's no magic here: companies that go through this checklist in advance typically get a deeper test for the same budget. A pentest isn't a box-ticking audit. It's a check whose result depends directly on preparation from both sides. The more clearly the task is defined and the better the environment is prepared, the sooner the pentest can be started, the fast you get the results. And the lower the risk that something critical to the company won't get checked the way it should be.
Not sure where to start preparing for a pentest? Book a discovery call with A42's technical team and get a free complimentary consultation.
