The DORA register of contractual arrangements with ICT third-party providers. It is more than a list of vendors, because it must support supervisory evidence, distinguish critical services, and stay accurate as subcontracting chains, AI dependencies, and business usage change over time.
Expanded Definition
An Article 28(3) register is the DORA-required inventory of ICT third-party contractual arrangements that a financial entity must maintain so supervisors can assess dependency, concentration risk, and operational resilience. It is not merely procurement documentation; it is an evidence record that ties each service to business impact, criticality, and oversight obligations under the EU Digital Operational Resilience Act and the European supervisory expectations that accompany it.
Definitions vary across vendors and compliance teams, but the practical standard is consistent: the register must show which ICT services exist, who provides them, what data or functions they support, and whether subcontractors, cloud services, or AI-enabled components materially alter the risk profile. That makes it adjacent to vendor management, yet distinct from a simple supplier list, because the register must stay current as contractual scopes, service chains, and operational dependencies change. The NIST NIST Cybersecurity Framework 2.0 is useful here because it frames governance, asset visibility, and risk response as continuous functions rather than one-time filings.
The most common misapplication is treating the register as a static spreadsheet, which occurs when procurement owns it alone and operational teams do not update it after subcontracting, architecture, or usage changes.
Examples and Use Cases
Implementing an Article 28(3) register rigorously often introduces reporting overhead, requiring organisations to weigh supervisory clarity against the cost of collecting and validating contract-level detail across business units.
- A payments firm records its core cloud platform, the managed security service attached to it, and the downstream support provider so the register reflects the full ICT dependency chain.
- A bank flags an AI-based fraud detection service as a critical ICT arrangement because it influences customer-facing decisions and incident response obligations, not just software procurement.
- A financial institution updates the register after a provider adds subcontracted storage, ensuring the new chain is visible to risk owners before the next supervisory review.
- A resilience team uses the register to identify which services support essential business functions, then aligns that view with controls described in the Ultimate Guide to NHIs when service identities, API keys, or machine credentials are part of the outsourced stack.
- An internal audit function compares the register against incident records to confirm whether critical dependencies were known before an outage, breach, or provider failure.
For practitioners who manage digital identity infrastructure, the register becomes more reliable when contract records, service accounts, and secrets management are reviewed together, because the operational reality of a vendor often lives in its non-human identities rather than in the legal agreement alone.
Why It Matters in NHI Security
An Article 28(3) register matters because third-party risk increasingly flows through machine identities, integrations, and service credentials, not just named suppliers. NHI governance depends on knowing which external parties can create, use, or inherit access paths into production systems. NHI Mgmt Group research shows that Ultimate Guide to NHIs reports 92% of organisations expose NHIs to third parties, which is exactly why an accurate register must track more than contract names. If a provider is compromised, a stale register can delay containment, obscure which services were affected, and leave supervisors with an incomplete picture of exposure. That is also why the register should be aligned with resilience programs and with the NIST Cybersecurity Framework 2.0, which expects organisations to understand assets, dependencies, and response pathways.
Organisations typically encounter the real cost of an inaccurate Article 28(3) register only after a provider outage, audit finding, or incident investigation, at which point the register becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Article 28(3) | This article creates the register requirement for ICT third-party contractual arrangements. |
| NIST CSF 2.0 | GV.SC-1 | Third-party dependency oversight aligns with supply-chain governance expectations. |
| NIST CSF 2.0 | ID.AM-1 | The register is an asset and dependency inventory for ICT services and providers. |
Maintain a complete, current register of ICT third-party contracts and critical service dependencies.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
