Skip to main content
Vendor risk · One outside-in methodology

The question is not how your vendors score. It is what an attacker can reach through them.

ShadowMap runs one outside-in engine. The categories, the maths and the bands that grade your own external estate are the ones applied to every vendor in your portfolio — so an internal target and a vendor threshold are directly comparable, and a vendor finding arrives carrying the same evidence a first-party finding does. Where it is safe and authorised, that evidence includes a test.

Request an exposure snapshot How to evaluate this
24 hours
Onboarding assessment, before you sign
20 vendors
Included in the standard licence
CERT-In
Empanelled security auditor since 2008
60–80%

Faster vendor-incident response

Measured against questionnaire-driven third-party review, which is the baseline most programmes actually run. The gain is not that anyone works faster — it is that nobody waits for the next cycle to find out. The derivation is published further down this page, and the number is not worth quoting without it.

Evidence types

What a questionnaire structurally cannot tell you

A questionnaire is a self-assessment, written by the party being assessed, describing a moment that has already passed. Nearly every answer is true on the day it is written. The problem is the other eleven months — and the table below is the comparison the category does not publish.

What the questionnaire attestsWhat is observed insteadRefreshWhen it changes
"We maintain an inventory of our internet-facing assets." Every hostname that answers from the public internet across the vendor apex domains you nominate, resolved without the vendor taking part. Continuous A host that appeared yesterday is in the register today, attributed to the vendor that owns it.
The gap is not hypothetical. On its own estate, a hospital network with an inventory it considered reliable held 470 hostnames on the register against 640 answering — a 36% delta, found on the way to assessing its vendors rather than as the object of the work. Anonymised engagement, 2026.
"Administrative access requires multi-factor authentication." Which administrative interfaces are reachable from the internet at all, on what software version, and whether the sign-in path in front of them presents a second factor. Continuous An interface that appears, changes version or stops presenting a second factor is a dated change on the finding. The policy does not have to be wrong for that to happen — it only has to have an exception nobody recorded.
"Staff credentials are rotated and never reused." Credential records attributed to the vendor domain in stealer-log and breach material, including how many were added in the preceding 90 days. As new source material is processed A newly attributed record is dated to when it entered the corpus, not to when the breach happened — so recency measures when you could have known, not when the vendor got round to saying so.
Vendor-side credentials reach you observed and untested — we hold authorisation over your estate, not your vendor's. The one exception is narrow: where an exposed vendor-staff identity maps to an account on your own systems, a contractor remote-access portal or a shared tenancy, that account is your estate and is in scope for validation.
"Our sub-processors are disclosed and assessed." The hosting, DNS, mail, certificate and authentication providers each vendor actually resolves to, compared across the whole monitored portfolio. Continuous A shared upstream provider becomes a counted fact with a date on it — including the providers you have no contract with, and therefore no standing to question.
In the same engagement, 19 of 64 monitored vendors served their customer-facing systems from one regional hosting provider, and four of the five vendors named in the continuity plan as alternates for one another resolved to the same two data centres in the same city. None of that is a vulnerability. It is architecture. The difference is that it is now a quarterly agenda item with a number behind it rather than an assumption inside a plan nobody had tested.
"We will notify you of any material change." Estate size and composition tracked over time, so an acquisition, a migration or an inherited network shows up as movement rather than as a letter that may never arrive. Continuous You find out in the week it happens, not at the next review.
Worked example from the same engagement: a Tier 1 clinical vendor passed its March review cleanly, then grew from 40 to 96 answering hosts between April and July after absorbing a firm it had acquired — including a legacy coding workbench on an unsupported application server with an administrative login exposed without a second factor. The next scheduled review was seven months away.

"We maintain an inventory of our internet-facing assets."

What is observed instead
Every hostname that answers from the public internet across the vendor apex domains you nominate, resolved without the vendor taking part.
Refresh
Continuous
When it changes
A host that appeared yesterday is in the register today, attributed to the vendor that owns it.

The gap is not hypothetical. On its own estate, a hospital network with an inventory it considered reliable held 470 hostnames on the register against 640 answering — a 36% delta, found on the way to assessing its vendors rather than as the object of the work. Anonymised engagement, 2026.

"Administrative access requires multi-factor authentication."

What is observed instead
Which administrative interfaces are reachable from the internet at all, on what software version, and whether the sign-in path in front of them presents a second factor.
Refresh
Continuous
When it changes
An interface that appears, changes version or stops presenting a second factor is a dated change on the finding. The policy does not have to be wrong for that to happen — it only has to have an exception nobody recorded.

"Staff credentials are rotated and never reused."

What is observed instead
Credential records attributed to the vendor domain in stealer-log and breach material, including how many were added in the preceding 90 days.
Refresh
As new source material is processed
When it changes
A newly attributed record is dated to when it entered the corpus, not to when the breach happened — so recency measures when you could have known, not when the vendor got round to saying so.

Vendor-side credentials reach you observed and untested — we hold authorisation over your estate, not your vendor's. The one exception is narrow: where an exposed vendor-staff identity maps to an account on your own systems, a contractor remote-access portal or a shared tenancy, that account is your estate and is in scope for validation.

"Our sub-processors are disclosed and assessed."

What is observed instead
The hosting, DNS, mail, certificate and authentication providers each vendor actually resolves to, compared across the whole monitored portfolio.
Refresh
Continuous
When it changes
A shared upstream provider becomes a counted fact with a date on it — including the providers you have no contract with, and therefore no standing to question.

In the same engagement, 19 of 64 monitored vendors served their customer-facing systems from one regional hosting provider, and four of the five vendors named in the continuity plan as alternates for one another resolved to the same two data centres in the same city. None of that is a vulnerability. It is architecture. The difference is that it is now a quarterly agenda item with a number behind it rather than an assumption inside a plan nobody had tested.

"We will notify you of any material change."

What is observed instead
Estate size and composition tracked over time, so an acquisition, a migration or an inherited network shows up as movement rather than as a letter that may never arrive.
Refresh
Continuous
When it changes
You find out in the week it happens, not at the next review.

Worked example from the same engagement: a Tier 1 clinical vendor passed its March review cleanly, then grew from 40 to 96 answering hosts between April and July after absorbing a firm it had acquired — including a legacy coding workbench on an unsupported application server with an administrative login exposed without a second factor. The next scheduled review was seven months away.

The frame

An RFP written as "security ratings" has already chosen its winner

The right-hand column of that table is a procurement requirement, not a product feature. Ask instead for a letter grade across a vendor portfolio, and the ratings incumbents answer it well while the evaluation collapses into whose pre-built inventory is larger. That is a fair fight, and it is not the one worth having.

Write the requirement the other way — find what an attacker can reach through our third parties, establish what they can actually use, and remove it — and the shortlist changes shape. Three concessions belong here rather than in a footnote, because a buyer will find all three anyway. A direct remediation workflow is not our differentiator: SecurityScorecard, UpGuard and RiskRecon all ship one, and RiskRecon's vendor-facing action plans — generated at no charge to the rated party, then re-verified — are better designed than ours. The established ratings platforms carry larger pre-built vendor inventories and a longer methodology pedigree than we do, and an argument about whose score is more accurate is one we have no interest in starting. And UpGuard is not a ratings-only product, whatever a competitor deck may tell you: it ships genuine data-leak detection, typosquatting monitoring and identity-breach lookup, and a product user will know it. The narrower sentence is the accurate one, and the harder one to answer. UpGuard detects. It does not validate, and it does not remove — and validation is the difference between an exposed key and a live one, removal the difference between a lookalike domain and a domain that is gone.

One engine, three moments

There is no separate vendor product

One engine runs both estates, so there is nothing to reconcile between two methodologies and no second product to buy — which is what a vendor module bolted beside a first-party platform cannot offer. What changes across the vendor lifecycle is not the engine but the question being asked of it, and there are three moments where that question is different.

01 Onboarding

Before the contract is signed

What procurement is holding
A shortlisted name, a commercial proposal, and a security questionnaire that will take weeks to come back — if it comes back. One mature programme averaged 41 days per response, with a median of eleven weeks to close a file.
What the first 24 hours produce
Asset discovery against the candidate's apex domains, exposure analysis, credential exposure, and a rating computed with the identical categories used on your own estate — benchmarked against comparable vendors in the same sector, so a first score is interpretable before you have a portfolio to compare it against.
What it changes
Security review stops being the long pole in the contracting timeline, and the security schedule you negotiate is written against observed facts rather than against a form the counterparty filled in about itself.
02 Continuous

Between the annual reviews

What the register says
The vendor passed. The file is defensible. The next review is due in twelve months, and the tiering model that decided the review interval was itself built from the questionnaire.
What the estate does meanwhile
It grows, gets acquired, inherits infrastructure, changes hosting provider, opens a service that was meant to be internal, and appears in stealer-log material. None of it generates a notification, because none of it is something a vendor would think to declare.
What it changes
Posture drift is surfaced as a dated finding with an owner, not as a grade movement. A rating going from B to D is never the finding — it is only the reason somebody looked.
03 Enrichment

When the form still has to be filled in

Why the form does not go away
SIG and CAIQ responses carry contractual and regulatory weight that an observation cannot carry. An attestation has a signature on it, and observation cannot sign anything.
What gets attached to each answer
Every response touching an externally observable control is set beside what was observed, on the date it was observed. The reviewer reconciles two sources instead of grading prose, and "we follow industry best practice" stops being a passing answer.
What it changes
The hospital network re-tiered rather than replaced: full-length questionnaires fell from 200 vendors to 71, with the rest moved to a short attestation, and the capacity that freed went into the fourteen escalations the first monitoring cycle produced.

Sourcing the number

Where 60–80% faster comes from

The second of those three moments — the months between the reviews — is where the range at the top of this page is earned. A procurement team is right to distrust a range with no derivation behind it, so here is the one behind ours, including what it deliberately does not measure.

Vendor-incident response speed As of 2026-08-06
  • The baseline is a questionnaire-driven third-party review programme: an annual or biennial cycle, a form filled in by the party being assessed, and an out-of-band escalation whenever something becomes public. That is what most programmes actually run, which is why it is the comparison worth making.
  • The measured interval runs from the moment a vendor-side change becomes externally observable to the moment your team holds it as an actionable finding with a named owner.
  • The improvement comes from removing a wait, not from anybody working faster. Continuous observation collapses the gap between an event and its discovery, and in a questionnaire programme that gap is bounded only by the length of the review cycle.
  • It is a range because the size of the gain depends on the cycle you run today. A programme already on quarterly reviews with a working incident-triggered escalation path sits at the bottom of the band; an annual-cycle programme sits at the top.

Deliberately excluded

  • It does not measure how quickly the vendor fixes anything. That is the vendor's clock, and no monitoring product controls it.
  • It is not a benchmark against another continuous-monitoring product. Anyone claiming a percentage against a named competitor is comparing two things they do not both operate.
  • It is not a per-vendor guarantee. A vendor whose estate does not change produces no improvement to measure, and that is the correct result.

What you are looking at

Every vendor finding declares which kind of evidence it is

What actually lands in your queue is not a grade. It is a finding — and what you can do with it depends entirely on how it was established. Authorisation is the hard boundary in third-party monitoring, and it belongs on the finding rather than in a disclaimer. Not every finding is validated, and the ones that are not say so on their own row.

Every vendor finding declares which kind of evidence it is
StateWhat it meansWhat follows
Validated Tested against your estate, in scope and authorised. Continuous Automated Red-Teaming carries an audit identifier on every request so the activity reconciles against your own logs. Nothing is modified. Treat as established fact. This is the queue that moves first.
Observed, not validated Seen from outside on a third party's estate. We hold no authorisation to test another company's systems and do not assume one, so nothing was probed. Route to the vendor as a confirm-and-fix, with the observation and its date attached.
References you, not attributed An asset in vendor-controlled space that names your organisation. It may be a dedicated tenancy you were never told about, or shared infrastructure that has nothing to do with you. Confirm ownership before acting. We surface it; we do not attribute it for you.
Reported as zero A capability ran across the portfolio and found nothing attributable. Recorded explicitly as zero rather than quietly omitted from the report. Evidence that the surface was examined, which is what an auditor will ask for.
Key
  • Confirmed by test
  • Assume live, verify with the vendor
  • Confirm ownership first
  • Recorded, not omitted

Where this gets sharper

Third-Party Risk Management works from one correlated exposure model

Attack Surface Management Vendors are scored with the identical categories, the same maths and the same bands as your own estate — the methodology does not change when the estate is not yours.

Questions buyers actually ask

Before you evaluate this

We already run SecurityScorecard, UpGuard or RiskRecon. Why would we add this?

Often you would not replace it, and we would not open the conversation there — the breadth concession earlier on this page is meant literally. The question worth asking is what sits underneath the grade, and what happens on the day you find something. Ours is one engine running your own external exposure programme and your vendor portfolio on the same methodology, with credential exposure at stealer-log depth, validation where it is safe and authorised, and removal of the exposures that can be removed. If your evaluation is genuinely about portfolio breadth, buy on breadth. If it is about what an attacker can reach through a supplier and what you can prove about it, run both products against the same ten vendors for thirty days and compare the findings rather than the scores.

Do you test our vendors' systems?

No — not without authorisation from the party that owns the estate, which in a third-party relationship is not yours to give. Vendor-side findings arrive observed and untested, with the observation and its date attached so the vendor can act on it. The exception is the one on the ledger above: an exposed vendor-staff identity that maps to an account on your own systems is your estate, and it is validated under the same audit trail as any first-party finding. Every finding states which mode it is in.

What does adding a vendor cost?

Twenty vendors are included in the standard licence, which also carries the entire first-party exposure programme rather than a vendor-monitoring seat alone. Additional vendors are in the region of ₹30,000 to ₹40,000 per vendor per year, decreasing with volume. Users are unlimited, and takedowns are unlimited subject to a fair-use boundary stated in the contract. The practical planning question is not the per-vendor price but how many vendors genuinely warrant continuous assessment: most portfolios have a critical tier far smaller than the register suggests, and the concentration view usually reshapes that tier in the first cycle.

Can this replace our questionnaire programme?

No, and we would advise against trying. A regulator asking whether a vendor has a documented incident-response plan is not asking a question anything outside-in can answer, which is why the section above treats the form as something to enrich rather than retire. What changes is the reporting. In the engagement described above, the board pack stopped reporting how many forms came back — a measure of programme activity — and started reporting what is observably true about the monitored portfolio, on a stated date, with an audit trail an assessor can reproduce.

See three of your vendors the way an attacker sees them

Nominate up to three vendors and one of your own apex domains. Two business days, a written snapshot, no vendor cooperation required and no call needed to get it.

Request a vendor exposure snapshot See Pricing