Scoping an External Attack Surface Check well makes the difference between a report that sits in a drawer and one that actually changes what your team prioritizes. This is the checklist we walk through with prospective clients before writing a proposal, useful whether you’re scoping with us or with anyone else.
1. Define the organizational boundary
Start with the entity, not the domain list. Does the assessment cover the parent company only, or subsidiaries and recent acquisitions too? Attackers don’t respect your org chart. If a subsidiary’s infrastructure is reachable and connected to anything you care about, it’s worth deciding, explicitly, whether it’s in or out of scope, rather than defaulting to “we’ll figure that out later.”
2. Decide how much you want discovered vs. confirmed
Some organizations want the broadest possible external footprint mapped, including low-confidence and speculative assets. Others want to focus tightly on known, high-value systems and use the assessment purely for validation. Neither is wrong, but be explicit about which one you’re asking for, because it changes both the deliverable and the price.
3. Clarify what “seed information” you’ll provide
A good outside-in assessment shouldn’t require internal access, credentials, or agents, but it’s still useful to agree upfront what starting information you’ll share: known domains, brand names, subsidiary names, and known IP ranges if you have them. This isn’t required for discovery to work, but it helps the assessor validate coverage and avoid wasting time on organizations that share your name but aren’t actually you.
4. Set explicit exclusions before anything starts
If there’s a system you don’t want touched (a fragile legacy platform, something a specific vendor manages exclusively, an environment mid-migration) say so before scope is finalized, not after testing has started. A written exclusion list, part of the Rules of Engagement, is what protects both sides here.
5. Agree what “validation” and “attack-path investigation” mean for this engagement
Ask directly: what happens when a candidate weakness is found? Does the provider stop at “this looks interesting,” or do they manually confirm it’s real and, where authorized, investigate whether it chains into something with actual business impact? This is the single biggest quality differentiator between a scan-and-forward service and a genuine assessment, and it’s worth confirming in the proposal stage, not discovering afterward.
6. Ask what happens with a critical finding mid-engagement
You shouldn’t have to wait for the final report to learn about something urgent. Confirm upfront that critical findings get escalated to you as soon as they’re validated, and get a named point of contact on both sides for that scenario.
7. Decide who needs to see the results, and in what form
A report written for a CISO and a report written for a compliance auditor emphasize different things. If you need the output to double as evidence for a customer requirement or an audit, say so during scoping. It’s much easier to structure the report correctly from the start than to retrofit it afterward.
8. Confirm the authorization step explicitly
No reputable provider should begin any testing, active or passive beyond public-source discovery, before a written scope, authorization, and Rules of Engagement document is signed by someone with the authority to grant it. If a vendor is willing to skip this step to move faster, treat that as a red flag, not a convenience.
Putting this into practice
If you’re ready to work through this with us, our Request Assessment form starts exactly this conversation. It asks for the organizational context above, and we use it to come back with a straightforward, itemized proposal rather than a generic package. You can see what a completed engagement produces on our sample assessment page, and what the investment typically looks like on our pricing page.