Incidents

An incident is a security or operational event that has actually happened and is being handled — as opposed to a risk scenario (a potential event) or a vulnerability (a weakness that could be exploited). CyberGuard treats incidents as first-class objects so detection, response, evidence and the controls that should prevent recurrence all live in one place.

Where to find it

Operations → Incidents in the sidebar. The register lists each incident with its Reference ID, Name, Status, Severity, Detection and domain; use the search bar and Filters to slice it by any of these.

Key concepts

What an incident captures

Classification — a name, an optional reference ID, and a Severity: critical, major, moderate, minor, low or unknown. Severity drives triage — critical work first.
Timing — when it occurred, when it was reported, when it was resolved.
Detection — internal or external, optionally with a link to the source signal.
Scope — the affected assets, the threats believed to be in play, the third-party entities involved.
Assignees — who is handling the response.
Response — qualifying terminology, whether the business continuity plan was activated, and resolution notes.
Linked controls and tasks — the applied controls invoked during response, plus the task definitions that should run as follow-up, such as a post-mortem or a control review.

Status lifecycle

Incidents follow a five-state lifecycle: New → Ongoing → Resolved → Closed, with Dismissed available at any point if the event turns out not to be a real incident.

Timeline entries

Every incident carries a timeline — an append-only log of significant moments: detection, mitigation steps, free-form observations, severity changes, status changes. State transitions are recorded there automatically, and you add entries as the response unfolds. The timeline is what an auditor or a post-mortem author reads to reconstruct exactly what happened and when.

Working with incidents

Register the event as soon as it’s confirmed: name, severity, detection source, affected assets.
Assign responders and move the status to Ongoing as work starts.
Log timeline entries as things happen — a sparse timeline written after the fact is worth far less than one written live.
Link the applied controls used in the response, and attach follow-up task definitions before closing.
Move to Resolved when the event is contained, then Closed once follow-up is done.

Tasks — the follow-up work spawned from an incident.
Applied controls — the measures invoked during response.
Calendar — follow-up deadlines by month.