Switching external exposure vendors: the first thirty days

Most external exposure platforms are not bought for the first time. They are replaced.

The trigger is rarely a single failure. It is usually an accumulation: a queue nobody worked, because nothing in it was ordered by anything an engineer recognised as urgency; a discovery scope that stopped at infrastructure while the exposures that turned out to matter were a leaked repository and a set of credentials taken off someone's home laptop; a renewal quote that grew faster than the value did. By the time an organisation is seriously comparing digital risk protection vendors or attack surface management vendors, the decision to leave has usually already been taken, and what is left is a migration.

That is the part nobody plans for. Choosing the replacement is a procurement exercise with a well-understood shape, and the evaluation itself is a separate discipline. Getting from one platform to the other is a data migration and, more importantly, a decision migration. Two years of "that host belongs to the joint venture, not us" and "accepted until the datacentre exit completes" appear in no export file, and re-deriving them by hand costs an analyst a quarter.

The overlap fortnight, and when to ask for it

Insist on a minimum of two weeks with both platforms live against the same scope. Not as a courtesy — as the only opportunity you will ever have to measure one against the other on identical inputs.

Sequencing matters more than length. Most enterprise contracts auto-renew on a sixty- or ninety-day notice window, and the moment you serve notice your leverage goes to zero. Secure the overlap and the export commitments in writing first, then give notice. Asking the vendor you have just fired for co-operative data extraction is a conversation with a predictable outcome.

Both platforms then get the identical seed set: the same apex domains, brand and product names, ASNs, cloud accounts and subsidiary list. If you hand the incoming platform a cleaner seed than the incumbent ever had, you have measured your own tidying rather than their discovery. Freeze scope changes for the fortnight.

What you are measuring is the symmetric difference — assets the incumbent holds that the new platform does not, and the reverse. Neither direction is self-explaining. Assets only the incumbent holds are often decommissioned estate never retired from its inventory, or attribution errors quietly accepted for years; assets only the new platform holds may be genuine discovery or over-attribution. The only way to know is to sample twenty or thirty from each side and adjudicate them by hand against registrar records, cloud account ownership, or a conversation with the team that stood the thing up.

Getting your inventory out

Assume the rows are exportable and that most of what made them useful is not.

Usually exportable: assets with hostnames, addresses, open services and first-seen dates; findings with severity and status; sometimes tags and owner assignments. Usually not, or only in degraded form: the attribution rationale that says why an asset was judged to be yours; evidence artefacts such as captured responses and screenshots; comment threads; suppression rules and their written justifications; severity overrides; and the state-change history that constitutes your audit trail.

Export through the API rather than the interface — UI exports are commonly capped, paginated, silently truncated at a row limit, or flattened in ways that lose nested evidence. And ask in writing, before notice, for the data-return format and the post-termination retention and deletion position, including whether deletion extends to derived data. A vendor that answers precisely is one you can leave cleanly; a vendor that answers vaguely has told you something useful about the contract you are about to sign with somebody else.

The attribution rationale is the piece worth fighting for. An asset row without the reason it was attributed to you is a hostname in a spreadsheet, and it will need re-verifying — because your new platform is going to disagree with it.

Week one will look like a regression. It is not.

Four mechanisms produce that impression, and all four are artefacts of the change rather than evidence about either platform.

Attribution is re-derived from scratch. The incoming platform inherits none of the incumbent's judgements. Shared hosting, CDN-fronted properties, regional subsidiaries and assets registered to a partner will land differently, and some will land wrongly in the first pass. This is the same reconciliation the incumbent did in its own first month; you have simply forgotten it.

Deduplication models differ. One platform counts a finding per host, per port and per CVE; another collapses to a service or an application. It is also why shortlists that place digital risk protection vendors alongside broader exposure platforms rarely compare like with like — a large movement in the finding count can be the same reality counted under a different rule. Compare per asset, never on totals.

Every trend chart is meaningless. "New this week" is the entire estate in week one, and no delta-based metric is valid until the platform has its own history.

A platform that validates hands you a smaller queue. Where validation is safe and authorised, much of what a scoring engine would have shown as high severity resolves to something that cannot actually be used. In ShadowMap deployments, typically 8–15% of surfaced exposures are validated as genuinely exploitable. Read as a count, that looks like the new vendor finding less. Read as a work queue, it is the reason for the change.

Two things usually move the other way at the same time, which is why the first month feels contradictory. Outside-in discovery typically returns 30–60% more internet-facing assets than the inventory the organisation held going in — and where the incumbent was the system of record for that inventory, that is precisely the delta you are staring at. Where its scope stopped at infrastructure, the categories it never covered arrive at once: in a typical first thirty days ShadowMap surfaces 5–15 active secrets and 200–800 stealer-log credentials for a single customer. None of that is a deterioration in your security posture. It is the same estate, described more completely, and it all arrives in the same fortnight.

Handle it before it happens. Tell your steering group, in writing and in advance, that month-one counts are not comparable with the previous platform's and that the first meaningful comparison is at day sixty. Otherwise somebody else will make that comparison for you, and they will make it with the count. The benefits that justify the switch — in ShadowMap's case a 40–60% improvement in time-to-action on high-severity findings — register in the third month, not the first.

Suppressions and accepted risk: migrate these by hand

This is the most valuable thing in the incumbent, and the only part of the migration where manual work is unambiguously worth it. Sort every suppression into three classes before moving anything.

Attribution corrections — "this is not ours" — are facts about the world and should migrate. Load them as scope rules on day zero, before the first full discovery completes, so those assets never enter the queue rather than being triaged and dismissed a second time.

Risk acceptances — "ours, known, accepted until X" — migrate as decisions, with the owner and expiry date restated. An acceptance with no named owner or no expiry is not an acceptance; it is an abandonment wearing a suppression's clothes. A migration is the one moment when you have political licence to re-open those.

False-positive suppressions should not migrate. They are artefacts of one platform's detection logic and carry no meaning in another's; importing them buries genuine findings behind rules written for a different engine.

The vendor portfolio

If the outgoing platform monitored your third parties, that portfolio is a separate migration with its own failure mode: the mapping between a supplier's name in your GRC system and the domains, subsidiaries and regional entities actually monitored on their behalf. That mapping is rarely documented and almost never exportable in usable form.

Re-tier rather than lift and shift. Most portfolios have drifted — suppliers tiered as critical three years ago and since decommissioned, material vendors onboarded last year and never added. Rebuild from the contract register rather than the incumbent's export, and monitor only what you have a contractual or clear legitimate-interest basis to monitor. The gain is operational: continuous outside-in monitoring answers "are we affected" during a supplier incident from evidence rather than from an emailed questionnaire, which across ShadowMap's customer base is a 60–80% faster vendor-incident response than a questionnaire-driven review cycle.

Renegotiate at the second renewal, not the first

You will sign the first contract with the least leverage you will ever have, having just demonstrated that you were prepared to leave somebody. Accept it, and optimise for optionality rather than price: a twelve-month initial term, the modules you can staff in year one, and — non-negotiably — an exit clause specifying API-level export, granularity and evidence artefacts.

Renewal two is where the money is, because by then you have facts: your real asset count rather than the estimate you scoped against, which modules produced findings that were actioned rather than merely delivered, and observed response times to hold an SLA against. It is also the first point at which a consolidation argument can be priced honestly against the stack you are actually running rather than assumed.

Four questions for your incumbent before you go

1. What exactly is in the data return — asset and finding rows only, or attribution rationale, evidence artefacts and state history as well?
2. What happens to our data after termination: retention period, deletion certificate, and does deletion extend to derived and aggregated data?
3. Which assets in our inventory did you discover, and which did we supply? The ratio is the clearest measure of what the platform was worth.
4. What did you find in the last twelve months that we actioned? Not what was found — what was actioned.

That last one is the important question, and it is aimed at you rather than at them. Switching platforms fixes coverage and it fixes prioritisation; it does not fix an unowned queue, and that is the one migration risk no export format protects you from. Settle who owns the work first, then price the platform around the work it will actually create.

Planning a replacement? A scoped proof of concept run against your own estate, in parallel with your incumbent, answers the discovery and attribution questions before the contract date forces the decision. → Request a proof of concept

Related: How to scope a fourteen-day exposure POC · Platform comparisons · Pricing and packaging