Digital risk protection is being absorbed. What replaces it?

Digital risk protection named something real. For most of the last decade it was the cleanest available description of a genuine gap: the impersonating domains, leaked credentials, exposed customer data and targeted executives that threaten an organisation from outside its perimeter and outside its control.

Then the word began to fade. Search demand for "digital risk protection" has been receding year on year, and the related terms are declining alongside it. Over the same period demand for "continuous threat exposure management" has grown, and analyst coverage has moved in the same direction.

That gap marks a category being absorbed, and the direction of absorption says something useful about how the work is now organised.

The word is declining. The problem is not.

Nothing DRP described has become less common. Domain impersonation has not slowed, information-stealing malware produces more usable corporate credentials every quarter, and data still leaves organisations through repositories, misconfigured storage and third parties.

The change was in the taxonomy. Two forces pulled the category apart from opposite ends.

The first was analyst coverage. DRP was assessed for years as a standalone services market. Its intelligence half (actor tracking, forum and channel collection, threat context) was absorbed into threat-intelligence coverage, because that is what it always was. Its discovery half asked what of ours is out there, who owns it and what is exposed; that half travelled the other way, into external attack surface management and then exposure management. Both halves found better homes; what was left in the middle was a name without a centre.

The second was product architecture. Vendors who grew up selling DRP have mostly resolved into one of two shapes: an intelligence platform whose output is context, or an exposure platform whose output is a work queue. Few still sell the composite. It was defined by what it monitored, never by what it produced.

What digital risk protection got right

Three things, and any successor category that quietly drops them is a downgrade.

It was genuinely outside-in. DRP assumed no access: no agent, no credentials, no enrolment. It looked at the organisation from the position an attacker occupies. That is the only vantage point from which the assets nobody registered with IT are visible at all.

It was brand-inclusive. It counted things that are not assets and never appear in an inventory: a domain registered to impersonate you, an application published under your name in a store you do not control, an executive whose reused password is for sale. Vulnerability management has no field for any of that.

It was action-oriented. Takedown was part of the product, not a referral to another supplier, so finding and remedy lived in one place. That is rarer than it should be, and the part of DRP most worth carrying forward.

What it never covered

Four gaps, and together they are why the category could not hold the centre.

Assets. DRP monitored what you asked it to monitor: brand terms, apex domains, executive and product names. It was seeded, not discovered, so it inherited your inventory's blind spot — and that blind spot was the original problem. Outside-in discovery that starts from an apex domain and assumes nothing else typically returns 30–60% more internet-facing assets than the organisation's own inventory contained. More on that distinction in EASM, CAASM, vulnerability management, exposure management.

Code. Public code hosts, package registries, build artefacts and mobile bundles were treated, at best, as one more place a document might leak from. They are something else: where live authentication material sits in plaintext. Across new deployments we typically surface 5–15 active secrets in the first thirty days: keys and tokens that still authenticate, not historical strings in old commits.

Validation. DRP produced signals carrying a severity, not findings carrying proof, and the result was a queue nobody could triage without redoing the vendor's work by hand. Of the exposures we surface, 8–15% validate as genuinely exploitable. The rest matter as context and trend, but they are not this week's work, and something must make that separation before the queue reaches a person. Where that step is missing, an analyst performs it manually and the programme's real cost is hidden in their calendar.

Vendors. Third-party exposure sat almost entirely outside DRP, in a questionnaire process on a different budget line and annual cycle. Yet most third-party incidents reach you through a supplier's external estate, which is continuously observable and requires the supplier to answer nothing. A continuous outside-in view of that estate answers "is this our problem this morning" 60–80% faster than questionnaire-driven review.

Why external exposure management is a successor, not a rebrand

A rebrand keeps the architecture and changes the label. Here the architecture changed too, and the difference is visible in the unit of work.

Under DRP, the unit of work was an alert about a mention: something matching your terms appeared somewhere, and the product told you. Under exposure management, the unit of work is an object: an asset, an identity, a repository, a supplier. Each carries a state and a history, and mentions attach to it. That inversion is what makes correlation possible: a leaked credential, a live session cookie and an exposed internal hostname stop being three alerts and become one compromised machine with one owner and one response.

It also changes the shape of the programme. Exposure management is a cycle, not a feed: scope, discover, prioritise, validate, mobilise. Findings arrive attached to something you own, ranked against each other and routed to the team that can act. In our own deployments that structure produces 40–60% faster time-to-action on high-severity findings, and that gain comes from removing the triage step, not from alerting faster.

None of this discards the intelligence half. Actor context tells you whether an exposed service matches the current tradecraft of a group targeting your sector, and ShadowMap maintains 1,000+ curated threat-actor profiles for that purpose. The change is that context attaches to an asset instead of arriving as a standalone report. The brand, impersonation and takedown work of digital risk protection runs as modules of one external exposure platform: nine of them, sharing one inventory, one correlation layer and one queue.

External exposure management is external. It does not see your internal network, it has no endpoint telemetry, and it cannot tell you which internal server is unpatched. It replaces DRP. It does not replace vulnerability management, and any vendor implying otherwise is selling you a gap.

If "DRP" is the line item in your budget

Do not rename it. The line renews, the budget code works, and relabelling it midyear starts a conversation with finance that produces nothing. What should change are the questions asked at renewal, because they now have better answers available than when the contract was signed.

Four are enough. Where did the inventory in this product come from: did the vendor discover it, or did we supply it? What proportion of last quarter's output was validated before it reached us, and what does this vendor mean by validated? Does coverage extend to code repositories and third parties, or stop at brand and credentials? And is a finding here a mention, or an object with a state, an owner and a history?

If the answers are good, the label on the invoice does not matter. If they are not, you are paying for a category the analysts have stopped covering separately, from a vendor whose own roadmap has already moved. Better to know before the renewal date than after it. The comparison set answers that against the alternatives directly.

Digital risk protection was a good name for a real problem. The problem outlived the name, which is the ordinary fate of a category that described a symptom instead of a structure.

Costing this out? The alternative-stack comparison sets out what an equivalent capability costs assembled from separate DRP, EASM, credential-monitoring and third-party tools, against a single consolidated platform. → Compare the alternative stack

Related: Digital risk protection · The ShadowMap platform · EASM, CAASM, VM, exposure management