DORA Incident Desk

Turns Jira Service Management incidents into DORA cases: major-incident classification, live report deadlines, Confluence report drafts and a Rovo agent, all running on Atlassian with no data egress.

Comment

Inspiration

Since January 2025 every bank, insurer and investment firm in the EU has had to follow the Digital Operational Resilience Act (DORA). When an ICT incident hits, the incident team has two jobs at once: fix the outage, and decide whether it is a "major ICT-related incident" under Delegated Regulation (EU) 2024/1772. If it is, a regulatory clock starts. The initial notification is due within 4 hours of that decision and no later than 24 hours after the firm became aware. The intermediate report is due 72 hours after the initial one, and the final report one month later.

The incident itself is usually handled in Jira Service Management. The classification usually happens in a spreadsheet, the deadlines in someone's head and the reports in Word. That gap is exactly where reports go late or wrong. We wanted the regulatory context to sit next to the incident, where the people handling it already work.

What it does

DORA Incident Desk turns a Jira Service Management incident into a DORA case:

  • Classification panel on the incident. Record the facts that matter: critical services, clients and transactions affected, reputational impact, duration and downtime, Member States, data impact, malicious access, costs, root cause and ICT providers. The app shows the verdict (major or not), every materiality threshold that is met and why, and the article behind each one. It also lists which facts are still unknown.
  • Reporting clock. It shows the due time of the initial, intermediate and final report, the rule each one comes from, and a status: open, due soon, overdue or submitted. Late classification and the 24-hour cap are handled.
  • One-click report drafts. The initial notification, intermediate report and final report are drafted into a Confluence space, pre-filled from the incident. Every field that still needs a human is marked. If Confluence is not set up, the draft goes to a Jira comment instead.
  • Recurring incidents. Incidents that are not major on their own, share the same apparent root cause and happen within 6 months are assessed together, as Art. 8(2) requires.
  • Rovo agent "DORA Incident Officer". Ask "Is INC-1 major under DORA?", "When is the next report due?" or "Draft the initial notification". The agent asks for missing facts, records them through the app's actions and never computes a verdict itself, so the answer always matches the panel.
  • MCP tools. The same eight actions are exposed through rovo:mcp. Custom Rovo Studio agents and external AI clients such as Claude can classify incidents, check deadlines and draft reports, with the user's own Jira permissions.
  • Teamwork Graph connector. DORA also requires a Register of Information covering every ICT third-party provider (Art. 28(3)). The app publishes that register to the Teamwork Graph as documents linked to the incidents that involved each provider. Search and Rovo can then answer questions like "which incidents involved our card processor?"
  • Runs on Atlassian. There is no egress. Incident data stays in Forge storage on the customer's own site, and the app stores no personal data. That matters for regulated firms.

How we built it

  • Forge, UI Kit and a shared rules engine. The app is a single Forge app on Node.js 24, with the UI built in UI Kit. A jira:issuePanel holds the case and a jira:adminPage holds settings, the register and an overview of open cases. Both read from one rules engine (src/dora.js) that implements the RTS thresholds and the reporting time limits.
  • Unit tests for the regulation. The rules engine has 24 unit tests. They cover strict thresholds (exactly 10% or exactly EUR 100,000 is not enough), the 24-hour cap, late classification, month-end arithmetic for the final report, recurring-incident grouping and CSV parsing of the register.
  • Rovo and MCP share the same actions. Eight action modules are attached both to the rovo:agent and to the rovo:mcp module, so the agent, Rovo Studio agents and external MCP clients all go through the same code path.
  • Permission checks as the user. Every action first reads the issue with asUser(), so nobody can see or change a DORA case for an incident they cannot open in Jira.
  • Storage and reports. Case state lives in Forge key-value storage, and reports go to Confluence through the v2 pages API.
  • Teamwork Graph. The connector uses graph:connector with @forge/teamwork-graph. It upserts one atlassian:document per provider, with issueIdOrKeys associations to the incidents that named it.
  • Demo data. Everything shown is synthetic: a fictional bank, fictional providers, fictional incidents.

Challenges we ran into

  • Getting the law exactly right. DORA's thresholds are strict inequalities, a major verdict needs critical services plus either malicious access or two other criteria, and the initial-notification deadline is the earlier of two clocks unless classification comes late. Each of these is a test now.
  • UI Kit forms. Controlled text fields in UI Kit drop keystrokes because state round-trips through the bridge. We switched to uncontrolled fields that remount when the case reloads.
  • Action inputs. An action may declare at most 10 inputs, so recording facts became three focused actions (impact, timeline, and reputation and data). That also made the agent's tool choice clearer.
  • Keeping the AI honest. The agent's prompt forbids it from deciding the verdict itself. It must call the app, quote the criteria and articles, and say what is missing.

Accomplishments that we're proud of

  • A working end-to-end flow inside Jira: incident, classification, live deadlines, a Confluence report draft, and an audit history of what changed and from where (panel or Rovo).
  • One set of actions serving three audiences: the Jira panel, the Rovo agent, and any MCP client.
  • Atlassian marks the app as eligible for Runs on Atlassian.

What we learned

Regulated teams do not need another dashboard. They need the rule, the reason and the deadline in the place where they already handle the incident. Forge's combination of issue panels, storage, Rovo actions, MCP and the Teamwork Graph makes that possible without any data leaving the customer's site.

What's next

  • Export of the official report templates (the ESA JSON/XBRL formats) from the same data.
  • Major cyber threat notifications (voluntary reporting).
  • Jira Service Management automation that opens a DORA case when a P1 incident starts.
  • A Marketplace listing.

The app supports regulatory work but is not legal advice: a person reviews and submits every report.

Built With

Share this project:

Updates

Submission history