Urgent penetration testing › What we need before starting
When a test is booked three weeks out and then slips to five, the cause is almost always the same: something the tester needed did not arrive. Having the following ready when you first make contact is the single biggest thing you can do to compress a timeline, and it costs you nothing but an afternoon.
The scope, in specifics
Not "our external estate". A list.
- Public IP addresses or ranges, written out.
- Hostnames and URLs, including any staging or admin subdomain you want covered.
- For applications: the name, the number of distinct user roles, whether there is an API, and roughly how many endpoints.
- Anything hosted or operated by somebody else, flagged as such.
If you do not know your public IP count, say so early. A short discovery step resolves it in hours, but only if it is booked rather than discovered on the morning testing was supposed to start.
Authorisation for anything you do not own
If a target sits with a hosting provider, a SaaS vendor or a managed service partner, their written authorisation is needed as well as yours. This is the item that most often adds a week, because it involves somebody else's process.
Start it the day you decide to test. Most major cloud providers publish a testing policy that covers customer-owned workloads without a separate request; smaller hosts often need a ticket and a few days.
Credentials, if the test is authenticated
One working account per role, created and verified before the window opens, transferred securely rather than by plain email. Verified matters: accounts that exist but have never been logged into have a habit of being locked, unverified or missing a permission the role is supposed to have.
Say what each account is meant to be able to do. A tester finding that the "standard user" account can reach the admin panel is either a serious finding or a provisioning mistake, and knowing which one saves a day.
Rules of engagement input
The tester drafts it, but three decisions are yours.
- What must not be touched, and why.
- Any window to avoid: month-end, a release, an audit, a board meeting.
- Whether denial of service is in scope. The default should be no.
A named contact who can answer the same day
One technical person who knows the environment, can be reached during the window, and has authority to answer a scope question without convening a meeting. Plus an out-of-hours number for the critical that surfaces at six on a Thursday.
A shared mailbox is not a contact. Tests stall for days waiting on tickets in a queue.
The deadline, and what it is for
Tell the provider the real date and the reason. A tender submission, an insurance renewal, a customer audit and a board paper have different tolerances, and the reason changes what can sensibly be compressed.
A tender date is usually immovable and the report has to be complete. An insurer often accepts an attestation letter ahead of the full report. A customer audit sometimes only needs evidence that testing is scheduled. Knowing which you are in lets a provider tell you honestly whether the date works.
What this changes, in days
| Ready up front | Not ready |
|---|---|
| Scope listed in specifics | Adds 2 to 5 days of back and forth |
| Third-party authorisation in hand | Adds 3 to 10 days, outside anyone's control |
| Credentials created and verified | Adds 1 to 3 days, often mid-test |
| Named contact available | Adds 1 to 2 days per question raised |
| Exclusions decided | Adds a day and a change request |
Add those up and the difference between a prepared and an unprepared engagement is routinely two weeks, on a test that takes five days to run.
What cannot be compressed
Being honest about the other side of it. Testing days are testing days: five days of work does not become two because the deadline moved. Report writing takes the time it takes if the report is to be worth reading. And a retest cannot happen until you have actually fixed things.
What can be compressed is everything before testing starts, and that is usually where the weeks went.
A worked example: fourteen days to a report
To make the timeline concrete, here is what a genuinely compressed engagement looks like when everything is ready. This is achievable, and it is achievable only because nothing waits on information.
| Day | What happens |
|---|---|
| 1 | First contact with the scope already listed, the deadline stated and the reason given. Quote issued the same day because nothing needs clarifying. |
| 2 | Quote accepted. Rules of engagement drafted and returned with exclusions and the contact named. |
| 3 | Rules of engagement signed. Hosting provider authorisation already in hand from day one. |
| 6 to 10 | Testing, with the named contact reachable throughout. Any critical reported the day it is confirmed. |
| 11 to 13 | Report written and quality reviewed. |
| 14 | Report delivered, with an attestation letter for onward sharing. |
Now remove one item. If the hosting authorisation was not requested until day three, it arrives around day ten and testing starts on day eleven. The same engagement delivers in week four rather than week two, and nothing about the testing changed.
What to do if you are already late
Sometimes the deadline was always going to be tight. Three things help more than panicking.
Split the scope. Test the part that matters most first, deliver a report on that, and cover the rest afterwards. A complete report on eighty per cent beats no report on everything.
Ask what the deadline actually needs. An insurer will often accept an attestation letter confirming testing is underway. A customer audit sometimes needs evidence that a test is booked. Only a tender submission genuinely needs the finished report in hand, and knowing which you are in changes what is possible.
Tell the provider the truth about the date. A supplier who knows the real constraint can often restructure the engagement around it. One who is told a comfortable date and discovers the real one in week two cannot.
How quickly can a test realistically start?
With everything above ready, within a week is often achievable and occasionally within a couple of days for a contained scope. Standard lead time from agreed scope to testing is two to three weeks, and most of that is scheduling rather than preparation.
Can you test without credentials?
Yes, and an unauthenticated test is a legitimate exercise. It shows what an anonymous attacker sees. It will not show what a logged-in user can reach that they should not, which is where the more serious application findings usually are.
What if we cannot get third-party authorisation in time?
Those targets come out of scope and the test proceeds on what you do control. It is better to test eighty per cent on time than to miss the deadline waiting for a supplier, provided the report is clear about what was excluded and why.
Do you need production access?
Not always. Production gives the most accurate picture. A staging environment is safer but only useful if it genuinely mirrors production, which it often does not once you look at the data, the integrations and the configuration. We will discuss which is appropriate during scoping.
Ready to go?
If your scope matches one of the two fixed-fee tests, you can buy it now and skip the quoting step entirely. Anything wider, send it over.