devguard

Incidents

Record security, privacy and quality incidents from detection to closure. Track severity, build a timeline, link the assets, risks and vendors involved, and keep track of who you have to notify, and by when.

Overview

The Incidents module is your incident register: a structured record of security and data incidents, from the moment one is detected through investigation, containment, resolution and closure. Each incident captures what happened, how severe it was, who owns the response, and everything it touched: the assets, risks, vendors, controls and treatment actions involved.

Incidents also track reporting duties. On the Reporting tab you apply a regime such as GDPR, nFADP, NIS2 or DORA, and devguard lists each report the law names, with its recipient, legal source and due date.

Lifecycle

An incident moves through five statuses. You set the status as the response progresses; the timestamps below are captured to give you an accurate record.

StatusMeaning
OpenLogged, response not yet started
InvestigatingBeing actively investigated
ContainedThe immediate threat is contained
ResolvedFully resolved; resolvedAt is recorded
ClosedReviewed and closed; closedAt is recorded

When you move an incident to Closed while its root cause or lessons learned are still empty, devguard asks for them first. You can fill them in right there or close without them; closing is never blocked, but an empty review weakens the audit trail.

Incident fields

FieldDescriptionExample
NameThe name of the incident (required)Phishing compromise of finance mailbox
OwnerBusiness role responsible for the response (required)Security Team
SeverityHow serious the incident isLow, Medium, High, Critical
StatusWhere the incident is in its lifecycleInvestigating
Threat classThe category of threat, if knownUnauthorized access
DescriptionWhat happenedA finance user entered credentials on a spoofed login page…
Occurred atWhen the incident actually happened2026-02-03 14:20
Detected atWhen you became aware of it (defaults to now)2026-02-04 09:10
Root causeThe underlying cause, filled in during investigation (rich text)Missing MFA on the mailbox
Lessons learnedWhat you would do differently, captured at closure (rich text)Enforce MFA on all mailboxes
LabelsFree-form tags to group and filter incidentsPII, Q1-initiative

Root cause and Lessons learned use the same editor as a finding's root cause and corrective action: bold, italic, underline and lists. Click either field on the incident to edit it in place; clicking outside saves it, and Escape discards the change.

Severity

Severity ranges from Low to Critical and reflects the impact of the incident on your organization. Use it to prioritize the response and to filter the incident list to what matters most.

Timeline

The Timeline tab is the running log of what happened and when. Add an entry for each meaningful step, such as detection, actions taken, findings and decisions, each with its own time and note. Together the entries form the chronological narrative you can hand to an auditor or regulator.

Reporting

The Reporting tab on the incident lists who you may have to notify, and by when. The number on the tab counts the stages still open.

Applying a regime

Click Apply regime and pick one. Regimes already on the incident are shown grayed out and marked Applied, so only the remaining ones can be selected; Contractual can be applied more than once.

RegimeWhen to use it
GDPRPersonal data breaches under EU law
nFADPBreaches of data security under the Swiss FADP
NIS2Significant incidents; your national transposition law sets the operative deadlines
DORAMajor ICT-related incidents at financial entities; ICT providers use Contractual
EU AI ActSerious incidents with high-risk AI systems; applies from 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I)
HIPAABreaches of unsecured protected health information
Swiss ISGCyberattacks on critical infrastructure; only for operators under ISG Art. 74b
ContractualA notice duty from a contract (DPA, BAA, DORA clause) with your own hours

The dialog asks for the moment the clock starts: awareness for most regimes, classification as major for DORA, discovery for HIPAA and the ISG. It then asks the regime's criteria as yes/no answers, each with an optional note. These answers are how you record significance: whether a NIS2 incident is significant, whether a DORA incident is major, whether an AI incident is serious. Criteria you leave unanswered are saved as open. HIPAA also asks how many individuals are affected, and whether more than 500 residents of one state or jurisdiction are among them, because that decides the media and Secretary notices. Contractual asks for the stage label, the recipient, the contract and clause, and the hours you have.

When every deciding criterion is answered No, the regime is recorded as not reportable: the dialog asks why no notification is required and stores your reason on the stages. Edit answers in the regime's menu changes the clock and the answers later; the due dates of open stages follow.

The full legal notice sits at the top of the dialog. The tab carries a short version of it.

Stages

Each regime adds one row per stage. A row shows the recipient, the legal source, its status and the due date with its anchor in words, for example "72h after you became aware". Where the law says "without undue delay" or "immediately", the date is an internal target you can change, not a legal deadline, and the row says so. A stage that follows another (a NIS2 final report, a DORA final report) has no due date until the earlier one is submitted.

Some regimes have stages that apply only in certain cases, such as the processor's notice to the controller or a NIS2 intermediate report. Add those with Add stage.

On each stage:

  • Mark submitted records the date and a reference or case number. After the due date it also asks why it was late.
  • Not required records why no notification is required. HIPAA asks for the four factors of the risk assessment instead. A stage the law always requires, such as the processor's notice, has no Not required.
  • Edit due changes the date with a reason, for example a law-enforcement delay under HIPAA.
  • Reopen clears the decision. The earlier decision stays in the Timeline.
  • Remove stage deletes an open or reopened stage. A decided stage has to be reopened first.

Remove regime in the regime's menu deletes the regime with all its stages, once none of them is decided; reopen decided stages first. Every removal is written to the Timeline and to the audit log, and a reopened stage's earlier decision stays in the Timeline. Only people who may edit the incident see these actions.

Personal data breaches

Turning on Personal data breach applies the privacy regime for you: GDPR, nFADP when your organization adopted only nFADP, or both. Turning it off removes privacy stages nobody has decided yet.

Where stages show up

Open stages appear in Deadlines, titled with the incident number, the regime and the stage only, and the dashboard's incidents card shows when the next report is due. Stages and decisions are never sent to the employee portal and cannot be set by the assistant. Notification notes from the incident's edit form appear at the foot of the tab.

The stages are reference timelines taken from the legal texts named on each stage, not legal advice. Due dates are calculated from the times you enter and do not account for weekends, public holidays or time zones. Your organization decides whether and when to report; have that decision checked by qualified legal counsel.

Findings

An incident can start a finding: a nonconformity to correct, an observation, or an opportunity for improvement. Raise finding in the Findings section opens the finding form with the incident as its source. The name and the root cause are prefilled, and nothing is saved until you save. A personal data breach prefills only the incident number and the link, so no breach content reaches the finding.

The Findings section lists every finding raised from the incident with its status. Deleting the incident keeps its findings. Findings are worked and closed in Audits → Findings.

An incident rarely stands alone. Link the things it involved so the impact is traceable:

  • Assets affected by the incident
  • Risks the incident realised or relates to
  • Vendors involved, when a third party is a factor
  • Controls that failed or are relevant
  • Treatment actions, the remediation work tracked to closure

These links are visible from the incident and from the related entity, so you can see an asset's or vendor's incident history in one place.

Evidence

Attach proof to an incident from its Evidence tab: forensic reports, notification records, screenshots, or any artifact that documents the incident and your response. This keeps the supporting material with the record for audits and regulatory inquiries.

Tasks

Each incident's detail view has a Tasks tab for the follow-up work it generates: the containment step someone still owes, the post-incident review, the fix that has to land before you can close it. Use Add task and it is attached to the incident automatically. These tasks appear in the central Tasks worklist and, with a deadline, on the Roadmap.

History

Every change to an incident is recorded in the History tab and the organization-wide audit log, giving you a complete, attributable trail of who changed what and when.

Comments

Every incident's detail view has a Comments tab for discussing it in place, so the reasoning behind a decision stays attached to the record instead of living in a chat thread nobody can find later. Comments complement the Timeline: the timeline records what happened and when, while the comments capture the discussion around it.

Write a comment with light formatting (bold, italic, underline, lists), reply to any comment (replies cannot be nested further), and edit or delete your own. Deleting a comment that has replies leaves a placeholder so the conversation still reads in order.

Type @ to mention a colleague. They are notified in the app, and by email once they turn email on under Account → Notifications, where they also choose how often they hear about comments.

How is this guide?

On this page