FortiSOAR case management is where alert records, incident ownership, tasks, evidence, collaboration, and automation become an operational workflow. The platform can receive large numbers of alerts, but a SOC still needs a consistent method for deciding which alerts become incidents, who owns the investigation, what evidence must be preserved, which tasks are required, and what constitutes a defensible closure.<\/p>\n
Within Fortinet Security Operations<\/a>, effective case management is not just a matter of adding fields to an incident form. It defines the handoffs between analysts and automation. A strong data model makes the current state obvious, ties actions to evidence, and keeps response work understandable even when several people, playbooks, and external systems contribute to the same case.<\/p>\n Current FortiSOAR documentation distinguishes Alerts from Incidents. Alerts commonly represent suspicious activity received from detection systems, while incidents represent security events that have been escalated into an investigation or confirmed breach context. Treating every alert as an incident removes that distinction and forces expensive incident-management behavior onto low-confidence signals.<\/p>\n Define explicit escalation criteria. An alert may become an incident because evidence reaches a confidence threshold, business impact is high, multiple related alerts converge, or an analyst determines that coordinated response is required. That decision should be visible in the record. The triage process<\/a> should feed case management rather than disappear inside it.<\/p>\n FortiSOAR can escalate an alert to an incident through workflow automation, carrying information such as incident name, severity, assignee, and the reason for escalation. The new incident can remain linked to the originating alert. That linkage is important because escalation should change the management state without severing the evidence trail that justified the decision.<\/p>\n Design the escalation mapping deliberately. Preserve source alerts, indicators, entities, timestamps, analyst notes, and enrichment that will matter later. An incident investigator should not need to reopen several alerts to discover the evidence that caused escalation. The record should explain both the security event and the decision path that turned it into a case.<\/p>\n FortiSOAR roles can provide SOC analysts with access to Alerts, Incidents, Comments, Attachments, Indicators, Tasks, War Rooms, schedules, and reporting according to assigned permissions. That access model should be paired with queue design: which team receives a new incident, how priority affects assignment, how ownership changes across shifts, and when specialists or managers become involved.<\/p>\n A case without a clear owner tends to accumulate actions without accountability. The bottleneck concepts in incident leadership<\/a> apply even to routine SOC work. At any time, the team should know who is responsible for the next decision, which tasks are blocked, and what evidence is needed to move the incident forward.<\/p>\n Tasks can represent analyst actions or automated steps and can link to external systems such as ticketing platforms. Use them to make investigation and response requirements explicit: validate identity activity, collect endpoint evidence, contact an application owner, isolate a system, verify containment, or obtain approval. Avoid creating tasks for every trivial click; the task list should represent meaningful work and dependencies.<\/p>\n Task status is also useful for handoffs. A new analyst should see what has been completed, what failed, what is waiting on another team, and which action would be dangerous to repeat. This is one reason the endpoint investigation workflow<\/a> benefits from structured case management rather than relying on free-form notes alone.<\/p>\n Attachments, indicators, comments, and War Rooms support different forms of investigative evidence and collaboration. The case should preserve enough material to explain findings without becoming a dumping ground for every raw artifact. Important screenshots, queries, exported records, indicator context, and analyst conclusions should be tied to the stage of the investigation where they mattered.<\/p>\n War Rooms are useful for active coordination, especially in high-severity events, but the durable incident record still needs the decisions and evidence required for later review. The principles in digital forensics<\/a> are relevant: collection is valuable only when provenance, timing, and relationship to the incident are preserved.<\/p>\n FortiSOAR provides SLA management capabilities through solution-pack functionality that can track acknowledgement and response expectations for alerts and incidents. Those timers can improve discipline when they represent real service commitments. They become harmful when the organization optimizes for stopping the clock rather than making the right security decision.<\/p>\n Define what acknowledgement, response, containment, and resolution mean for each case class. Pausing an SLA should require a valid operational reason, such as waiting on an external owner or approved maintenance window. Review breached cases to identify process bottlenecks, not to punish analysts for incidents whose complexity genuinely required more time.<\/p>\n FortiSOAR playbooks can enrich alerts, create or update records, assign tasks, notify stakeholders, and invoke response actions. Automate deterministic transitions first: data gathering, field normalization, duplicate checks, routine notifications, or creation of standard tasks. Preserve human approval where consequences depend on business context or evidence is incomplete.<\/p>\n The same boundary described in SOAR playbook design<\/a> applies to case management. Automation should make the case more complete and easier to act on. If a playbook closes incidents automatically, the closure logic must be as defensible as a human analyst\u2019s decision and leave enough evidence to explain why closure was appropriate.<\/p>\n An incident should not be closed simply because alert volume stopped. Closure criteria may require confirmed containment, eradication or mitigation, restored service, completed notifications, evidence retention, and a documented assessment of residual risk. Some cases also need follow-up work that belongs in a problem-management, vulnerability, or engineering backlog rather than remaining indefinitely in the incident queue.<\/p>\nAlerts and incidents should represent different operational states<\/h3>\n
Escalation should carry evidence forward, not restart the investigation<\/h3>\n
Ownership needs queues, roles, and a clear transfer model<\/h3>\n
Tasks should translate the response plan into visible work<\/h3>\n
Evidence and collaboration belong in the case record<\/h3>\n
SLA management should measure response obligations, not encourage premature closure<\/h3>\n
Automation should advance the case without erasing analyst judgment<\/h3>\n
Closure criteria should prove that the incident reached a stable state<\/h3>\n