DORA Incident Taxonomy Completion Procedure

Audience: regulatory schema owner, Notify DORA owner, release operator.

This procedure finishes the official-taxonomy part of DORA major ICT incident reporting. It is not a generic blocked-state note. It describes the decision and implementation path needed before Stella can claim official EBA XSD/XBRL validation for DORA incident handoffs.

Current Root Finding

Do not continue by blindly waiting for or vendoring EBA Reporting Framework 4.3. The local asset record already found that Framework 4.3 is the wrong asset for DORA major-incident reporting: it covers Third Country Branches and AMLA reporting, not DORA incident reporting. The current DORA incident implementation therefore stays on the Stella local contract and must keep reporting official EBA XSD/XBRL conformance as not-claimed until a correct machine-validation package is identified and intaken.

Source of truth: docs/legal/decisions/REG-20260502-eba-dora-incident-framework-4-3.md section “Gate 1 - Asset-scope re-verification (2026-05-02)”.

Procedure

1. Decide the correct official asset

The regulatory schema owner and Notify DORA owner must choose one of these outcomes before engineering changes the runtime conformance flag:

OutcomeWhen to choose itRequired action
No upstream machine package existsEBA/ESA still publish only legal text, annexes, forms, or PDFs for DORA incident reporting, with no XBRL/XSD/template package.Keep dora-major-incident-report-v1 as the canonical local contract. Update docs to state Stella produces an operator handoff, not official EBA XSD/XBRL conformance. Close the official-taxonomy implementation as not applicable until a package exists.
Correct official DORA-IR package existsA successor EBA/ESA package explicitly covers DORA major ICT incident reporting and includes machine-validation entrypoints for initial, intermediate, and final reports.Open a new regulatory asset record for that package. Do not reuse the abandoned Framework 4.3 asset id except as historical evidence. Continue with sections 2-5.
Operator-supplied package is requiredRedistribution is not permitted, or the official package is jurisdiction/NCA-specific.Implement an operator-supplied package path. The operator supplies the package during installation; Stella records the hash, validates offline, and still does not redistribute the package. Continue with sections 3-5, replacing vendoring steps with mount/config steps.

The decision record must include the exact source page, package filename, publication date, legal basis, and the report variants covered. A candidate package is not accepted unless it contains machine-validation entrypoints for the DORA incident report shape that Stella emits.

For a redistributable official package:

  1. Open a new docs/legal/decisions/REG-... record for the actual package.
  2. Record download URL, download date, filename, byte count, outer SHA-256, and archive file list.
  3. Re-run counsel review against the actual package notice. The RoI Path A answer is useful precedent, but it is not a substitute for final review of the DORA incident package.
  4. Unpack and scan the package for embedded third-party notices or bodies. Record whether XBRL International, EuroFiling, W3C, NCA, or other third-party files are redistributed or only referenced by URL.
  5. If approved for vendoring, copy bytes verbatim under docs/contracts/schemas/eu/dora/incident/<actual-package-id>/.
  6. Update:
    • docs/contracts/schemas/eu/eu-schema-taxonomy-assets-v1.yaml
    • docs/europe/schema-taxonomy-pin-inventory.md
    • NOTICE.md
    • docs/legal/THIRD-PARTY-DEPENDENCIES.md
    • third-party-licenses/
    • the package-local README with provenance and scan evidence.

For an operator-supplied package, do not add package bytes to the repo. Add only the config contract, hash-recording procedure, and operator verification docs.

3. Implement Notify validation

The Notify DORA connector must add the incident equivalent of the RoI validator pattern:

  1. Add a SHA-256-pinned asset loader, for example DoraIncidentTaxonomyAsset, that reads only local package bytes.
  2. Add DoraIncidentTaxonomyValidator for the generated initial, intermediate, and final report XML/iXBRL artifacts.
  3. Map each report variant to the official package entrypoint schema or XBRL filing rules. This mapping must be explicit and tested.
  4. Fail closed when the package is absent, has a hash mismatch, lacks the expected entrypoints, or validation fails.
  5. Keep the local contract fallback for deterministic handoff generation, but do not set claimed-against:<official-package> unless the official package validator ran successfully.
  6. Include validation diagnostics in the handoff envelope/manifest so stella verify dora-incident-report can replay the claim offline.

Runtime, tests, replay, export, and verification must never fetch regulator schemas over the network.

4. Update CLI, readiness, and operator install flow

The release/operator path must prove the installed site uses the same pinned package as the build:

  1. stella export dora-incident-report emits the official conformance status and package id in the manifest.
  2. stella verify dora-incident-report verifies hashes, DSSE binding, local signature, and official taxonomy validation status offline.
  3. Notify/Assurance readiness reports a stable missing-package or package-mismatch reason when the official package is absent or invalid.
  4. Release notes list the package id, filename, byte count, SHA-256, license notice, and whether the package is vendored or operator-supplied.
  5. During install/upgrade, the operator verifies the package hash before treating DORA incident handoffs as official-taxonomy validated. Filing with the competent authority remains operator-controlled.

5. Required tests and evidence

Focused proof before marking the sprint task done:

Completion evidence must include the exact commands, pass counts, package hash, and the generated handoff manifest showing claimed-against:<official-package-id> only after official validation passes.