Skip to main content
Gated pack · RFP skeleton · Scoring matrix · POC worksheet

An external exposure RFP and evaluation pack, with your name on it.

Four working documents: a requirements skeleton organised by capability area, a weighted scoring matrix with three vendor columns, a fourteen-day POC worksheet that settles what “found” means before anything runs, and the questions that separate vendors in this category. Written for the person running the evaluation — a security architect, an exposure or operations lead, a CISO’s deputy — and for the procurement colleague who ends up owning the scoring sheet.

The thinking behind it is free and stays free. Our evaluation guide publishes the criteria, the vendor questions and an honest account of what a fortnight cannot settle, because a buyer needs that during the project. The pack is the fillable version — the one you put your own company name on and send to three vendors — and that is the part we ask for an email address for.

Get the evaluation pack Read the ungated version

What is inside

Four documents, and not one of them a brochure

Each part is a sheet somebody on your side fills in. Nothing in the pack describes ShadowMap, nothing in it names a competitor, and none of it presumes an answer — the weights are blank, the criteria are editable, and the requirements are phrased against evidence a vendor either produces or does not.

What is in the External Exposure Platform RFP & Evaluation Pack
What you getWhat it isWhat you do with itWho fills it in
Requirements skeleton An RFP requirements schedule organised by capability area rather than by feature list — discovery and attribution, data and identity exposure, brand and impersonation, validation, vendor risk, and the operating layer that decides what gets worked first. Each requirement is phrased as something a vendor either evidences or does not. Paste it into your own RFP template, delete the areas outside your scope, and mark every surviving requirement essential or preferred before it goes out. The distinction is the one that later disqualifies rather than merely disappoints. Security architect
Requirements are written against evidence, not against features: “states which evidence tied each asset to our organisation” rather than “provides asset attribution”. A feature requirement is answered yes by every vendor in the category, which is why a feature matrix has stopped separating them. An evidence requirement is answered by fewer.
Weighted scoring matrix A scoring sheet with Vendor A, Vendor B and Vendor C columns, a weight against each criterion and a total that resolves to one number per vendor. The criteria are attribution quality, what a finding carries when it arrives, operational fit, validation posture, commercial and renewal terms, and what you take with you if you leave. Agree the weights with the panel before any proposal arrives, have each assessor score independently, then read the spread before the totals — the criteria your own panel disagrees about are the ones worth a second meeting. Procurement, with the panel
The weights ship blank on purpose. A vendor-supplied matrix carrying vendor-supplied weights is a vendor’s argument wearing a spreadsheet, and the first thing a competent procurement lead does with one is change the numbers. We would rather that happened in the first five minutes than in the readout.
Fourteen-day POC worksheet The scoping pages: apex domains, and the subsidiaries, acquisitions and trading names nobody keeps straight; the authorisation scope in writing, including what is out of bounds; the definition of “found”, agreed before anything runs; how a disputed finding gets validated and who arbitrates it; and what a pass looks like, in numbers written down first. Fill it in with the vendor in the room and both sides signing. Then run the fortnight against it, and reuse the same sheet for the second vendor so the two trials are actually comparable rather than two different experiments. Whoever runs the trial
Under-specify the seed list deliberately, and record which properties you are holding back. Finding them later counts as a result, rather than starting an argument about whether you had mentioned them — an argument nobody wins in the readout.
The separating questions The questions worth asking in this category, because they have real answers and the answers differ. Each carries what a weak answer sounds like, so an evasion is recognisable in the room rather than on the drive home. Ask them on the vendor call, or paste them into the RFP clarification schedule and read the written answers side by side. They work either way, which is the point of writing them down. Whoever runs the evaluation
Every one is a question we expect to be asked ourselves, and a serious competitor answers most of them. They are written against the evasion and never against a named vendor — the pack contains no competitor names at all, because a document with our competitive positioning in it is not a document you can put your own company name on.

What is in the External Exposure Platform RFP & Evaluation Pack

Requirements skeleton

What it is
An RFP requirements schedule organised by capability area rather than by feature list — discovery and attribution, data and identity exposure, brand and impersonation, validation, vendor risk, and the operating layer that decides what gets worked first. Each requirement is phrased as something a vendor either evidences or does not.
What you do with it
Paste it into your own RFP template, delete the areas outside your scope, and mark every surviving requirement essential or preferred before it goes out. The distinction is the one that later disqualifies rather than merely disappoints.
Who fills it in
Security architect

Requirements are written against evidence, not against features: “states which evidence tied each asset to our organisation” rather than “provides asset attribution”. A feature requirement is answered yes by every vendor in the category, which is why a feature matrix has stopped separating them. An evidence requirement is answered by fewer.

Weighted scoring matrix

What it is
A scoring sheet with Vendor A, Vendor B and Vendor C columns, a weight against each criterion and a total that resolves to one number per vendor. The criteria are attribution quality, what a finding carries when it arrives, operational fit, validation posture, commercial and renewal terms, and what you take with you if you leave.
What you do with it
Agree the weights with the panel before any proposal arrives, have each assessor score independently, then read the spread before the totals — the criteria your own panel disagrees about are the ones worth a second meeting.
Who fills it in
Procurement, with the panel

The weights ship blank on purpose. A vendor-supplied matrix carrying vendor-supplied weights is a vendor’s argument wearing a spreadsheet, and the first thing a competent procurement lead does with one is change the numbers. We would rather that happened in the first five minutes than in the readout.

Fourteen-day POC worksheet

What it is
The scoping pages: apex domains, and the subsidiaries, acquisitions and trading names nobody keeps straight; the authorisation scope in writing, including what is out of bounds; the definition of “found”, agreed before anything runs; how a disputed finding gets validated and who arbitrates it; and what a pass looks like, in numbers written down first.
What you do with it
Fill it in with the vendor in the room and both sides signing. Then run the fortnight against it, and reuse the same sheet for the second vendor so the two trials are actually comparable rather than two different experiments.
Who fills it in
Whoever runs the trial

Under-specify the seed list deliberately, and record which properties you are holding back. Finding them later counts as a result, rather than starting an argument about whether you had mentioned them — an argument nobody wins in the readout.

The separating questions

What it is
The questions worth asking in this category, because they have real answers and the answers differ. Each carries what a weak answer sounds like, so an evasion is recognisable in the room rather than on the drive home.
What you do with it
Ask them on the vendor call, or paste them into the RFP clarification schedule and read the written answers side by side. They work either way, which is the point of writing them down.
Who fills it in
Whoever runs the evaluation

Every one is a question we expect to be asked ourselves, and a serious competitor answers most of them. They are written against the evasion and never against a named vendor — the pack contains no competitor names at all, because a document with our competitive positioning in it is not a document you can put your own company name on.

The questions, since a vague contents list is worth nobody’s email

These are the six the pack leads with. Each arrives with what a weak answer sounds like, and every one already appears at length in the ungated guide — so listing them here costs us nothing and tells you whether the rest is worth your address.

  • Can you reprocess your own historical data when your extraction improves — or is the corpus we are paying for frozen at the quality of the day you collected it?
  • Do you publish the vocabulary your system uses to classify a finding, so that a verdict means the same thing next quarter as it does today?
  • What happens to a finding your AI judged benign? Is that decision visible, reversible and reviewable, or is the discarded pile simply gone?
  • Does detection terminate in removal, or in an alert — and if it is removal, who files, under whose authority, and is it metered?
  • Is active validation bounded to inventory you have attributed to us, inside a scope somebody signed?
  • Can we reconcile your activity against our own edge and WAF logs — source addresses, user agents, windows?

Get it

Editable, unbranded, and yours to issue

Enter a work email and we send a confirmation link. Click it and the pack downloads. There is no call to book, no field asking for your budget or your timeline, and no step where a person has to approve the request before the file is released.

The confirmation step is there because the ungated form on this site was handing files to anyone who typed an address, and most of those addresses were not real. It is a deliverability measure rather than a qualification gate — the pack is released to anybody who can read their own inbox, including the buyer who has already decided against us.

Change anything in it. Delete the capability areas outside your scope, reset the weights, put your own logo on the cover and issue it as your own document. A pack a procurement team cannot rebrand is a pack a procurement team cannot use.

External Exposure Platform RFP & Evaluation Pack

The requirements skeleton, the weighted scoring matrix, the fourteen-day POC worksheet and the vendor questions — all editable. We’ll email you a confirmation link; click it and the pack downloads.

By downloading, you agree to receive relevant communications. We respect your privacy.

Would rather not give an address? The whole argument is published ungated at /evaluate/, and you can rebuild the sheets from it in an afternoon.

The worksheet

A fortnight is the right length. Almost all of it is decided beforehand.

Fourteen days is long enough for a discovery pass to settle and for a second week to test whether the first was luck, and short enough that nobody’s attention has moved on. What decides whether the exercise produces an answer or an argument is almost entirely what got written down before day one — which is why the worksheet is mostly a pre-flight document and only partly a scoring one.

Fourteen-day POC

One fortnight, scoped before it starts

What the worksheet settles before day one
The apex domains you are certain about and the entities you are not. The authorisation scope in writing — what may be tested, from which source addresses, in which windows, and what is out of bounds, whether that is production at month end, anything a partner owns, or anything in a jurisdiction your legal team has not cleared. And the definition of “found”: does a parked domain count as an asset, does a credential from a six-year-old dump count as an exposure, does a look-alike domain that resolves nowhere count. All of it written while nobody yet knows which way the numbers will fall.
What it records while the trial runs
Assets discovered that your inventory did not hold, and which of the properties you held back were found without being named. Findings actioned, findings rejected, and the reason recorded against each. Median triage time in week one against week two. The findings you disputed, what evidence the vendor produced, who arbitrated and how it ended. The worksheet asks for disagreements to be logged rather than quietly resolved, because by the end of the fortnight that log tells you more than the findings do.
What it decides at the end
Whether the platform met the pass criteria you wrote down before it started, criterion by criterion, with the gaps named rather than averaged away. A trial scored after the readout is scored on the readout, and every vendor in this category is good at readouts. The sheet is designed so the decision is made against a page you filled in a fortnight earlier — including the honest entry where a criterion turned out to be the wrong thing to have measured.

How the matrix is scored

Five bands, published so your panel means the same thing by a seven

The most common way a weighted matrix fails is not the weights. It is five assessors quietly running five different scales, so the totals are arithmetic performed on incompatible numbers. The bands below are printed on the scoring sheet itself, and this is the one part of the pack worth reading before you download it — if your panel already has a scale it trusts, use that instead and change the sheet.

The scoring vocabulary printed on the weighted matrix
BandWhat the vendor actually producedWhat it scores, and what follows
Asserted only The vendor states the capability and produces nothing you could check — a datasheet line, a slide, a customer anecdote you cannot follow up. Score 1–3. Against a requirement you marked essential, this ends the evaluation for that vendor rather than costing it points.
Partly evidenced Some of the requirement is evidenced and some is asserted, or the evidence covers a neighbouring case rather than yours. Score 4–5. Record which half was evidenced — that note is what you go back to when two vendors finish level.
Evidenced The vendor showed the thing working, on their data or on a reference tenant, in enough detail that you could describe it to a colleague afterwards. Score 6–7. This is what a competent vendor in this category should reach on most criteria.
Evidenced and auditable The vendor showed it working AND handed you the underlying evidence — the attribution trail, the probe record, the export — so you could check the claim without asking them. Score 8–9. On attribution and validation this is the band that separates the category, which is why both criteria carry weight rather than being a checkbox.
Demonstrated on your estate It was evidenced, it was auditable, and it happened against your own domains during the trial rather than against a demonstration tenant. Score 10. Reserve it. A matrix where every vendor collects tens on half the criteria has stopped discriminating and is costing your panel time.
Key
  • Nothing to check
  • Partly checkable
  • Shown to you
  • Shown, and handed over to check yourself
  • Proven against your own estate

How it gets used

The order matters more than the documents

Each step below decides what the next one is able to see. Weights agreed after the proposals arrive are weights fitted to the proposals; a trial scoped before the shortlist is a trial scoped against the wrong two vendors; pass criteria written after the readout are the readout. Nothing here is difficult, and almost all of it is skipped.

  1. Before it goes out

    Fill in the scope pages, then write the requirements

    Apex domains, subsidiaries, brands, the vendor population you want assessed, and the exclusions. Scope first is not administrative tidiness — the requirements you actually need fall out of it, and a requirements schedule written before the scope is known is a wish list that every vendor can answer.

  2. Before proposals arrive

    Agree the weights while nobody knows who benefits

    Get the panel to set the weight against each criterion before a single proposal is in the room. Weights agreed afterwards are weights fitted to a favourite, and everyone in the meeting can feel it happening even when nobody says so.

  3. As they come back

    Score independently, then read the spread first

    Each assessor scores alone, against the published bands, before anyone compares. Then look at where your own panel disagrees by three points or more. That spread is the agenda for the next meeting, and it is a better signal than any total.

  4. Shortlist

    Scope the POC against the top two, on one worksheet

    Two vendors, the same worksheet, the same seed list, the same definition of “found”, both signed. Running two trials against two differently worded scopes produces two results that cannot be compared, which is the most expensive way to end an evaluation with no answer.

  5. The fortnight

    Wire one integration on day two, not day thirteen

    Route a real finding into the queue your team already works, in the first days rather than the last. Much of what separates these platforms in production is what a finding looks like after it has left the vendor console, and a trial run entirely inside a dashboard never sees it.

  6. The decision

    Decide against the page you filled in first

    Open the pass criteria you wrote before anything ran and mark them off one at a time, gaps named rather than averaged into a total. Then put the metered units and the renewal uplift in the contract, because neither becomes visible in a fortnight and both are expensive to argue about in year two.

Method

How the pack was built, and what is not in it

It is assembled from the evaluation material this site already publishes, plus the scoping sheets we ask prospects to run against us. Every vendor question in it is one we expect to answer, and every requirement is one we would be content to be marked against. That is the test each line had to pass before it went in.

What is deliberately absent matters more on a document like this than what is present. A pack carrying our competitive positioning is an advertisement, and nobody puts their own company name on an advertisement. The exclusions beside this are at the same weight as the method for that reason, rather than sitting in a footnote at the bottom of the page.

Cost is the one thing the pack does not model, because a like-for-like number depends on what you are already running. The arithmetic for that is published separately and ungated in what the alternative stack costs, with its own methodology note stating which vendors published no price and were therefore left out of the sum rather than quietly modelled.

What the pack contains, and what it deliberately does not As of August 2026
  • Every requirement is phrased against evidence a vendor can produce rather than a feature they can tick, because a feature schedule is answered yes by everyone in this category.
  • The scoring weights, the criteria list and the pass thresholds are all editable, and the weights ship blank. The panel sets its own priorities before any proposal arrives.
  • The vendor questions are ones we expect to be asked ourselves, and a serious competitor answers most of them. The “weak answer” column is written against the evasion, never against a named vendor.
  • The POC worksheet is the same one we ask to be run against us, including the parts that are inconvenient for us — the held-back properties, the disputed-finding log, and the requirement that active validation stay bounded to inventory already attributed to you.
  • Nothing in it requires a ShadowMap subscription, trial or conversation to use, and it is issued unbranded so you can put your own name on the cover.

Deliberately excluded

  • No competitor names, no vendor ranking and no scoring already filled in. The matrix ships with three unnamed columns because the columns are yours to label.
  • No accuracy, false-positive or suppression statistic, ours or anyone else’s. A figure of that shape describes the findings you were never shown, measured by whoever decided not to show them.
  • No takedown completion time, in either direction. Removal depends on registrars, hosts and platforms nobody in this category controls, so what belongs in an RFP is a contractual commitment with a penalty behind it rather than a published number.
  • No cost model and no vendor pricing. What a platform costs is a conversation with each vendor, and the build-versus-buy arithmetic is published separately and ungated.
  • No legal or procurement advice. The pack is a working template, not a form of contract, and it does not tell you whether your own procurement rules permit any of it.
  • No claim that it only works if you pick us. If it did, it would get read once and forwarded never, which would defeat the entire reason we wrote it.

Questions this page gets asked

Before you hand over an address

Does the pack only work if we end up buying ShadowMap?

No, and it is built so that it does not. There are no competitor names in it, no requirement written so that only one architecture can satisfy it, and the scoring weights ship blank so the panel sets its own priorities. The commercial logic is not subtle and we will state it plainly: a vendor whose evaluation criteria a buyer adopts is present in every subsequent conversation, including the ones they are not invited to. That only works if the criteria are fair, so they are. We would rather be evaluated properly and lose than win on a demo.

What is the difference between this and the evaluation guide on the site?

The guide at /evaluate/ is the thinking, and it is free and ungated because a buyer needs it during the evaluation — the three questions a fortnight has to settle, the scoping sequence, the vendor questions with what a weak answer sounds like, and an honest ledger of what two weeks cannot tell you however well it is run. The pack is the fillable version of the same material: the requirements schedule you paste into your own RFP, the scoring sheet with three vendor columns, and the POC worksheet both sides sign. That is the document you put your own company name on, which is the line at which we ask for an email address. Nothing in the pack contradicts the free guide, and if you only ever read the free one you have lost very little.

Do we have to talk to anyone to get it?

No. Enter a work email, click the confirmation link and the pack downloads. The confirmation step exists because the ungated version of this form produced a junk rate we could not work with, not as a qualification gate — there is no call to book and no form field asking for your budget or your timeline. If you would rather not give an address at all, the whole argument is published ungated at /evaluate/ and you can rebuild the sheets from it in an afternoon.

Can we edit it, and can we send it to vendors with our own branding?

Yes to both — that is what it is for. Change the criteria, change the weights, delete the capability areas that are outside your scope, put your own logo on it and issue it. It is a working document rather than a piece of marketing, and a pack a procurement team cannot rebrand is a pack a procurement team cannot use.

Where this gets sharper

The free half, and the capabilities the requirements are written against

How to evaluate a platform The ungated version of everything above: the three questions a fortnight has to settle, the scoping sequence, the vendor questions with what a weak answer sounds like, and a ledger of what two weeks cannot tell you however well it is run. Free on purpose — a buyer needs it during the evaluation, not after it. What the alternative stack costs The build-versus-buy arithmetic the pack deliberately leaves out, published ungated with its own methodology note — including which vendors published no price and were therefore excluded from the sum rather than quietly modelled. Attack Surface Management The capability the discovery and attribution requirements are written against — getting from an apex domain to the estate nobody named, with the evidence tying each asset to your organisation sitting on the asset rather than summarised into a score. Continuous Automated Red-Teaming What the validation criteria in the matrix are asking about — whether a discovered exposure can actually be used, established where it is safe and authorised, bounded to inventory already attributed to you, with an audit identifier on every request. Data Exposure Monitoring The capability behind the data and identity exposure section of the requirements skeleton — secrets in public repositories, exposed storage and indexed documents, attributed to an owner and tested for whether they still open anything.

Settle the first criterion before you write the RFP

Attribution is the one criterion you can test without a procurement process. Give us one apex domain and we send back a written account of what is already reachable from outside — no call needed, and the result is yours whichever platform you end up buying.

Request an exposure snapshot Read the ungated guide