DORA Article 28 ICT Third-Party Register Schema

Developer-friendly schema for the maintained register every EU financial entity must hold under DORA Regulation (EU) 2022/2554, Article 28(3).

Why this exists

The ESAs' Implementing Technical Standard for the register (JC 2024 53) is published as XBRL — perfect for supervisory reporting tools, hostile for the day-to-day engineering teams who have to keep the register accurate. This repo gives you the same field set as JSON Schema and YAML, with each field traced back to its DORA article.

Use it to:

• Validate your existing register against DORA Article 28 requirements
• Bootstrap a new register without reinventing the schema
• Generate type definitions for TypeScript / Python / Go
• Feed into AI agents that read your register
• Diff your register against the regulation when ESAs publish updates
• Sanity-check what your GRC vendor is storing under the hood

What's in the box

• schemas/ — JSON Schema (draft 2020-12) + YAML equivalent
• examples/ — three worked examples (critical cloud, non-critical SaaS, sub-contractor chain)
• docs/field-to-article-mapping.md — every field traced to its DORA article number
• docs/supervisory-evidence-checklist.md — what supervisors actually ask for
• docs/implementation-notes.md — gotchas we've hit

Quick start

Python (jsonschema)

import json, yaml
from jsonschema import Draft202012Validator

schema = json.load(open("schemas/ict-third-party-register.schema.json"))
record = yaml.safe_load(open("examples/example-cra-cloud-provider.yaml"))

Draft202012Validator(schema).validate(record)
print("Register entry is valid against DORA Article 28 schema.")

Node (ajv)

import Ajv2020 from "ajv/dist/2020.js";
import addFormats from "ajv-formats";
import { readFileSync } from "node:fs";
import { load } from "js-yaml";

const ajv = addFormats(new Ajv2020({ strict: false }));
const schema = JSON.parse(readFileSync("schemas/ict-third-party-register.schema.json", "utf8"));
const record = load(readFileSync("examples/example-cra-cloud-provider.yaml", "utf8"));

const validate = ajv.compile(schema);
if (!validate(record)) {
  console.error(validate.errors);
  process.exit(1);
}
console.log("Register entry is valid against DORA Article 28 schema.");

Generate TypeScript types

npx json-schema-to-typescript schemas/ict-third-party-register.schema.json \
  > src/types/ict-third-party-register.d.ts

Limitations

• Not a substitute for legal advice. The schema is field-complete against the regulation text as published in 2022 and the ESAs ITS final draft (JC 2024 53), but supervisors may request additional context.
• Synthetic example data only. No real providers, no real LEIs, no real contracts. The examples are illustrative.
• Field set will evolve as the ESAs publish further implementing/regulatory technical standards. PRs welcome (see .github/ISSUE_TEMPLATE/).
• National competent authorities may add fields. The schema covers the EU baseline; if your NCA mandates additional attributes (CBI, BaFin, AMF, AFM, etc.), extend the schema in a project-specific overlay rather than fork.
• Not an XBRL transformer. This is the human/engineering register. If you need to submit to a supervisor in the ESAs XBRL format, run a separate mapping step from this schema.

About FiorLab

FiorLab is an EU-native supplier risk intelligence platform purpose-built for DORA, EBA outsourcing, and GxP compliance. We built this schema because we needed it in-house and saw no public, developer-friendly equivalent. See our DORA deep-dive and the DORA Article 28 Evidence Checklist that complements this repo.

Contributing

Found a field that's misaligned with the regulation, or a missing obligation? Open an issue using one of the templates in .github/ISSUE_TEMPLATE/. PRs that cite the relevant article or ITS paragraph get merged fastest.

License

MIT — see LICENSE. Use it, fork it, build commercial products on top of it. Attribution appreciated, not required.