How to Set Up Jira for DORA Compliance: ICT Incident Reporting and Audit Trails

[#1]

Does Your Compliance Team's Workflow Fit Jira, or Fight It?

If your organization is working through DORA compliance and already uses Atlassian products, you've probably asked a very practical question: does the way your compliance team already works fit into Jira, or fight against it? Are Atlassian tools doing real work here, or just adding another place to type things twice?

This article answers that in three steps. First, we check whether Atlassian's platform is trustworthy enough to build a regulated workflow on at all. Second, we show how Jira and Confluence cover DORA's risk management and audit needs, and exactly where a new compliance manager would click to set that up. Third, we walk through DORA's ICT incident reporting requirements and show which additional tools carry the process the rest of the way.

Important note: We are not lawyers, and nothing here is legal advice. The tool recommendations are based on our expertise with Jira and on the experience of real SaaSJet clients. The regulation defines what needs to be done; the choice of tool remains yours.

What Is DORA, and Which Financial Entities Does It Apply To?

DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) has applied to EU financial entities since 17 January 2025 — banks, insurers, payment and e-money institutions, investment firms, crypto-asset service providers, and the critical ICT providers that serve them. Its goal is simple: make sure the financial sector can keep running, or recover quickly, when something goes wrong with its technology.

What Counts as ICT Risk Under DORA?

ICT stands for "Information and Communication Technology." ICT risk is any risk related to a company's IT systems. It covers:

• Cyberattacks — hackers, malware, data theft.
• System failures — servers down, a database not responding, an application not working.
• Coding errors — a bug causing incorrect calculations or data loss.
• Vendor issues — a cloud provider goes down, taking your service with it.
• Physical equipment problems — hardware failure, a data center outage.
• Human error — an employee deletes data or misconfigures a system.

The Five Pillars of DORA

1. ICT risk management — build and govern a framework for identifying, protecting against, detecting, and recovering from ICT risk.
2. ICT-related incident management and reporting — classify incidents and report them within strict deadlines.
3. Digital operational resilience testing — test your systems regularly, including advanced threat-led penetration testing for larger entities.
4. ICT third-party risk management — manage the risk your vendors and technology providers introduce.
5. Information sharing arrangements — voluntary sharing of cyber threat intelligence across the financial sector.

Not in the EU? This still applies to you in spirit. Similar rules exist elsewhere under different names — the UK's FCA/PRA Operational Resilience regime, Australia's APRA CPS 230, and others. Deadlines, article numbers, and legal terms vary, but the approach is the same: manage your risks, report incidents on time, test your resilience, and be able to show that you did. The Jira setup below follows that approach. If your local rules require a 6-hour deadline instead of DORA's 4-hour one, you adjust the numbers and field options — not the workflow.

Why Atlassian Is an Audit-Ready Platform for Regulated Work

Before asking whether Atlassian products help with DORA specifically, you need proof that Atlassian is a place a regulated business can safely build any compliance process at all. What matters is whether the records are trustworthy, whether someone independent has checked the controls, and whether there's a real paper trail. Atlassian's own security documentation gives a concrete answer to all three.

1. The record can't be quietly rewritten. Every action inside Atlassian's infrastructure is logged under a formal policy framework, reviewed annually and signed off by senior management. Logs are forwarded to a centralized platform with read-only access — even Atlassian's own staff can't edit history. Security teams monitor those logs for unusual activity, with a defined investigation process.
2. The controls are checked by someone other than Atlassian. Atlassian runs internal and independent external audits every year, evaluating both legal/contractual obligations and whether its controls actually work in practice, and continuously verifies compliance against frameworks like ISO 27001 and SOC 2.
3. When something's wrong, there's a documented fix cycle. Audit findings go through root-cause analysis, a severity rating, and a corrective action. That's the same vocabulary a bank's compliance department uses internally (MRA/MRIA, remediation plan, closure rate) — Atlassian is held to its own customers' standard.
4. The platform is stress-tested on a schedule, not just after something breaks. Annual penetration testing, an active bug bounty program, and continuous vulnerability scanning with remediation timelines tied to severity (CVSS).
5. There's an actual paper trail behind the compliance claims. Records of processing activities, privacy impact assessments, transfer impact assessments, signed data processing agreements — the artifacts an auditor would actually ask to see.

Where this sits relative to DORA: Atlassian's Trust Center frames its role as shared responsibility — it secures and documents its own platform, but each financial entity remains accountable for its own compliance posture on top of it.

How to Set Up Jira and Confluence for DORA Compliance

Pillars 1 and 2 in Practice: ICT Risk Management and Incident Reporting in Jira

DORA's first pillar asks for two different things, and each calls for a different tool.

1. A documented governance framework (policies, risk tolerance, budget). This can live as a Confluence page or a small space of linked pages. Confluence keeps a version history of every edit automatically — who changed what and when, with no configuration.

One limit is worth being precise about, because an auditor will be: version history evidences editing, not approval. Under Article 5(2) of DORA, approval of the ICT risk management framework and the resilience strategy sits with the management body. Showing that a named person approved a policy has to be a deliberate step — an approval task linked to the page, an inline sign-off, or a comment naming the approver and the date. Version history will preserve it, but will not produce it on its own.

2. An operational cycle of identifying, classifying, and responding to risk. This is what Jira is built for, and it's where the rest of this section stays. To manage the operational process and reporting, we created a dedicated space tracking two types of work: Risk and Reporting.

The Risk Work Item Workflow in Jira

This workflow shows the life of one risk, from the moment your team finds it to the moment it's closed. Every financial entity handles risk a little differently, but DORA expects the same basic steps: find the risk, decide what to do about it, and record that decision.

NEW → IN CLARIFICATION → AVOID / MITIGATE / TRANSFER / ACCEPT → RESOLVED → ARCHIVED

• NEW — The risk has just been created. Write a clear summary. Anyone opening the issue should understand the risk without asking you for details.
• IN CLARIFICATION — The team knows about the risk but hasn't chosen how to handle it.
• AVOID — The team removes the cause completely, usually by stopping the process that creates the risk.
• MITIGATE — The team reduces the risk: less likely to happen, or smaller impact, but not removed. For ICT risks, this is the most common choice.
• TRANSFER — Responsibility moves to someone else, through insurance or a vendor contract.
• ACCEPT — Management makes a clear, written decision to leave the risk as it is. This is not a way around DORA — it's a decision DORA controls. Article 6(8)(b) requires the entity to set a risk tolerance level for ICT risk, and Article 5(2)(d) requires management to approve it. So ACCEPT is only valid when it matches an already-approved risk tolerance level. It's a documented choice, not doing nothing.
• RESOLVED — The risk is removed, or no longer relevant.
• ARCHIVED — Closed. No longer active, but the record stays.

Custom Jira Fields That Carry the DORA Decisions

Without custom fields, a status like ACCEPT or MITIGATE shows what the team decided — not why, and not how big the risk is. For DORA compliance, you need to show how risk was measured, how it changed, and which decisions management approved. Custom fields also make automation possible: they let Jira create a Reporting Task automatically when a risk is classified as Major.

Field	Type	What It Means
Current Likelihood	Select (1–5)	Shows the risk's path: where it started, where it is now, and where it should end up per the approved risk tolerance level.
Target Likelihood	Select (1–5)	The Likelihood level management has approved as acceptable — the practical expression of the entity's documented ICT risk tolerance level. Required under Article 6(8)(b) as part of the digital operational resilience strategy; management approval required under Article 5(2)(d).
Current Impact	Select (1–5)	The current estimate of impact, updated at every reassessment (through Form 3 — Root Cause / Closure).
Target Impact	Select (1–5)	The Impact level management has approved as acceptable. Usually set once, at IN CLARIFICATION.
Current Risk Class	Select (1–5)	Calculated: Current Likelihood × Current Impact. Shows where the risk sits now on the Low / Medium / High / Critical scale.
Target Risk Class	Select (1–5)	Calculated: Target Likelihood × Target Impact. The goal — whether the risk has reached an acceptable level.
DORA Classification	Select	Pending / Major / Not Major. Shows whether an incident meets DORA's major threshold under Article 18. One wording note: in DORA, incidents are major and cyber threats are significant — not the same thing. The classification criteria and thresholds come from a related technical standard, RTS 2024/1772 (criteria in Articles 1–7, thresholds in Article 9). Setting this to Major makes Jira create a linked Reporting Task.
Root Cause Confirmed	Select / Checkbox	Yes / No. Marks the moment root cause analysis is complete — different from the RESOLVED status. Under Article 19(4)(c), the final report is submitted once root cause analysis is finished, even if the fix isn't fully in place. That's why it's a separate field instead of waiting for RESOLVED. Setting it to Yes moves the linked Reporting Task to FINAL REPORT DUE.

The Reporting Work Item Workflow: DORA's Three Submissions

NEW → INITIAL NOTIFICATION → INTERMEDIATE REPORT DUE → FINAL REPORT DUE → DONE

This workflow exists to help a financial entity meet its ICT incident reporting obligations to the competent authority, on time, every time. Its statuses match the three submissions required by Article 19(4), plus a starting and a closing status.

NEW — A Reporting Task is created automatically as soon as the linked Risk Task is classified as Major. This status mostly exists because every Jira workflow needs a starting status mapped to the "To Do" category.

INITIAL NOTIFICATION — The actual submission of the initial notification to the competent authority. Under Article 5 of RTS 2025/301, it must go out as early as possible — in any case within 4 hours of the incident being classified as major, and no later than 24 hours from the moment the entity became aware of the incident. Whichever limit comes first applies.

INTERMEDIATE REPORT DUE — The second submission, due within 72 hours after the initial notification is sent (RTS 2025/301, Article 5). The clock starts when the notification is sent, not when the incident was classified. It gives an updated view: what changed, and any new information found. You submit it even if nothing has changed. This status can repeat — DORA requires an updated intermediate report without undue delay, and always once regular activities are restored.

FINAL REPORT DUE — Entered when Root Cause is confirmed. Under Article 19(4)(c), the final report is submitted once root cause analysis is complete, even if remediation is ongoing — so the task can reach this status while the technical team is still fixing the problem. Under Article 5 of RTS 2025/301, the final report is due no later than one month after the intermediate report, or after the latest updated intermediate report.

DONE — All three required submissions have been sent. The reporting obligation for this incident is complete.

From here, everything runs on Jira's built-in features. If you're new to Jira, the steps below show exactly where to click.

Step-by-Step: Creating the ICT Incident and DORA Reporting Space

1. Go to the Spaces menu and click "+". Choose a company-managed Space — only company-managed Spaces support fully custom workflows, custom work item types, and field configurations that can later be shared across other Compliance Spaces. You can also connect this Space to a Confluence Space, so governance documentation and operational workflow stay linked.

Step-by-Step: Creating Your Own Work Item Types

1. Go to Jira admin settings → Manage Space, find your Space, click "…", select Space settings.
2. Go to Work items → Types → Actions → Edit work item types → Modify Work Item Type Scheme, and create two types:

Risk Task — tracks an ICT risk from identification to resolution: classification, likelihood and impact scoring, treatment decision (avoid, mitigate, transfer, accept), and root cause confirmation. This is where DORA's operational risk-management cycle lives.

Reporting Task — tracks the regulatory obligations tied to a Major ICT incident: the three deliverables required by Article 19(4), each with its statutory deadline. Auto-created when a linked Risk Task is classified as Major. Closing it means the paperwork is done, not that the incident is resolved.

Step-by-Step: Building Your Own Workflows

1. Go to Settings → Work items → Workflows → Add workflow → Create new.
2. Give it a name (for example, "Risk Workflow") and a short description.
3. Create your two workflow schemes.

Scheme of Risk Workflow:

Scheme of DORA Reporting Workflow

Then go to Space settings, map your workflow with work types, and publish changes.

Step-by-Step: Adding the Custom Fields

1. Go to Admin Settings → Work items → Fields → Create a new field.
2. Create all the custom fields listed above. Don't forget to map each field to a Screen — otherwise it won't appear on your work items.

Step-by-Step: Automating the Link Between Risk and Reporting

Automation is what connects a Risk Task to a Reporting Task without anyone doing it manually. When a risk is classified as Major, Jira creates the reporting work item by itself.

1. Go to Space settings → Automation.
2. Trigger: Field DORA Classification changes to Major.
3. Action "Create issue":
   • Issue type: Reporting Task
   • Space: same Space
   • Summary: Reporting: {{issue.summary}}

Everything in this section runs on native Jira: two custom work item types, two custom workflows, a set of custom fields carrying the DORA-specific data, and one automation rule connecting them. A Risk Task moves through identification, scoring, and treatment on its own. The moment DORA Classification is set to Major, the automation creates a linked Reporting Task and transitions it into INITIAL NOTIFICATION. From there, the Reporting Task's workflow carries the three DORA submissions.

Extending Your DORA Compliance Setup in Jira with SaaSJet Apps

Structuring the ICT Incident Lifecycle with Smart Forms for Jira

A DORA incident evolves. What's known at detection is very different from what's known at classification, investigation, or closure. Rather than cramming all of it into one Jira screen, Smart Forms for Jira can act as structured checkpoints attached to the same work item across the incident lifecycle, each collecting exactly what's available at that stage.

A typical flow:

Incident detected → Incident Intake Form → DORA Classification Form → investigation and reporting → Root Cause / Closure Form

Each form has a different purpose, but all of them update the same Jira work item: the Intake Form can create it, the Classification Form records the classification decision, the Closure Form marks it ready to close. Selected form answers map to Jira fields, so the work item keeps driving dashboards, filters, assignments, and the automation rule above.

Phase 1: Capture the Incident as Soon as It's Detected

At the start, the priority isn't a complete regulatory record — it's capturing enough reliable information to open the incident and give the response team a structured starting point. This form is deliberately short: it's often the first point of contact with someone outside the compliance team, sometimes outside Jira entirely, at the moment they're least equipped to answer detailed questions. Every extra required field trades completeness for speed.

Field	Options / Formula	DORA Rationale
Summary	—	Clear summary of what happened
Description	—	Free-text detail not covered by the fields below; not tied to a specific DORA requirement
Initial Likelihood	1 to 5	—
Initial Impact	1 to 5	—
Initial Risk Score	{Initial Likelihood}*{Initial Impact}	—
Date/Time of Detection	—	Feeds the duration criterion (RTS 2024/1772, Article 3) — if the moment downtime began can't be established, it's measured from detection. Also the start of the 24-hour outer deadline for the initial notification, which runs from the moment the entity became aware, not from classification
Incident Type	Cyber attack / System failure / Third-party failure / Other	—

On submission, this form can create the Risk Task.

Phase 2: Classify the Incident Against the Seven DORA Criteria

Article 18 sets the classification framework for ICT-related incidents, and RTS 2024/1772 makes it measurable: seven criteria, in Articles 1 to 7, with materiality thresholds in Article 9. Once more is known, a Classification Smart Form can guide the responsible team through these criteria in sequence instead of putting every question on the Jira screen. Conditional logic keeps it manageable — a question about financial counterparties only appears if the affected service involves them — and the form calculates derived values, like the percentage of clients affected, instead of asking someone to do it by hand.

Field	Options / Formula	DORA Rationale
Clients Using the Affected Service	—	A reference figure for the relative threshold below; DORA doesn't require this field itself. Important: the denominator is clients of the affected service, not the entity's whole client base. For a multi-product entity, these are fundamentally different numbers
Clients Affected	—	The "clients, financial counterparts and transactions" criterion (Article 1, RTS 2024/1772) — direct and indirect clients
% of Clients Affected	{Clients Affected}/{Clients Using the Affected Service}*100	Article 9(1), RTS 2024/1772: threshold met if more than 10% of clients using the affected service are affected, or more than 100,000 clients in absolute terms. The same criterion has two further dimensions worth tracking separately: more than 30% of financial counterparts depending on the affected service, and more than 10% of average daily transaction count or value
Can affected count be determined?	Yes / No	If the exact number can't be determined, a reasonable estimate is used and that fact is recorded in the Classification Rationale. This is not an automatic basis for a major classification — the rule that thresholds count as met when information is lacking applies to significant cyber threats, not to incident classification. Don't conflate the two
Reputational Impact	None / Media coverage / Client complaints / Counterparty or regulator enquiry / Loss of clients or counterparts	The "reputational impact" criterion (Article 2; threshold Article 9(2)). This is the seventh criterion and the one most easily missed — no single numeric threshold, assessed by indicators. If a form claims to cover the RTS criteria, this one needs to be in it
Duration (hours)	—	The "duration and service downtime" criterion (Article 3; threshold Article 9(3)): incident duration over 24 hours, or downtime over 2 hours for ICT services supporting critical or important functions. Two different numbers — keep them in separate fields. If the moment downtime began can't be determined, it's measured from detection
Geographic Spread	Member States	The "geographical spread" criterion (Article 4; threshold Article 9(4): impact in two or more Member States). A multi-select fits because the threshold is counted by their number
Data Loss Type	None / Availability / Authenticity / Integrity / Confidentiality	The "data losses" criterion (Article 5; threshold Article 9(5)). DORA consistently lists four data properties — availability, authenticity, integrity, confidentiality — so Authenticity has to be an option. The threshold is also met in case of data loss through unauthorized access to systems
Criticality of Services	Critical / Important / Neither	The "criticality of the affected services" criterion (Article 6). Under Article 8 this is a gateway condition, not one criterion among equals — the incident is weighed against the other thresholds only once a critical or important function is affected. This field belongs first in the form, not tenth
Financial Loss Estimate	—	The "economic impact" criterion (Article 7; threshold Article 9(6): costs and losses have exceeded, or are likely to exceed, EUR 100,000). It's the sum of all cost types, so link it to the three cost fields in the Closure form
Estimated / Confirmed	Estimated / Confirmed	Our own addition — the initial notification may contain estimates, the final report requires confirmed figures
DORA Classification	Pending / Major / Not Major	The decision under Article 18 (against the thresholds in Articles 8–9, RTS 2024/1772), which triggers the obligations in Article 19
Classification Rationale	—	Entities must apply the criteria consistently and document why. Because the Article 8 logic — gateway plus at least two thresholds — is a judgement, not arithmetic, this written rationale is the actual evidence behind the decision
Classification Authority (Approver)	—	Article 17(3)(c) requires assigning roles and responsibilities activated for different types of ICT-related incidents

The Smart Form attaches to the Risk Task as a checklist and can update the DORA Classification field on the linked work item directly. That field is what the automation watches: DORA Classification = Major triggers the Reporting Task. The completed form stays attached as the rationale behind that decision; not every answer needs to become a separate Jira field, only the ones the rest of the workflow acts on.

Phase 3: Keep Operational Work and Audit Evidence Connected

During investigation, additional Smart Forms can attach to the same work item instead of living as disconnected documents. A form can double as a structured checklist for the people working the case, while only the operationally important values — status, owner, confirmed impact — map to Jira fields. That keeps the work item from turning into dozens of custom fields, while the full incident record stays connected to the work.

Phase 4: Confirm Root Cause and Close

As the incident moves toward resolution, root cause is confirmed, costs are known, and remediation has an owner. This is also the point to look back and compare what was assumed at intake against what was confirmed: Initial Risk Score against Current Risk Score, Estimated against Confirmed Financial Loss. That comparison is itself useful evidence for the lessons-learned section of the final report.

Field	Options	DORA Rationale
Root Cause Confirmed	Yes / No	Article 19(4)(c) — this event, not RESOLVED, is the content condition for the final report. The deadline itself still runs from submission of the intermediate report (one month, Article 5, RTS 2025/301), not from this checkbox
Root Cause Description	Full description of the cause	Content for the final report — the root cause analysis Article 19(4)(c) requires to be complete before final submission
Contributing Factors	—	Supports completeness of the root cause analysis. The exact section structure comes from the templates in Implementing Regulation (EU) 2025/302 — check against the current template before publishing
Client Notification Required	Yes / No	Article 19(3) — a separate obligation to notify, without undue delay, clients whose financial interests are affected, and the measures taken. Not part of the reporting cascade to the regulator (that's paragraph 4) — it runs in parallel
Direct Cost	—	The "economic impact" criterion (Article 7, threshold Article 9(6), RTS 2024/1772) + the cost section of the final report
Recovery Cost	—	Same — recovery costs are part of the economic impact criterion, calculated as the sum of all cost and loss types
Regulatory Cost	—	Same — fines and regulatory costs as part of the full economic impact picture
Current Impact / Current Likelihood	Reassessed at closure	Not from the DORA text — our own risk-management practice of tracking the trajectory, not a regulatory requirement
Current Risk Score	{Current Likelihood}*{Current Impact}	Same — a derived value for internal risk management
Lessons Learned	—	A section of the final report + supports Article 17(2) DORA and Article 22(d), RTS 2024/1774 — mechanisms to analyse significant or recurring incidents and patterns in how often they occur
Remediation Owner	—	Article 17(3)(c) — the entity must assign roles and responsibility for handling different types of incidents

Submitting the Smart Forms can move the work item to its next status, and restrictions can limit who is allowed to complete or edit it — useful when only a named Classification Authority should be able to confirm the DORA Classification decision.

How to Track DORA Reporting Deadlines in Jira with SLA Time and Report

Classifying an incident as Major and building the Reporting Task workflow only gets a financial entity halfway. DORA's ICT incident reporting obligations come with hard deadlines to the competent authority. This is where SLA Time and Report for Jira takes over. For each deadline you configure an SLA with start and stop conditions matching the actual events in your workflow, so the countdown reflects the real regulatory clock rather than generic ticket age.

SLA Goal	Limit	Start	Source
Initial Notification — limit from classification	4 hours	DORA Classification = Major (the moment the Reporting Task is created)	The submission is required by Article 19(4)(a) DORA. The 4-hour limit runs from the moment the incident is classified as major — Article 5, RTS 2025/301
Initial Notification — outer limit	24 hours	Date/Time of Detection	Article 5, RTS 2025/301: no later than 24 hours from the moment the entity became aware of the incident
Intermediate Report	72 hours	Status changes INITIAL NOTIFICATION → INTERMEDIATE REPORT DUE	Article 19(4)(b) + Article 5, RTS 2025/301 — the clock runs from submission of the notification, not from classification. Due even if nothing has changed; an updated intermediate report must be sent without undue delay, and in any case once regular activities are restored
Final Report	1 month	Status changes INTERMEDIATE REPORT DUE → FINAL REPORT DUE	Article 5, RTS 2025/301. Article 19(4)(c) separately requires root cause analysis to be complete at submission — a content condition, not the start of the clock. Setting Root Cause Confirmed to Yes moves the task into this status, but does not by itself start this SLA

You can also turn on breach alerts. Pre-breach warnings arrive as a comment directly on the ticket, so the assignee and reporter see the countdown tightening before the deadline hits. Once a deadline is actually breached, that notification can also be routed to a Slack channel — so the compliance manager and the wider team find out the moment a limit is missed, not just the person watching the ticket.

One calendar detail: Under Article 5(4) of RTS 2025/301, where a submission deadline falls on a weekend or a public holiday in the entity's Member State, the report may be submitted by noon of the next working day. But Article 5(5) withdraws that allowance — for the initial notification and the intermediate report — from credit institutions, central counterparties, operators of trading venues, and entities identified as essential or important under Article 3 of Directive (EU) 2022/2555. In plain terms: if you're a bank, the clock on the first two submissions does not pause for the weekend. Good reason not to apply a single working calendar to all four goals above.

SLA Goals Beyond Regulatory Deadlines

Everything above covers the deadlines DORA sets for reporting a Major incident. But nothing stops a compliance or risk team from setting internal SLAs for how long a Risk Task should sit in a given stage, whether or not the incident ever becomes reportable.

For example: a risk shouldn't stay in IN CLARIFICATION for more than 5 hours before a treatment decision, or MITIGATE work should show progress within a set number of days. DORA doesn't set a time limit on risk treatment, but Article 17(2) does expect procedures for monitoring, handling, and following up on ICT risk consistently — and an SLA that flags a risk quietly sitting untouched for weeks is one practical way to show that follow-up is actually happening, not just documented as a policy.

Proving the Deadlines Were Met, Not Just Tracking Them

Configuring SLA rules answers the forward-looking question: will we make it. A month later, an examiner asks a different one: did you, every time, and how do you know. SLA Time and Report answers that too, which is why the deadline evidence lives here rather than in change-log tooling.

DORA requirement	What it asks for in practice	The feature that produces it
Article 5, RTS 2025/301 — three reporting deadlines, each with its own start event	A per-incident record of whether each configured reporting SLA was met or exceeded, including SLAs starting from different events	The SLA Grid: every SLA goal for every incident in a structured table, selectable by space, SLA configuration, saved filter, JQL, sprint, label, or reporter, with columns you choose on export
Article 22, RTS 2024/1774 — mechanisms to analyse patterns across incidents	Whether a near-miss was one bad quarter or something systemic, and whether it clusters around a person, a severity level, or something else	Met vs Exceeded shows how many goals were met and breached across a period. Met vs Exceeded per Criteria breaks the same result down by any field on the work item — Assignee, Severity, Urgency, Source and dozens more — so a pattern doesn't stay hidden inside an aggregate
Article 22(d), RTS 2024/1774 — retain evidence securely, for a period commensurate with criticality	A deadline-compliance archive that builds itself, instead of depending on someone remembering to pull a report before an audit	The Report Scheduler emails an .xlsx snapshot to named recipients on a recurring schedule — monthly, on a chosen day and time, in the entity's own timezone. The same data exports on demand as CSV, PDF, JPEG, or SVG
Article 5(4)–(5), RTS 2025/301 — the weekend allowance and the entity types it doesn't apply to	Different working calendars for different SLA goals, inside the same Jira space	Each SLA configuration has its own working calendar. On the Advanced plan, calendars can also match the assignee's regional schedule — useful when a compliance team spans time zones

How to Build a DORA Audit Trail in Jira with Issue History

After the reports go out, the questions change. Instead of "did you meet the deadline," an auditor asks: "show me exactly what happened, who was involved, and whether the same issue keeps coming up." Issue History for Jira is built for that moment — it turns Jira's own change history into an audit trail you can search, filter, and export across every incident this quarter, rather than opening one ticket at a time.

Three requirements sit behind that question, and each asks for something different:

• Article 17(2) DORA — record all ICT-related incidents and significant cyber threats, and establish procedures for monitoring, handling, and following them up so that root causes are identified, documented, and addressed.
• Article 22, RTS 2024/1774 — retain all evidence relating to ICT-related incidents securely, for a period commensurate with the criticality of the affected functions and assets, and put mechanisms in place to analyse significant or recurring incidents and patterns in how often they occur.
• Article 8(2), RTS 2024/1772 — recurring incidents that are individually not major but cumulatively meet the conditions for one. Implementing Regulation (EU) 2025/302 requires these to be reported in aggregated form — a pattern you can't see one incident at a time.

DORA requirement	What it asks for in practice	The feature that produces it
Article 17(2) DORA — record all incidents and follow them up so root causes are identified and documented	A record of the incident that survives the incident itself: what was entered, when, by whom, and how it changed as the investigation moved on	Complete work-item history — every field change with old and new value, every status transition, every reassignment, logged as its own event rather than a summary
Article 17(3)(c) DORA — assign roles and responsibilities activated for different incident types	Proof that whoever classified the incident, or confirmed the root cause, was authorized to do it	Every change is attributed: who, when, and what changed from what to what — including changes made by automation, such as a Smart Form submission. A change to DORA Classification, Classification Authority, or Root Cause Confirmed is tied to a named actor with a timestamp
Article 22, RTS 2024/1774 — mechanisms to analyse significant or recurring incidents and patterns	Reading across a population of incidents, not one ticket at a time	Cross-issue reporting: define the incident population by space, assignee, sprint, label, date range, or other Jira fields, then read the full change history of all of them in one table, with the columns you choose
Article 22(d), RTS 2024/1774 — keep evidence available as long as needed, and hand a specific pull to someone outside Jira	Evidence that can be pulled, filtered, and shared without asking the recipient to log into Jira	Export the filtered report to XLSX, CSV, or PDF for your retention schedule, share it by email to named recipients, or as a copyable link
Articles 18–19 DORA — showing, after the fact, when the incident was classified as major and when each submission went out	The moment that starts the reporting clock, and evidence each step happened	The moment DORA Classification changed to Major is a logged, timestamped field change. The comment recording that a notification was submitted sits in the same record, in the same export

A quick note on deletion. Issue History includes a recovery feature for deleted work items — useful if a Risk Task or Reporting Task is removed by mistake. It's worth knowing exactly what "recovery" means: the item returns as a new work item with a new key, starts in To Do, and has its comments restored (marked as restored) but not its original attachments. A separate deleted-items view shows the field values at deletion, which helps spot what happened. Given how recovery works, a more reliable approach for a regulated workflow is to restrict who can delete a Risk Task or Reporting Task.

Fix What's Slowing Your DORA Process Down with Time in Status

Time in Status provides workflow intelligence: it shows where work actually waits inside a Jira process, and why. That matters for DORA compliance because Article 17(2) requires procedures to monitor, handle, and follow up on ICT risk. A risk sitting untouched in IN CLARIFICATION for ten hours isn't a paperwork gap — it's a broken process.

If Risk Tasks stall in IN CLARIFICATION, the fix usually isn't to "remind people faster" — it's to check whether the classification criteria let a responder decide quickly. Time in Status won't make that decision for you, but it tells you where to look, which is the first step to fixing the process rather than just tracking the problem.

What's actually happening	The feature that shows it	Why it matters here
A stage has no regulatory deadline, but is quietly stalling anyway	Average Time across the treatment statuses (IN CLARIFICATION, MITIGATE and so on), comparable by project, assignee, or issue type	Surfaces the risks being actively worked versus the ones quietly parked — the gap Article 17(2)'s consistent follow-up is meant to close
An incident bounces backward instead of moving forward	Status Count shows how many times a work item re-entered a status; Transition Count shows how work actually moved between stages	A risk cycling through IN CLARIFICATION three times is a rework signal pointing at the process — unclear criteria, missing information at intake — not at any one person. The unit of improvement is the workflow, not whoever is assigned
A report needs to be readable by someone outside the day-to-day team	Status Groups merge related statuses into one line — the four treatment statuses can read as a single "In treatment" stage — producing clean cycle and lead time figures. The dashboard gadget puts the same numbers in front of leadership for standing oversight	Turns a Jira-native report into something a compliance lead or second-line reviewer can actually read
The final report still needs a full timeline	Time in Status per Date and Status Entrance Date give exact durations and entry dates per stage for one incident	A genuine side benefit for Article 19(4)(c) — the timeline falls out of the same data already being used to find and fix bottlenecks

Make Jira Do the DORA Compliance Work, Not Just Track It

DORA does not require you to buy new software. It requires you to demonstrate that risk was managed, that deadlines were met, and that evidence is available whenever it is requested. Jira, set up as described here, carries that end-to-end: a workflow for risk, a workflow for reporting, custom fields holding the regulatory decisions, and automation linking the two the moment a risk is classified as Major. The four applications in this article run the same process faster, more automatically, and in a way that is easier to verify.

• Smart Forms for Jira turns intake and classification into a trigger: submitting a form creates the Risk Task and fills the fields that control the workflow.
• SLA Time and Report for Jira watches the 4-hour, 72-hour, and one-month clocks, so nobody has to keep deadlines in their head while working on an open incident.
• Issue History for Jira builds the audit trail as a side effect of the classification and reporting work already happening, so "prove it happened" doesn't mean reconstructing a timeline from memory the week before an exam.
• Time in Status turns the same data into a way to spot a halted process before it becomes a finding, rather than after.

None of this makes an entity compliant on its own — that remains a decision for your own compliance and legal teams, based on your internal control framework. What these apps do is take the workflow you have already set up in Jira and run more of it for you: fewer statuses moved by hand, fewer deadlines held in someone's head, fewer reports rebuilt from scratch.

When your DORA process still depends on someone remembering what the next step is, that's a sign it should be part of the workflow instead.

[Dave Rosenlund _Trundl_]

Normally, I skip the articles written by Marketplace partners (because they are all about selling their products, and offer no other valuable learning).

But once I started reading this one, I just kept reading.

Great job, @Mariia_Domska_SaaSJet  👍

P.S. You may want to remind your readers there are two DORA's.  One from Google, and one from the EU, and they are about entirely different things 😉

[Mariia_Domska_SaaSJet]

@Dave Rosenlund _Trundl_ Thank you for the warm words and your support. And thank you for remaining about two DORA's; that's why I explained at the start of the article which DORA I was talking about. I would have written out the full term more often if I had not faced character limits. The original version was longer, but I needed to shorten it to publish it here.

[Carlos Faddul]

Very good article @Mariia_Domska_SaaSJet ! It helps to clarify and better understand some key points of DORA audits

[Arkadiusz Wroblewski]

Good Job @Mariia_Domska_SaaSJet 

I can relate with @Dave Rosenlund _Trundl_ , Mostly, I just get the next notification, look at it... Advertisement - go further, but here I stopped for a moment :)