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.
| Status | Meaning |
|---|---|
Open | Logged, response not yet started |
Investigating | Being actively investigated |
Contained | The immediate threat is contained |
Resolved | Fully resolved; resolvedAt is recorded |
Closed | Reviewed 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
| Field | Description | Example |
|---|---|---|
Name | The name of the incident (required) | Phishing compromise of finance mailbox |
Owner | Business role responsible for the response (required) | Security Team |
Severity | How serious the incident is | Low, Medium, High, Critical |
Status | Where the incident is in its lifecycle | Investigating |
Threat class | The category of threat, if known | Unauthorized access |
Description | What happened | A finance user entered credentials on a spoofed login page… |
Occurred at | When the incident actually happened | 2026-02-03 14:20 |
Detected at | When you became aware of it (defaults to now) | 2026-02-04 09:10 |
Root cause | The underlying cause, filled in during investigation (rich text) | Missing MFA on the mailbox |
Lessons learned | What you would do differently, captured at closure (rich text) | Enforce MFA on all mailboxes |
Labels | Free-form tags to group and filter incidents | PII, 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.
| Regime | When to use it |
|---|---|
GDPR | Personal data breaches under EU law |
nFADP | Breaches of data security under the Swiss FADP |
NIS2 | Significant incidents; your national transposition law sets the operative deadlines |
DORA | Major ICT-related incidents at financial entities; ICT providers use Contractual |
EU AI Act | Serious incidents with high-risk AI systems; applies from 2 Dec 2027 (Annex III) / 2 Aug 2028 (Annex I) |
HIPAA | Breaches of unsecured protected health information |
Swiss ISG | Cyberattacks on critical infrastructure; only for operators under ISG Art. 74b |
Contractual | A 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.
Related data
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?
Security Questionnaires
Answer the security questionnaires your customers send you. Upload, review and export them, while every approved answer grows a reusable answer library so the next questionnaire is faster.
Tasks
Tasks are the concrete units of work that move your compliance program forward. Track what needs to be done, who owns it, and when it is due across every framework, control, and record.