What a penetration tester needs from you before day one
The most common reason a test underdelivers is not the tester. It is that day one was spent waiting for credentials, day two on an allowlist request that needed a change approval, and day three on discovering that the test accounts were locked by a policy nobody could override. In a five day engagement that is over half the budget, and the report will say the same thing in more diplomatic language. Preparation is the part of the engagement you control completely, and it is worth a fortnight of attention.
Why do access delays dominate short engagements?
Because everything a tester needs sits with a different team, and none of those teams has the engagement in their plan. Accounts come from an application owner, network access from infrastructure, allowlisting from whoever runs the edge, cloud read access from a platform team, and each request travels through a change process sized for routine work rather than for a fixed five day window. The requests are individually small and collectively fatal.
The compounding factor is that testers cannot usefully work around a missing item. Without credentials for the second role, the horizontal access control testing simply does not happen, and it is not substituted with something else of equal value. Time lost at the start is not recovered later in the week, because the deep work depends on the access.
The measurable version of this: ask your supplier to record, in the report, how much testing time was lost to access issues. Firms that do this routinely will agree without hesitation. Seeing the number once tends to fix the problem permanently, because it converts an invisible cost into a line somebody has to explain.
What has to be ready before the start date?
The items below, with an owner named for each and a check that they actually work. The verification step matters more than the provisioning step: an account that exists but has not been logged into once is not ready, because first login is where the password change, the enrolment prompt and the policy block appear.
| Item | Usual owner | Lead time | If it is late |
|---|---|---|---|
| Accounts for every role, two per role | Application owner | Days, longer if approval is needed | No access control testing at all |
| Multi-factor exemption or shared enrolment | Identity team | Days, often needs a policy exception | Tester locked out of the accounts you provided |
| Source IP allowlisted at the edge and WAF | Network or platform team | Change window, so allow a week | Blocked traffic read as false negatives |
| API documentation and a working example call | Engineering | Hours if it exists | Days spent guessing parameters |
| VPN access or an internal jump host | Infrastructure | A week if hardware or a laptop ships | Internal test cannot start |
| Written authorisation and rules of engagement | You, plus any third party host | Days, longer with a managed provider | Test cannot lawfully begin |
| A named contact with authority to stop the test | You | None, but must be diarised | Nobody to call when something breaks |
What breaks on day one most often?
Multi-factor authentication on the supplied accounts, every time. The account is created, the enrolment is bound to a device the tester does not have, and resolving it needs someone with administrative rights in your identity provider. Decide in advance whether the tester enrols their own authenticator, whether a conditional access policy exempts their source addresses, or whether a shared enrolment is acceptable, and get it approved before the week starts.
After that: web application firewalls and rate limiting silently dropping test traffic, which produces the worst possible outcome because the tester sees no response and cannot distinguish a block from a fix. Bot protection and CAPTCHA on login flows, which stops authenticated testing dead. Single sign-on through a corporate identity provider that will not issue tokens to an external tester's session. And test data that is either absent, so nothing meaningful can be exercised, or is real customer data, which creates a problem of its own.
The pattern in all of these is that a control designed to stop attackers stops your tester, and you are paying for the tester. Decide deliberately which protections stay on. Leaving the WAF enabled is a defensible choice if you want to know what it blocks, but then the report must record that the test was conducted through it, so nobody later mistakes filtered traffic for an absent vulnerability.
What does a container or cloud test need specifically?
A landing position and read access to configuration. For a Kubernetes test the useful minimum is a way to obtain a shell in a workload in the target namespace, a kubeconfig with read permissions for the resources in scope, and access to the manifests or charts that define the deployments. Without a landing position the tester spends the engagement establishing initial access, which is the part you already assume is possible.
For cloud, a read-only role scoped to the accounts in scope changes what the same budget buys, because IAM policy, network configuration and storage permissions are answerable in minutes from configuration and take a day to infer from outside. Provision it as a dedicated role with logging enabled rather than by sharing an existing account, so what the tester did stays distinguishable in your audit trail afterwards.
Also supply the image registry and pipeline detail. The route from a compromised build to production is one of the shortest paths in a modern estate, and testing it needs to know which registry is authoritative, how images are signed or verified if they are, and which credentials the pipeline holds. If any of these questions has no clear owner, that is itself worth knowing before the test rather than during it.
Who needs to be available during the week?
One named technical contact who can answer questions the same day, one person with authority to halt the test, and an agreed escalation route for a finding severe enough that waiting for the report would be negligent. Critical findings should reach you within hours, and the mechanism for that should be agreed in advance rather than improvised, because an out-of-hours discovery with no route to a decision maker is a wasted advantage.
Decide who else knows. Briefing your monitoring team avoids a live incident response and lets them assist with access, at the cost of losing any read on your detection capability. Not briefing them tests detection, and should be a decision taken by someone senior enough to accept a disrupted day. Either is fine. Neither happening by default is not.
Consider a light change freeze on the systems in scope. Deploying midway through a test invalidates findings, wastes retesting effort and produces the confusing situation where a reported issue cannot be reproduced because the code moved underneath it.
What should you prepare that nobody asks for?
The ability to reset test data. Testing modifies state, and an environment where the tester is reluctant to submit anything destructive is an environment that gets tested cautiously. Knowing you can restore a dataset in an hour changes what the tester is willing to try, and cautious testing is not what you are buying.
Increased log retention for the window, and confirmation that logs actually capture what you would need after a real intrusion. A test is a rare opportunity to compare a known attack timeline against your own records, and the comparison is often more informative than the findings. If your logs cannot reconstruct what a tester did while you had the exact times and source addresses, they will not reconstruct an attacker.
Finally, a copy of the previous report in the tester's hands. Some buyers withhold it to avoid biasing the test. The stronger reason to share it is that recurring findings are the most important signal available about whether your remediation process works, and a tester who cannot see the last report cannot tell you that anything has recurred.
Common questions
- What do you need to give a penetration tester before the test?
- Accounts for every role with at least two per role, a resolution for multi-factor authentication on those accounts, your tester's source addresses allowlisted at the edge and in the web application firewall, API documentation with a working example call, network or VPN access for internal work, signed authorisation and rules of engagement, and a named contact with authority to stop the test. Verify each item by logging in before the start date.
- Why do penetration tests lose time to access problems?
- Because each item sits with a different team and travels through a change process sized for routine work rather than a fixed engagement window. Testers cannot substitute equivalent work when access is missing: without a second role account, access control testing simply does not happen. Ask your supplier to record time lost to access issues in the report. Seeing that number once usually fixes the problem for good.
- Should the web application firewall be disabled during a test?
- It is a deliberate choice either way. Leaving it enabled tells you what it blocks but risks the tester mistaking filtered traffic for an absent vulnerability, since a dropped request looks like a fixed one. Common practice is to allowlist the tester's source addresses so the application itself is tested properly, then separately confirm what the firewall would have caught. Whichever you choose, the report must state it.
- What access does a Kubernetes penetration test require?
- A way to obtain a shell in a workload in the target namespace, a kubeconfig with read permissions for the in-scope resources, and access to the manifests or charts defining the deployments. Without a landing position the tester spends the engagement proving initial access, which you already assume is possible. Add registry and pipeline detail, because the route from a compromised build to production is one of the shortest paths available.
- Should you tell your monitoring team about a penetration test?
- Briefing them avoids a costly live incident response and helps with access, at the cost of learning nothing about your detection. Not briefing them tests detection, which is valuable but should be authorised by someone senior enough to accept a disrupted day. The failure mode is neither deciding nor telling anyone, so a genuine response begins mid-engagement. Either way, agree an escalation route for critical findings in advance.
- Should you share the previous penetration test report?
- Yes, in almost all cases. The concern about biasing the tester is outweighed by the value of knowing whether findings have recurred, which is the single best available signal about whether your remediation process works rather than just closing tickets. A tester who has not seen the previous report cannot tell you that the same defect class has returned in a different component, which is the finding you most need.
