Incident handling

Support every stage of an incident, from the first signal to the risk review it should trigger.

Typical requirementsNIS2 Art. 23DORAGDPR Art. 33

Stage 1 of 5
Detection
Monitoring alerts, supplier notices and threat news arrive as signals. Signals already tied to risks and assets are recognised sooner.
Signals Incidents Risks Suppliers
Links used
1. Signals escalates to Incidents
2. Signals indicates Risks
3. Signals concerns Suppliers
WINGMAN and AI support
Groups related signals and proposes whether to open an incident.
Decides: The incident manager decides.
Stage 2 of 5
Triage
Affected services, everything that depends on them, and the risks involved set the severity and the reporting duties.
Incidents Assets Risks Roles
Links used
1. Incidents affects Assets
2. Assets depends on Assets
3. Incidents realises Risks
4. Roles leads Incidents
WINGMAN and AI support
Proposes severity and whether NIS2, DORA or GDPR thresholds are met, with the deadlines that follow.
Decides: The incident manager classifies.
Stage 3 of 5
Resolution
Responders get their next steps as tasks, and the controls that failed or held are known.
Incidents Tasks People Controls
Links used
1. Incidents followed up by Tasks
2. People assigned Tasks
3. Controls improved by Tasks
WINGMAN and AI support
Guides technicians step by step from runbooks linked to the affected assets.
Decides: Responders act; the incident manager closes.
Stage 4 of 5
Communication
Notices to the authority, customers, users and suppliers are drafted, sent and kept with the incident.
Incidents Documents Suppliers Roles
Links used
1. Incidents reported in Documents
2. Incidents involves Suppliers
3. Roles leads Incidents
WINGMAN and AI support
Drafts the authority report and the customer notice in time for the deadline.
Decides: The incident manager approves and sends.
Stage 5 of 5
Post-mortem and risk review
Root cause analysis links the incident to the risks it realised. A risk review is triggered as part of the post-mortem.
Incidents Risks Plans Controls Tasks
Links used
1. Incidents realises Risks
2. Plans reviews Risks
3. Controls reduces Risks
4. Controls improved by Tasks
WINGMAN and AI support
Guides the post-mortem and proposes rating changes and new controls.
Decides: The risk owner approves the changes.

Screens for this stage · Stage 1: Detection

Ask Wingman **Describe what happened; WINGMAN registers the incident** A support colleague describes three customer reports of invoice emails with a changed bank account. The orchestrator recognises a suspected incident, offers Register incident or Report a signal, runs the four-step skill, and submits the drafted record as a suggestion. Accept writes it.

Ask Wingman · step 1 **The drafted incident as a suggestion** The skill collected the details, drafted the record with title, affected parties, source of the problem and ten mitigation recommendations, and shows it with Accept and Reject.

Ask Wingman · step 2 **Accepted — written to the record** One click turns the suggestion into INCIDENT-29043.

Signals **The signals inbox** Human-reported observations arrive as cards. WINGMAN classifies each one with a confidence score and proposes a risk or an incident; the owner accepts or rejects.

Email notification **The email the owner receives** A signal routed to you: the record id and title, and what to do: open it beside the AI classification, then accept a suggestion or mark it a false positive.

Screens for this stage · Stage 2: Triage

Ask Wingman **Triage with the incident handler** The assigned handler asks for severity, reporting obligations and next-hour decisions. The Incident Management skill runs eleven steps and ends with suggestions: link the two candidate source systems, create the missing threat, and six remediation tasks. The handler accepts or rejects each.

Ask Wingman · step 1 **Eleven steps, severity Critical** Company context, intake, severity classification, evidence and duplicates, response plan, suggestions, findings, next-hour decisions, draft notifications, interim post-mortem, brief update. Then what is required: no regulatory obligation recorded yet, GDPR 72 h clock only if Legal confirms a breach, customer notice required now.

Incidents · step 3 **The incident WINGMAN registered from the conversation** Title, description, ten mitigation recommendations and a fresh brief, written from what the reporter said in chat. Post-mortem fields wait for later.

Graph **The graph of one record** Every record has a Graph tab: the risk in the centre, its review tasks, the incident that realised it and the control that reduces it. Depth 1 to 3, or open the full graph.

Screens for this stage · Stage 3: Resolution

Ask Wingman · step 4 **Remediation tasks accepted** Out-of-band verification for payment-detail changes, SPF/DKIM/DMARC reject policy, phishing-resistant MFA and more become tasks linked to the incident and its assets. One duplicate with a wrong id is rejected.

Tasks **My tasks** Tasks filtered to one person, with recurring markers, priority chips, status and due dates. Quick views for this week, this month and overdue.

Screens for this stage · Stage 4: Communication

Ask Wingman **Draft the notification to the authority** Asked in plain words on the incident, WINGMAN fills the GDPR Article 33 notification from the record: nature of the breach, data subjects, data categories, DPO contact, likely consequences, measures taken, communication to data subjects, other notifications. Every field is marked KNOWN, UNKNOWN or ASSUMED.

Ask Wingman · step 1 **Article 33(3)(a): nature of the breach** Summary, breach type, cause or vector with the three possibilities from the record, linked threat and systems, each marked KNOWN or UNKNOWN.

Ask Wingman · step 2 **Draft customer security notice** Owner, timing, channels, subject and body, with the facts that must be confirmed before sending: wording on the source, whether to publish bank details, payments already made, personal data.

Screens for this stage · Stage 5: Post-mortem and risk review

Ask Wingman · step 3 **Suggestions: link assets, create the threat** Update suggestions add InvoiceNinja and Gmail as candidate sources; a create suggestion adds the threat Phishing, business email compromise and domain impersonation and links the incident as its instance.

Risks **A risk with an open review and a suggestion** On the risk itself: what changed since the last review (a linked incident, a training task, a parent risk), one suggested change (likelihood 4 → 2 with the reason), and Confirm & complete.

Risks · step 3 **Review completed: score 16 → 8, Monitored** The score drops from 16 to 8, severity from Critical to High, status moves to Monitored, the position on the matrix shifts, and the brief regenerates.

Sector angles

What this use case looks like under specific regulations.

NIS2

Classification against the regulation's significance criteria, then the early warning in 24 hours, the notification in 72 hours, progress reports and the final report to CERT.LV, drafted from the incident record.

Financial sector

Loss events and major ICT-related incidents are recorded once, with classification, reporting and lessons learned that update risks.

CRA

Actively exploited vulnerabilities and severe incidents follow the reporting deadlines, with notices kept on the record.

GDPR

Personal data breaches follow the 72-hour notification decision, with the assessment kept even when nothing is notified.

Videos

**WINGMAN AI GRC – risk management use case** Regular risk reviews and new risk identification, plus incidents, signals and vulnerability changes between reviews.

**WINGMAN AI GRC – financial sector (DORA, MiCA, ECB)** Live signals on critical functions, ICT and supply-chain risk, major incidents decided by people, and supervisor reports drafted for submission.

Plays from youtube-nocookie.com. YouTube sets no cookies until you press play.

Incident handling

Sector angles

Videos

Other use cases

Supplier evaluation

Change management

Regular reviews

Security operations control

See WINGMAN on your own data