Support

ECZ-ID DORA Readiness adds one skill, dora-evidence-review, to an agent host. When you ask whether a workspace holds the ICT third-party evidence a regulator, auditor or customer asks for, the agent runs a bundled review script over the folder you point it at, then reports which classes of evidence it found, which it did not, why each matters and what to review next.

The review works from file names and paths only. It looks for these classes of evidence:

• ICT third-party register (register of information) (primary evidence class)
• Operational-resilience / ICT risk policy (primary evidence class)
• Incident-response evidence (primary evidence class)
• Resilience-testing / continuity evidence (primary evidence class)
• ICT contractual arrangements / exit plans (supporting evidence class)

It does not open any of those files. So it can tell you that a register of information exists where a reviewer would expect one, and it cannot tell you whether the entries in it are complete or current.

Results are reported as EVIDENCE OBSERVED, EVIDENCE NOT OBSERVED, REVIEW RECOMMENDED and REVIEW REQUIRED, with a Review Priority of LOW, NORMAL, ELEVATED, HIGH and the reasons that produced it. The Review Priority is deterministic: the same file listing always gives the same result. It is not a score, a grade, a pass mark or a verdict.

The Privacy page sets out exactly what the plugin reads and what it does not. The Terms page sets out the basis on which you may use it.

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act — has applied since 17 January 2025 (Article 64). The review explains why each class of evidence is asked for by citing the articles that ask for it:

• ICT third-party register — Article 28(3): a register of information covering all contractual arrangements on the use of ICT services, distinguishing those that support critical or important functions, available to the competent authority on request.
• Operational-resilience / ICT risk policy — Articles 6 and 6(8): a sound, comprehensive and well-documented ICT risk management framework, including a digital operational resilience strategy.
• Incident-response evidence — Articles 17 and 19: an ICT-related incident management process, and reporting of major ICT-related incidents to the competent authority.
• Resilience-testing / continuity evidence — Articles 11, 24 and 26: an ICT business continuity policy, a digital operational resilience testing programme, and threat-led penetration testing for the entities identified for it.
• ICT contractual arrangements / exit plans — Articles 28(8) and 30: exit strategies for ICT services supporting critical or important functions, and one written contract setting out rights, obligations and service levels.

Those citations are description of published law, quoted so that a gap makes sense rather than merely appearing on a list. They are not a statement about your position under that law.

Nothing this plugin produces certifies DORA compliance, determines whether you are in scope, determines whether an arrangement supports a critical or important function, or satisfies any obligation you have. It cannot: it reports which documents exist in a folder, and DORA obligations sit with the entity, not with a repository. A LOW Review Priority means every class the review looks for was observed by filename — no more than that. Whether the evidence is adequate is for you, your advisers and, ultimately, your competent authority.

Most reports we can act on quickly come down to one of these, and each is faster to check than to describe in an email.

• Evidence was not observed in a repository that clearly holds it. Detection is by file name, so a register named for an internal system rather than for what it is may not match. The review skips node_modules, dist, build and similar generated directories, and it ignores hidden dot-directories other than .github, .gitlab and .well-known.
• Your evidence does not live in a repository. Most ICT third-party evidence lives in a document system, not in Git. That is normal, and EVIDENCE NOT OBSERVED here means only that the review did not see it where it looked. A common answer is to keep a pointer in the repository to where the register actually lives.
• The review stopped short in a large repository. Traversal is bounded by design, so a review cannot run away on a very large tree. Point it at the folder you care about rather than at a monorepo root.
• The host cannot find the skill. Confirm the plugin is installed and enabled in that host, and that a Node.js runtime is available — the bundled review script runs on Node and has no other dependency.
• You want to see exactly what the review did. The script is short, readable and has no build step. Read review.mjs, or run it yourself with --json for the machine-readable projection.

Email support@ecocitizenz.com. This is the support route for every EcoCitizenz product, so please name ECZ-ID DORA Readiness in the subject line.

A report we can act on usually contains:

• the plugin name and version — eczid-dora-readiness 0.1.1;
• the agent host and its version, and how the plugin was installed there — which marketplace, or a local copy;
• your operating system and Node.js version;
• what you asked the agent to do, and what you expected to happen;
• what actually happened, quoted rather than summarised;
• any error text in full and, if the review ran, the --json output — the single most useful attachment for a detection problem;
• for a detection problem, the file name and path you expected to be observed. The path is enough. We do not need the document.

Please do not send us your register, your contracts, your incident records or your test reports. They are exactly the kind of material that should not travel by email, we do not need them to fix a detection problem, and we do not want them. A file name is enough.

Nothing about diagnosing this plugin requires a credential, and we will never ask you for one. Please do not include, in a message, an attachment or a screenshot:

• passwords, passphrases or PINs;
• API keys, access tokens, session cookies or bearer tokens;
• private keys, certificates, keystores or signing material;
• .env files, CI secrets or cloud credentials;
• customer personal data, or confidential source code you are not free to share.

If you believe you have already sent us a secret, rotate it immediately — that is the only reliable remedy — and then tell us, so we can delete the message on our side.

Security reports are handled separately from ordinary support. If you believe you have found a vulnerability in this plugin, in the review script it ships, or in another EcoCitizenz service, report it to support@ecocitizenz.com with security report in the subject line, rather than raising it in a public issue.

A useful security report describes the affected component and version, the conditions needed to reproduce the issue, the impact you observed, and anything you think we would otherwise miss. Please give us a reasonable opportunity to respond before disclosing publicly, where earlier disclosure would create material risk for users.

EcoCitizenz supports good-faith security research. When testing, please do not access customer data unnecessarily, destroy or alter data, disrupt production systems, perform denial-of-service testing, or exploit an issue beyond what is reasonably required to demonstrate it. Those conditions are set out in the security research section of the Terms.

We do not operate a paid bug-bounty programme for this plugin, and this page offers no reward.

Misuse is not the same as a vulnerability. If you have seen a copied manifest on an unrelated origin, an impersonated operator, a stale or misleading proof reference, or a page imitating ECZ-ID verification, use the abuse report route. Reports are reviewed. They do not by themselves decide truth or change any credential state.

The plugin is open source, so you do not have to take any statement on these pages on trust — you can read every line it runs.

• The published plugin package — manifest, skill, review script and evidence-class reference.
• The ECZ-ID plugins page — how to install this and the other ECZ-ID plugins in your agent host.
• DORA guidance — what each evidence class is for, and how supervised entities ask for it.
• The DORA and SBOM suite — the related products, and the free ECZ-ID DORA & SBOM Pack that installs the sibling extensions together.
• The same detectors, guidance and Review Priority also ship in the free VS Code extension ECZ-ID DORA Readiness, on the Visual Studio Marketplace and Open VSX. That extension is a separate product with its own release cycle; these pages describe the plugin.

ECZ-ID DORA Readiness is published by EcoCitizenz Ltd, trading as EcoCitizenz, company number 17348848, registered in England and Wales.