Provider → service → function: the three links most third-party obligations read back to

Three regulations, one shape

Read the third-party obligations side by side and the same three nouns keep appearing:

• DORA Article 28(3) — the register of information on all contractual arrangements for ICT services provided by ICT third-party providers, distinguishing those supporting critical or important functions.
• NIS2 Article 21(2)(d) — supply-chain security, including the security-related aspects of relationships with each direct supplier or service provider, taking into account the vulnerabilities specific to each and the overall quality of their products and practices; and Article 21(3), which asks you to consider what they deliver.
• ISO/IEC 27001 Annex A 5.19–5.23 — information security in supplier relationships, in supplier agreements, in the ICT supply chain, monitoring and review of supplier services, and cloud services.

Provider, service, function. Every column in the DORA register, every NIS2 supplier assessment, every ISO supplier review is a property of one of those three or of a link between them. Organisations that struggle with third-party obligations are rarely missing the contracts; they are missing the links.

A provider does not support a function. A provider delivers a service; a service supports a function. Skip the middle noun and the register cannot be produced.

Why the middle noun matters

Take a cloud provider that runs the payment gateway API and, separately, the internal wiki. Contract-level thinking says “one provider, one arrangement, criticality: high” — because payments are involved. Service-level thinking says: this provider delivers two ICT services; one supports a critical function and one does not; the register lists both, flags one, and the exit strategy is required for one. That is not pedantry — it is the difference between an exit plan for a payments service and an exit plan for a wiki, and between one substitutability assessment and two.

The same is true in reverse. A critical function — online payments — depends on three IT services; two are run internally and one is delivered by the provider. “Which providers are behind our critical functions?” is answered by walking function → services → providers. Without the service in the middle, the question is answered from memory.

The four records

1. The third-party record. Legal name, country, type (cloud provider, ICT service provider, managed service provider, …), LEI where available, whether it is an ICT provider, whether it supports a critical or important function, criticality, owner, status (active, under review, offboarding).
2. The IT service. What the provider actually delivers — an API, a hosting platform, a managed identity service — as a first-class object with its own owner, lifecycle and criticality, composed of assets.
3. The link between them. Provider ↔ IT service (or ↔ asset, or ↔ business solution when the provider delivers a whole function). One relationship record per delivered thing, with a relationship type.
4. The function. The business solution the service supports, carrying the criticality classification — the place DORA’s “critical or important” flag and NIS2’s proportionality actually attach.

With those four, the DORA register is a projection: providers × their services × the functions those services support, plus the contract details you keep alongside. The NIS2 supplier view is the same graph read from the other side: for each provider, which of our services and functions depend on it, and how critical are they. The ISO supplier review is a cadence per provider driven by the criticality inherited from the functions it ends up supporting.

Concentration, substitutability, exit — as queries

Once the links exist, the three hard third-party questions stop being workshops:

• Concentration. Which providers sit under more than one critical function? Group the links by provider, filter by function criticality, count.
• Substitutability. For each critical service delivered by a provider, is there a recorded alternative? That is a risk register entry per service, linked to the provider and to the service, with a treatment plan.
• Exit. For each such service, does an exit plan exist and when was it tested? A governance document linked to the service, with a review date.

None of these needs a new system. They need the links to be records rather than paragraphs.

In Secantra

The third-party registry holds the provider record with the fields above and links each provider to the assets, IT services or business solutions it delivers, with a relationship type. IT services compose assets and roll up to business solutions through the CMDB’s structural relationships, so provider → service → function is a walk, not a lookup. Risk register entries and governance documents attach to the same objects. What is not there: contract fields on the provider record — contract references, dates and costs stay in the contract file, attached as evidence — and a generated regulatory register template. The records are the spine; the template is an export you build on top of them.

Checklist

• Every ICT provider is a record with legal name, country, type, LEI, critical-function flag and owner
• Every service a provider delivers is an IT service linked to it — not implied by the contract title
• Every IT service in scope rolls up to a business solution that carries the criticality
• Concentration, substitutability and exit are recorded as risks and documents on those links
• The register (DORA) and the supplier view (NIS2) are read from the links, not maintained beside them