Before you request a quote
- Decide what question you want answered. "Can someone reach our customer data from the internet?" produces a better engagement than "test us".
- Identify why you are testing — compliance deadline, customer questionnaire, insurance renewal, or genuine assurance. It changes the scope and the deliverable.
- Inventory what is in scope: applications, external hosts, internal ranges, cloud tenants, AD domains. Rough numbers are enough to get a quote.
- Confirm you have authority to authorise testing on every asset, including anything hosted by a third party — you will need their written permission too.
- Check with your auditor, if compliance is the driver, what scope they expect. Get it in writing before you buy.
- Set a realistic timeline that leaves room to remediate before your deadline, not just to test before it.
Scoping the engagement
The most common and most expensive scoping mistake is spreading a fixed budget across everything you own, which produces shallow coverage of many things instead of real coverage of what matters. Depth on the systems that would actually hurt you beats breadth every time.
The second most common is excluding the systems you are most worried about because you fear the results. Those are precisely the ones to include.
- Prioritise by blast radius — what would genuinely hurt if it were compromised?
- Include your identity provider and SSO. Compromise there compromises everything downstream.
- Decide authenticated versus unauthenticated testing. Authenticated testing across each user role finds substantially more, and reflects reality since attackers phish credentials.
- Be explicit about what is out of scope and why, and record it.
- Decide whether this is a blind test or a coordinated one. Blind tests also test your detection capability; coordinated tests find more vulnerabilities per hour.
Do not "clean up" before the test
Patching frantically the week before testing is understandable and self-defeating. You are paying to find out what your environment actually looks like on a normal day. Test the real thing, then fix what is found.
What to prepare for the testers
- Test credentials for each user role, delivered through a password manager or an encrypted channel — never email.
- API documentation if you have it: OpenAPI, Swagger or Postman collections dramatically improve API coverage.
- Network diagrams and an asset list for internal engagements.
- A named technical contact who can answer questions quickly during the test.
- A named emergency contact reachable outside business hours who has authority to halt testing.
- Allowlisting decisions — whether testing source IPs should bypass your WAF. Testing both with and without is ideal; if you only do one, test without, since that reflects reality.
Rules of engagement
This is the document that keeps a test from becoming an incident, and it should be signed before anything runs. At Security Arsenal the signed statement of work is the testing authorisation — not a checkbox in a form.
- Approved testing windows and any blackout dates or change freezes.
- Prohibited techniques — denial of service, account lockout, and anything destructive are commonly excluded.
- Stop conditions: what should cause testing to pause, such as domain admin being achieved or sensitive data being reached.
- What happens if a third-party environment is reachable — stop immediately, prove reachability then stop, or continue only with written authorisation.
- Who gets notified at start and stop, and how findings will be communicated if something critical is found mid-test.
- Data handling: how evidence is stored, how long it is retained, and how it is destroyed at close-out.
Who to tell inside your organisation
If your security team does not know a test is happening, they will respond to it as a real incident — which is either a valuable exercise or an expensive waste of a weekend, depending on whether you meant it.
A common and sensible middle path is to inform only a small number of people, so detection and response are genuinely exercised, while someone senior can confirm activity is authorised the moment escalation begins. Whatever you choose, decide deliberately and write it down.
After the report arrives
- Read the executive summary as a leadership team, not just as a security team.
- Triage by exploitability and business impact, not by CVSS score alone — a medium on your payment path outranks a high on a static marketing site.
- Assign owners and dates to every finding you intend to fix, and record a decision for the ones you do not.
- Use the included retest. Documented closure is what auditors, customers and underwriters actually want to see.
- Feed findings into your detection engineering — every proven attack path is a detection you should now have.
- Ask what patterns keep recurring. Three injection findings in three years is a secure-development problem, not three bugs.
Want a number before you talk to anyone?
Our instant estimator prices your actual environment using the same model our quoting process uses. No email required to see the figure.