Skip to main content
Regulator guide · EU third-party ICT risk

A DORA third-party programme rests on what you knew about your ICT providers, and when you knew it.

Third-party ICT oversight turns on a record, not a review: that monitoring ran, over what scope, and what changed between one assessment and the next. Continuous outside-in monitoring produces one specific half of that: what a provider’s internet-facing estate looked like on a given date, and what has moved since. This page sets out what that evidences, what it does not reach, and where the boundary sits.

ShadowMap is a monitoring platform, not a regulatory adviser. Nothing here is an interpretation of the Regulation, legal advice, or a claim that any artefact satisfies an obligation. Those determinations belong to your compliance function and your own advisers. For the vendor methodology behind this, see third-party risk management.

See three of your providers from outside How regulatory monitoring works

Scope

The part of this a monitoring platform can speak to

DORA’s third-party material is built around a relationship, not a moment: the arrangements you hold, which of your functions sit on them, what happens to the oversight after the contract is signed, and what is written down about all of it. Most of that is contractual, organisational and legal work. A monitoring platform has nothing useful to say about the majority of it.

One part is different. Whether a provider’s internet-facing estate is still what it was when you assessed it; whether something opened, moved or appeared since; whether credentials belonging to that provider are circulating; whether several providers you treat as independent of one another resolve to the same upstream. All of those are observable from outside, continuously, without the provider taking part and without anything being installed anywhere. That is the part this page is about.

The honest boundary

What continuous provider monitoring evidences, and what it cannot

The third column is the one to read first. Every entry in the second column is a real artefact with a date on it; every entry in the third is a question that outside-in observation structurally cannot answer, however long it runs. Read the last row first: it decides whether the five above it are worth anything.

Third-party ICT oversight questions against what external monitoring does and does not evidence
What oversight asks about a providerWhat outside-in monitoring evidencesWhat it does not reachWhere it sits
Is the provider’s internet-facing estate still what it was when we assessed it? Every hostname answering from the public internet across the provider apex domains you nominate, resolved without the provider taking part, each carrying the date it entered scope and, where it has gone, the date it left. Anything the provider runs that never answers from the internet. A private estate has no outside-in signature at all, and asking a monitoring record about it is asking the wrong instrument. Attack Surface Management
Attribution is the load-bearing part, not discovery. A host tied to the wrong company puts a finding on a provider’s file that the provider can disprove in a meeting, and a monitoring record that has been shown to be wrong once is discounted wholesale afterwards. Each host carries the evidence that ties it to the provider, not to a company with a similar name.
Has anything changed since the last review? Movement in that estate as a dated finding: a host that appeared, a service that opened, a software version that moved, an administrative interface that stopped presenting a second factor, an estate that grew after an acquisition nobody announced. Why it changed. The record states what became observable and on which date; the reason belongs to the provider and is something to ask for, never something to infer from outside. Third-Party Risk Management
This is the row that answers “when did you know”, and it is the reason a change is published as a dated finding with an owner, not as a movement in a score. A grade going from B to D is only the reason somebody looked.
Who does the provider itself actually depend on? The hosting, DNS, mail, certificate and authentication providers each monitored provider resolves to, compared across the whole monitored portfolio instead of one file at a time, so a shared upstream becomes a dated, checkable fact. The contractual subcontracting chain. A resolution path shows a technical dependency. It does not show who holds the contract, what that contract permits, or which of your functions is sitting on it. Third-Party Risk Management
The dependency you have no contract with is still a dependency, and it is the one a disclosure list structurally cannot show you. A provider can only disclose the arrangements it holds directly. Concentration is worked further down this page.
Are credentials belonging to the provider circulating? Credential records attributed to the provider’s domains in stealer-log and breach material, dated to when they entered the corpus rather than to when the underlying breach is said to have happened. Whether the provider has rotated them, and whether they still open anything on the provider’s systems. Testing a third party’s estate needs authorisation from the party that owns it, which in a provider relationship is not yours to give. Dark Web Monitoring
There is one narrow exception: where an exposed provider-staff identity maps to an account on your own systems (a contractor remote-access portal, a shared tenancy, a federated login), that account is your estate, and it is validated under the same audit trail as any first-party finding.
Did the monitoring actually run, over what scope, and what was done about what it found? Per-provider detection timestamps and the attributed inventory each run covered, the disposition your team recorded against each finding with the assignee and the timestamps, and the privileged changes made to the monitoring configuration itself. Any confirmation that the record satisfies an obligation. ShadowMap produces the artefact. Whether the artefact answers a particular clause is a judgement for your auditor and your own advisers. Regulatory Intelligence
The record deliberately includes the occasions your own service levels were missed and the surfaces that were examined and returned nothing. A monitoring trail showing only the months that went well is not evidence. An examiner who cannot find a single miss in a year stops trusting the whole set.
Is the provider’s internal control environment sound? Nothing. There is no outside-in signature for governance, segregation of duties, change management, personnel screening, backup and restore testing, or the resilience testing a provider runs on itself. All of it. Attestations, audit reports, contractual audit and access rights, and the provider’s own testing carry this half of the question. Nothing here replaces them. —
Outside-in monitoring is evidence about the surface an attacker meets. It is not assurance about the controls behind that surface, and a programme that lets one stand in for the other has quietly swapped the thing for a proxy of it.

Third-party ICT oversight questions against what external monitoring does and does not evidence

Is the provider’s internet-facing estate still what it was when we assessed it?

What outside-in monitoring evidences
Every hostname answering from the public internet across the provider apex domains you nominate, resolved without the provider taking part, each carrying the date it entered scope and, where it has gone, the date it left.
What it does not reach
Anything the provider runs that never answers from the internet. A private estate has no outside-in signature at all, and asking a monitoring record about it is asking the wrong instrument.
Where it sits
Attack Surface Management

Attribution is the load-bearing part, not discovery. A host tied to the wrong company puts a finding on a provider’s file that the provider can disprove in a meeting, and a monitoring record that has been shown to be wrong once is discounted wholesale afterwards. Each host carries the evidence that ties it to the provider, not to a company with a similar name.

Has anything changed since the last review?

What outside-in monitoring evidences
Movement in that estate as a dated finding: a host that appeared, a service that opened, a software version that moved, an administrative interface that stopped presenting a second factor, an estate that grew after an acquisition nobody announced.
What it does not reach
Why it changed. The record states what became observable and on which date; the reason belongs to the provider and is something to ask for, never something to infer from outside.
Where it sits
Third-Party Risk Management

This is the row that answers “when did you know”, and it is the reason a change is published as a dated finding with an owner, not as a movement in a score. A grade going from B to D is only the reason somebody looked.

Who does the provider itself actually depend on?

What outside-in monitoring evidences
The hosting, DNS, mail, certificate and authentication providers each monitored provider resolves to, compared across the whole monitored portfolio instead of one file at a time, so a shared upstream becomes a dated, checkable fact.
What it does not reach
The contractual subcontracting chain. A resolution path shows a technical dependency. It does not show who holds the contract, what that contract permits, or which of your functions is sitting on it.
Where it sits
Third-Party Risk Management

The dependency you have no contract with is still a dependency, and it is the one a disclosure list structurally cannot show you. A provider can only disclose the arrangements it holds directly. Concentration is worked further down this page.

Are credentials belonging to the provider circulating?

What outside-in monitoring evidences
Credential records attributed to the provider’s domains in stealer-log and breach material, dated to when they entered the corpus rather than to when the underlying breach is said to have happened.
What it does not reach
Whether the provider has rotated them, and whether they still open anything on the provider’s systems. Testing a third party’s estate needs authorisation from the party that owns it, which in a provider relationship is not yours to give.
Where it sits
Dark Web Monitoring

There is one narrow exception: where an exposed provider-staff identity maps to an account on your own systems (a contractor remote-access portal, a shared tenancy, a federated login), that account is your estate, and it is validated under the same audit trail as any first-party finding.

Did the monitoring actually run, over what scope, and what was done about what it found?

What outside-in monitoring evidences
Per-provider detection timestamps and the attributed inventory each run covered, the disposition your team recorded against each finding with the assignee and the timestamps, and the privileged changes made to the monitoring configuration itself.
What it does not reach
Any confirmation that the record satisfies an obligation. ShadowMap produces the artefact. Whether the artefact answers a particular clause is a judgement for your auditor and your own advisers.
Where it sits
Regulatory Intelligence

The record deliberately includes the occasions your own service levels were missed and the surfaces that were examined and returned nothing. A monitoring trail showing only the months that went well is not evidence. An examiner who cannot find a single miss in a year stops trusting the whole set.

Is the provider’s internal control environment sound?

What outside-in monitoring evidences
Nothing. There is no outside-in signature for governance, segregation of duties, change management, personnel screening, backup and restore testing, or the resilience testing a provider runs on itself.
What it does not reach
All of it. Attestations, audit reports, contractual audit and access rights, and the provider’s own testing carry this half of the question. Nothing here replaces them.

Outside-in monitoring is evidence about the surface an attacker meets. It is not assurance about the controls behind that surface, and a programme that lets one stand in for the other has quietly swapped the thing for a proxy of it.

The record

How a provider gets into the monitoring record, and what keeps it there

Evidence that monitoring ran is a by-product of doing the work in an order that can be reconstructed later, not a report you can generate at the end of it. Each step below decides what the next one is able to see.

  1. Nominate

    You decide who is in scope. We do not.

    You name the providers and the apex domains they trade under, including the subsidiaries and acquisitions that make a supplier register hard to keep straight. ShadowMap does not designate which arrangements support a critical or important function, does not tier your providers for you, and does not maintain your register of information. Those are yours, and they should be.

  2. Attribute

    Establish what actually belongs to that provider

    Every host is tied back to the provider by something checkable, not by name similarity. This is the unglamorous half of the work and the half that decides whether the record survives being challenged: a provider that disproves one attributed asset has, in practice, disproved the file.

  3. Observe

    Continuously, from outside, with nothing installed

    No agent, no credentials, nothing touched that is not already reachable from the public internet, and no cooperation required from the provider. A provider-side estate is observed and not tested. Continuous Automated Red-Teaming runs against your own estate where it is safe and authorised, and authorisation over somebody else’s systems is not yours to grant.

  4. Date the change

    A change is a dated finding, not a moved score

    What became observable, on which date, against which asset, with the previous state kept beside it. That is what turns “when did you know” from a recollection into a record, and it is the single artefact a review cycle cannot produce however well it is run. Between two annual reviews there is nothing to date.

  5. Hand it over

    Exportable, with the misses left in

    The dispositions your team recorded, the assignees, the timestamps, the surfaces examined that returned nothing, the service levels your own policy set and the occasions they were missed, and the privileged changes made to the monitoring configuration. Whether that answers a given obligation is not ours to say; producing it, in a form somebody else can reconstruct, is.

Concentration

The dependency nobody has a contract with

Subcontracting and concentration are where a supplier register and the actual architecture drift furthest apart, and it is the one question on this page where outside-in observation is not the weaker instrument. A provider can only disclose the arrangements it holds directly. What its systems resolve to is answerable without asking anyone.

Subcontracting and concentration

One monitored portfolio, seen from the file and from the resolution path

What the paperwork discloses
The sub-processor and subcontractor list the provider compiled, as at the date it was written, covering the arrangements that provider holds directly. It is a contractual artefact and it is accurate on its own terms. What it cannot describe is the layer beneath its own suppliers, or a hosting migration completed the month after it was signed off.
What the resolution path shows
Which hosting, DNS, mail, certificate-issuance and authentication providers each monitored provider’s customer-facing systems actually resolve to, read the same way for every provider in the portfolio, on the same day, so the answers are comparable instead of being reconciled across a set of differently worded files.
What it changes
Concentration stops being an assumption inside a continuity plan and becomes a dated fact somebody owns: the same upstream serving several providers you had been treating as alternates for one another. None of that is a vulnerability. It is architecture, and it is now a standing agenda item with a date and an owner instead of an unexamined belief. The limit stays exactly where the table put it: a technical dependency is not a contractual one, and only the provider can tell you which of your functions is sitting on it.

Method

How a provider is scoped, observed and recorded

A monitoring record is only worth producing if somebody else can work out how it was made. The exclusions below carry the same weight as the method.

Provider monitoring: how it is scoped, and what it deliberately is not As of August 2026
  • Scope is yours. You nominate the providers and the apex domains they trade under. ShadowMap does not designate which arrangements support a critical or important function, does not tier your providers, and does not maintain your register of information.
  • Everything is outside-in. Nothing is installed on your estate or a provider’s, no credentials are used, and nothing is touched that is not already reachable from the public internet by anyone.
  • A provider’s estate is observed, not tested. Validation runs where it is safe and authorised, and authorisation over a third party’s systems is not yours to give, so provider-side findings arrive observed and untested, and say so on the finding.
  • Attribution carries its own evidence. Each host is tied to the provider by something checkable, not by name similarity, because a record whose attribution cannot be defended is worse than no record at all.
  • Dates sit on the observation, not on the incident. A finding is dated to when it became observable, which measures when you could have known, not when the underlying event is claimed to have occurred, and not when a provider got round to mentioning it.
  • The record keeps what did not go well: the surfaces examined that returned nothing, and the occasions your own service levels were missed.

Deliberately excluded

  • No legal determination. Nothing here establishes whether the Regulation applies to your entity, whether an arrangement supports a critical or important function, or whether any artefact satisfies an obligation. Those belong to your compliance function and your own advisers.
  • No claim to EU regulatory counsel. ShadowMap produces monitoring evidence and does not advise on European financial regulation. This page is not an interpretation of the text and should not be relied on as one.
  • No assurance over a provider’s internal controls. Outside-in monitoring reaches the external surface and stops there.
  • No testing of a provider’s systems. Continuous Automated Red-Teaming runs against your own estate where it is safe and authorised, never against a third party’s on your say-so.
  • No threat-led penetration testing. That is a scoped, supervised exercise with its own requirements; continuous external monitoring is a different instrument and does not stand in for it.
  • No register maintained on your behalf, and no filing, notification or submission lodged with any authority. ShadowMap produces the record; you and your advisers decide what is done with it.

Questions this page gets asked

Before you put this in a programme plan

Does using ShadowMap make us DORA compliant?

No, and treat any vendor who says otherwise as having told you something useful about themselves. Compliance is a determination about your entity, your arrangements and the functions sitting on them, and it belongs to your compliance function and your own advisers. What ShadowMap produces is one input to it: a dated, scoped record of what was observable from outside about the providers you nominate, what changed and when, and what your team did about each finding. That record is evidence. Whether it answers a particular obligation is a judgement we are not qualified to make.

Do you need the provider’s cooperation, or their permission?

Neither, because nothing is done to the provider. Observation runs entirely against what already answers from the public internet: nothing installed, no credentials, and nothing touched that is not already reachable by anyone. What we will not do is test a provider’s systems: that needs authorisation from the party that owns the estate, and in a third-party relationship that party is not you. Provider-side findings therefore arrive observed and untested, with the observation and its date attached so the provider can confirm and fix. Most of the organisations we work with tell their providers they are monitored anyway, and it tends to be a better conversation than the questionnaire it partly replaces.

How is this different from the register of information we already keep?

They answer different questions and neither substitutes for the other. A register records the arrangements you hold. It is a contractual artefact, compiled as at a date, and yours to maintain. Monitoring records something a register structurally cannot: what a provider’s external estate actually looked like on a given day, and what moved in the months between the dates the register was compiled. ShadowMap does not maintain a register on your behalf, does not decide which arrangements are in it, and lodges nothing with any authority.

Is this threat-led penetration testing?

No, and the two should not be confused in a programme plan. Threat-led penetration testing under DORA is a scoped, supervised exercise with its own requirements and its own participants. Continuous Automated Red-Teaming is continuous validation of your own external exposure, bounded to inventory that discovery has already found and attributed to you, run where it is safe and authorised. It does not substitute for threat-led penetration testing.

Where this gets sharper

Provider evidence comes out of one correlated exposure model

Third-Party Risk Management The methodology underneath this page: what a questionnaire structurally cannot tell you, and the published vocabulary stating which kind of evidence each provider finding is: validated, observed but not validated, or recorded as nothing found. Attack Surface Management The discovery and attribution that every row of the table above depends on: the same outside-in engine, pointed at a provider’s apex domains instead of your own, with origin infrastructure found behind the edge that fronts it. Regulatory Intelligence What EU and national authorities publish, tracked as programme context rather than as a compliance opinion, and the table of what an auditor asks against the artefact inside the platform that answers it. NIS2 and supply-chain monitoring The sibling guide: the same posture applied to suppliers instead of providers, with the boundary published as a vocabulary of evidence kinds instead of a table. Read it beside this one if your group has entities inside both.

See three of your providers the way an attacker sees them

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

Request an exposure snapshot See Pricing