DORA Incident Reporting in Jira: How to Track the 4h, 24h, 72h, and 1-Month Deadlines

[#1]

A major ICT incident is classified at 2:30 PM. You open Jira, see 4 hours left to submit the report, and start watching the clock.

Except here's the catch: the real deadline may have started hours earlier.

Submitted the initial notification? A brand-new 72-hour timer immediately starts ticking. Made it to the final report? Here, "one month" isn't just an automatic "+30 days."

DORA incident reporting isn't so much about moving tickets across a board – it's a time-tracking puzzle with several different starting points.

My colleague Mariia recently published a broader guide on how to set up Jira for DORA compliance, covering the incident workflow, classification, Reporting Tasks, forms, and audit history. If you are building the whole process, I recommend starting there.

Here, I want to focus on a narrower question:

Once that workflow exists, how do you make sure Jira is tracking the right deadline?

This is also where Jira can become part of a practical compliance tracking software setup: not by interpreting DORA for you, but by making regulatory deadlines visible and measurable inside the workflow your team already uses.

⏱️ There isn't really one “DORA reporting SLA”

Article 5 of Commission Delegated Regulation (EU) 2025/301 defines several reporting deadlines for major ICT-related incidents.

Reporting milestone	Deadline	Starts from
Initial notification	Within 4 hours	Classification as a major ICT-related incident
Initial notification – outer limit	No later than 24 hours	Awareness of the incident
Intermediate report	Within 72 hours	Submission of the initial notification
Final report	Within 1 month	Intermediate report, or latest updated intermediate report

The third column is the important one.

The 72-hour clock does not start at classification. The final-report deadline does not start when the incident is resolved. And the 24-hour limit does not necessarily start when somebody creates a Jira ticket.

You can have a perfectly green SLA and still be tracking the wrong deadline if the timer starts from the wrong event.

That is why, with SLA Time and Report for Jira, I would not try to force all four requirements into the same SLA setup.

⚙️ First decide: fixed duration or actual deadline?

There are two useful patterns here.

If the requirement is a fixed amount of time after a Jira event that accurately represents the real event, a Time-limit SLA is usually the simplest approach. For example:

Major classification → 4 hours

or:

Initial notification submitted → 72 hours

But sometimes the real regulatory timestamp exists before Jira catches up. In that case, starting a new timer from ticket creation or a later status change can shift the deadline.

That is where a Negotiated Date SLA becomes more useful.

Instead of giving every work item the same duration, it tracks a date or date-time already stored in Jira. Each incident can therefore have its own actual target.

The practical rule I would use is:

If Jira captures the real event → start the timer there.
If it doesn't → store the real deadline first, then track it.

👀 Case 1: The Initial Notification actually has two time limits

Imagine your organization becomes aware of an ICT incident at 9:00 AM.

At 2:30 PM, the team classifies it as a major ICT-related incident. Now you have:

Classification + 4h → 6:30 PM

and:

Awareness + 24h → 9:00 AM next day

In this example, the four-hour deadline comes first.

If classification happens close to the end of that first 24-hour period, however, the awareness-based limit can become tighter. And if the incident is only classified as major after those first 24 hours have already passed, Article 5(2) applies a separate four-hour requirement from the later classification.

How I would track the 4-hour limit

If the same Jira work item records the classification event, the setup is straightforward:

Start → Classification = Major

Goal → 4 hours

Stop → Initial Notification submitted

Here, SLA Time and Report adds value by turning the actual classification event into a visible countdown on the work item, rather than leaving the deadline in a spreadsheet or someone's calendar.

But if your Reporting Task is created after classification, I would not automatically start the four-hour SLA from ticket creation.

Even a 15-minute delay between classification and ticket creation means a 15-minute shift in the regulatory deadline.

In that situation, record the real Major Classification Time, calculate the corresponding deadline in Jira, and track that Date Time field with a Negotiated Date SLA.

And for the 24-hour outer limit

The same principle applies even more strongly. Keep the real:

Awareness Time

and a separate:

Initial Notification Outer Deadline

Conceptually:

Outer Deadline = Awareness Time + 24 hours

Jira Automation supports adding hours to date/time values, so this deadline can be populated automatically.

Then SLA Time and Report tracks the resulting deadline instead of starting another fresh 24-hour timer.

That matters if awareness happened at 9:00 AM but the Reporting Task was only created at noon. The team should still see a deadline of 9:00 AM the next day  –  not noon.

⚙️ Case 2: The 72-hour clock starts after submission

The Intermediate Report is easier because the duration itself is fixed.

DORA gives you 72 hours from submission of the Initial Notification. So this would be wrong:

Major classification → 72 hours

The useful setup is:

Initial Notification submitted → 72 hours → Intermediate Report submitted

If the Jira transition happens at the same time as the actual submission, a Time-limit SLA in SLA Time and Report is enough.

This keeps the team focused on the next real milestone. As soon as the initial notification is submitted, they can see how much of the 72-hour window remains directly in Jira.

But again, the quality of the SLA depends on the quality of the event.

If somebody changes the Jira status at 4:50 PM and sends the actual notification at 5:20 PM, your SLA starts 30 minutes too early. If those events cannot reliably happen together, store:

Initial Notification Submitted At

calculate:

Intermediate Report Deadline = Submitted At + 72 hours

and track that deadline instead. The goal is not to build the most complicated SLA configuration. It is to make sure the Jira clock matches the real reporting clock.

📅 Case 3: One month is not the same as 30 days

The Final Report is where I would avoid a normal 30-day SLA.

Article 5 requires it no later than one month after the Intermediate Report or, where applicable, the latest updated Intermediate Report. So:

Final Report SLA = 30 days

can produce the wrong date. Instead, keep the relevant submission timestamp and an explicit Jira field such as:

Final Report Deadline

Conceptually:

Latest applicable Intermediate Submission + 1 calendar month → Final Report Deadline

Once your reporting process has calculated and validated that date, use it as the target of a Negotiated Date SLA.

This is an important separation of responsibilities. Jira or your compliance process determines what the regulatory deadline is.

SLA Time and Report answers the operational question: Are we still on track to meet it?

I would also keep this field visible rather than hiding the calculation completely inside automation. Calendar-month calculations have edge cases around month-end dates, so for a regulatory workflow the result should be tested and reviewable.

📅 Calendars matter  –  but don't use them to reinterpret DORA

SLA calendars are useful here, but there are two different jobs to separate.

For the regulatory countdown itself, I would generally use a 24/7 work schedule unless your validated compliance logic requires something different. SLA Time and Report calendars exclude non-working time, so putting a normal Monday–Friday calendar on a statutory clock can change how the remaining SLA time is calculated.

This is particularly important because DORA's weekend rule is not simply “pause the timer.”

Article 5 allows some deadlines falling on a weekend or bank holiday to move to noon of the next working day, but it also defines exceptions for certain entities, and competent authorities can extend those exceptions to other significant or systemic entities.

So when an adjusted deadline applies, I would store the actual validated deadline in Jira rather than expecting a business-hours calendar to derive it.

Where flexible calendars are genuinely useful

The teams working around the regulatory deadline may still follow very different schedules.

Your incident team may operate 24/7. Legal may work local business hours. Another part of the process may move between teams in different time zones.

For those internal response, review, or handoff SLAs, the flexible calendars in SLA Time and Report are much more valuable. You can configure schedules around real working hours, time zones, holidays, and non-working periods instead of treating every team as if they worked the same day.

And if responsibility moves between people working on different schedules, the Multiple-scheduler SLA can use the calendar assigned to the current assignee and switch when ownership changes.

I would keep those internal SLAs separate from the statutory DORA timer. That gives you both:

a regulatory deadline that does not move because somebody is off shift, and internal SLAs that reflect when the people doing the work are actually available.

🔔 The real value is knowing which deadline needs attention now

Once all these deadlines are configured, the biggest benefit is not having four more timers. It is being able to open an incident and immediately understand:

Which reporting milestone are we working toward?
How much time is left?
Are we already getting too close?

SLA Time and Report keeps that information on the Jira work item and can warn the responsible people before a goal is exceeded.

For a DORA workflow, I would treat that as an internal control.

The app does not submit the report and does not make the organization compliant. But it reduces the chance that a deadline exists somewhere in the process without being visible to the people who need to act on it.

📊 And after the incident, the question changes

During the incident, you care about: How much time is left?

Afterwards, you care about: Did we meet it?

That is where the same SLA data becomes useful for review.

Instead of reconstructing every deadline manually, teams can use SLA results to see which reporting targets were met or exceeded and whether the same stage keeps causing problems.

Maybe one late Intermediate Report was an exception. If Intermediate Reports repeatedly get close to the 72-hour limit, that tells you something about the process before the next major incident happens.

This is not the complete DORA audit trail. Jira history, actual regulatory submissions, and the evidence required by your compliance process still matter.

But SLA Time and Report gives you a consistent record of one very specific thing: whether the operational deadlines you defined were met.

---

Final thoughts

On paper, DORA reporting looks like four simple numbers: 4 hours. 24 hours. 72 hours. One month.

In practice, the tricky part is tying each clock to the right real-world event. A standard Time-limit SLA works great for fixed countdowns after a clear Jira trigger. However, when you're dealing with dynamic dates or past timestamps, storing the target date directly in Jira and tracking it with a Negotiated Date SLA is a much safer bet.

And remember to keep team working hours separate from regulatory timers: statutory deadlines run on strict compliance rules, while flexible calendars should be reserved for tracking internal team effort across regions.

That is where I see the practical value of SLA Time and Report for Jira in a DORA process: not interpreting the regulation for you, but turning an already-defined reporting rule into something the team can see, act on, and review later.

Instead, it can become one part of a broader compliance tracking software workflow in Jira: once the reporting rules and deadlines are defined, the app makes them visible, helps teams react before they are missed, and keeps a measurable record of the result.