Screen reference
Incidents
Security incidents, linked to the assets affected and the risks they call into question.
What the screen is for
- With Jira Service Management: an incident is an existing ticket, which the app links to assets and risks. The title (if empty) and the dates are taken from the ticket; the app never modifies the ticket.
- Without JSM: the app keeps a light register, each incident is entered here.
Who can do what
| Action | Reader | Compliance manager | Jira administrator |
|---|---|---|---|
| Read incidents | yes | yes | yes |
| Record, edit, change status, note sent notifications | no | yes | yes |
Step by step
- Read the summary: Open incidents, Contained, Resolved, Closed, and "To handle" (risks to reassess, deadlines to watch, lessons to write). Show All, Open, To handle, or Resolved or closed.
- "Record an incident": title, severity (Low to Critical), detection date and time in UTC, owner, assets affected, linked risks. With JSM, enter the ticket key (for example ITSM-12).
- In the drawer, change the status (Mark contained, Mark resolved, Close, Reopen). A closed incident is no longer edited.
- For a serious incident, reassess the linked risks in the risk register, then click "I reassessed these risks". The app does not change the risks.
- Write the lessons learned (what happened, what changes). A serious incident cannot be closed without them.
Notification deadlines
When you choose DORA or NIS2, the app prepares deadlines (initial notification, intermediate and final report; early warning, notification, final report) from the detection date. You note each sending by hand.
These dates are prepared from the texts and must be confirmed with your counsel. The app sends nothing to authorities and does not say a notification is required in your case.
Known limits
- JSM dates are read as Jira gives them; the key of a linked ticket does not change.
- The JSM link adds no scope: it reads the ticket you can already see in Jira.
Was this page helpful?