FortiSOAR is often described in terms of automation, but a SOC also needs a disciplined way to assign human work and coordinate complex incidents. Queues, shifts, and war rooms address that operational layer. Queues organize records that require attention, shifts define who is available for assignment at a given time, and war rooms create a focused collaboration space for high-impact incidents that need coordinated technical and business response.

The current NSE 7 Security Operations 7.6 Architect objectives explicitly include queues, shifts, war rooms, and FortiSOAR incident handling. The important skill is understanding how these features change ownership, workload distribution, escalation, and collaboration—not memorizing where a button appears in the interface.

Separate the incident lifecycle from the analyst workload

An incident record describes a security situation. A queue describes work that needs an owner. Those are related but not identical concepts. One incident can generate multiple tasks, enrichment actions, approval steps, and communication activities. If every operational decision is forced into the incident status alone, managers lose visibility into who is doing what and analysts lose a clear work list.

Queues provide a structured workload view. FortiSOAR can use defined criteria to place records into a queue and assign them to available users. That gives managers a way to see pending work, current assignments, and areas that may require reallocation. Analysts get the inverse view: what belongs to them now, what is waiting, and what priority should be handled next.

This becomes especially important in larger SOCs where incident ownership spans tiers, specialties, regions, or customers. Queue design should reflect operational responsibility rather than copying the organizational chart mechanically.

Design queues around meaningful ownership boundaries

A useful queue answers a clear question such as “which phishing investigations are waiting for Tier 1?”, “which cloud-security incidents require the platform team?”, or “which high-severity cases belong to the overnight shift?” If a queue mixes unrelated work, the assignment logic becomes hard to understand and service-level performance becomes difficult to measure.

Choose queue criteria that match how the SOC actually routes work: incident type, severity, customer or tenant, technology, geography, team, or another durable attribute. Avoid excessive fragmentation. Twenty tiny queues can produce more routing complexity than operational value, particularly when analysts are qualified to handle several types of work.

Ownership and permissions must match the queue. FortiSOAR permissions determine who can create, view, update, and act on records, so a queue should never become a way to expose records to analysts who should not access them. Test both assignment behavior and visibility.

Shifts make automated assignment time-aware

A queue can contain work at any time, but the people who should receive that work change through the day. Shifts define the users available during specific times and days. FortiSOAR then uses those shift memberships when assigning queued records to individual users.

This matters for follow-the-sun operations and for SOCs that distinguish business-hours response from after-hours escalation. A queue may remain constant while its active analyst population changes. If the shift model is wrong, incidents can be routed to users who are not working, forcing manual reassignment and increasing response time.

Leave management extends the same idea. Planned absence should remove a user from automated assignment for the relevant period without requiring managers to redesign the queue. The operational goal is continuity: the system should reflect real staffing rather than assume every configured user is always available.

Choose assignment rules that balance speed and fairness

Automated assignment is useful only when analysts trust it. Consider whether work should be distributed evenly, routed by specialty, weighted by existing workload, or escalated based on severity. The exact model depends on the SOC, but the result should be predictable enough that managers can explain why a record went to a particular analyst.

Track queue backlog, assignment age, reassignment frequency, and stale records. A growing backlog may indicate insufficient staffing, overly broad queue criteria, a noisy detection source, or downstream dependencies that prevent closure. Queue metrics are therefore not just productivity measures; they can expose design flaws elsewhere in the SOC pipeline.

Do not use automation to hide overload. If analysts receive more incidents than they can meaningfully investigate, faster assignment only moves the bottleneck. Detection tuning, enrichment, severity discipline, and staffing all influence the value of the queue model.

War rooms are for coordinated response, not routine case notes

A war room is appropriate when an incident requires active collaboration among multiple stakeholders. FortiSOAR war rooms provide a dedicated space where teams can coordinate the response, allocate work, capture analysis, track milestones, communicate with stakeholders, and run playbook or connector actions related to the incident.

Not every alert needs a war room. Creating one for routine cases dilutes the signal and burdens teams with unnecessary coordination overhead. Reserve war rooms for situations where the incident’s complexity, impact, duration, or cross-team nature makes ordinary case handling insufficient.

Typical examples include ransomware affecting multiple business units, a material data-exfiltration investigation, a major identity compromise, or an incident that requires security, infrastructure, legal, communications, and executive coordination. The value comes from bringing those streams together without losing accountability.

Define roles before the room goes live

A collaboration space does not automatically create good incident command. Decide who owns the incident, who leads technical investigation, who handles containment, who communicates externally, and who has authority to approve disruptive actions. FortiSOAR can organize information, but humans still need a clear decision model.

When the room is activated, capture the incident objective and current facts at the top. Separate confirmed evidence from hypotheses. Assign tasks with owners and due times. Record major decisions and the evidence behind them. This reduces repeated discussion and helps incoming analysts understand the current state quickly.

External collaboration should be governed carefully. If outside stakeholders or third parties receive access, verify what information the collaboration method exposes and whether sensitive evidence should remain in the internal incident record.

Connect automation to human checkpoints

FortiSOAR can launch playbooks and connector actions from the incident-response workflow, but high-impact automation should respect human decision points. Enrichment and evidence collection are often safe to automate aggressively. Disabling accounts, isolating endpoints, blocking production traffic, or modifying infrastructure may require approval depending on business risk.

A mature workflow uses automation to reduce repetitive analyst work while preserving explicit control where the consequence of a false positive is high. For example, a playbook can collect identity, asset, reputation, and network context automatically, then present a concise decision package to the incident owner before containment.

This balance is central to broader automation and orchestration thinking: automation performs actions, while orchestration coordinates actions, dependencies, systems, and human decisions into an end-to-end process.

Use the workspace to preserve investigation continuity

Incidents often outlive individual shifts. A good FortiSOAR workspace should let the next analyst understand the timeline, unresolved questions, evidence gathered, actions already taken, and next decision without reconstructing the case from chat messages. Queues and shifts support the ownership handoff; the incident and war room preserve the investigative memory.

At shift change, record what is known, what remains uncertain, which actions are pending, and whether any risk has changed. Do not simply reassign the record. A handoff that moves ownership without transferring reasoning creates duplicated work and can lead to contradictory response actions.

On-call incident response depends on the same handoff discipline: availability, escalation paths, and ownership boundaries must be defined before an emergency begins.

Measure the workflow, not just closure counts

Closing many incidents is not automatically evidence of an effective SOC. Review time to assignment, time to first meaningful action, number of reassignments, escalation delays, queue aging, and the percentage of cases that require manual routing corrections. For war rooms, examine whether decision authority was clear, whether tasks had owners, and whether handoffs preserved context.

After a major incident, use a structured incident post-mortem to improve the operating model. The lesson may be a detection change, but it may also be a queue criterion, shift schedule, permission, approval step, or war-room practice.

Fortinet certification SOC objectives treat operations as both technology and process. Queues, shifts, and war rooms make ownership and collaboration explicit so automation and human judgment can work together instead of competing for control.

Queues work well for ordinary workload, but critical incidents need explicit escalation rules. Define what happens when a high-severity case sits unassigned, when an analyst does not acknowledge it within the expected time, or when the required specialist is not on shift. The escalation can notify a lead, move the record to a different queue, engage an on-call role, or create a war room depending on the impact.

Build these rules from operational risk rather than arbitrary timers. A suspected ransomware outbreak may justify immediate multi-team escalation, while a low-confidence phishing report can remain in the normal queue longer. If every case is treated as urgent, the escalation channel becomes another noisy queue.

Consider regional and customer boundaries as well. A managed-security provider may have separate escalation contacts and service targets for each tenant. An internal enterprise may have different procedures for production, corporate IT, and regulated environments. The record should carry enough ownership metadata that automation can route correctly without an analyst memorizing every exception.

Test escalation during controlled exercises. Verify that notifications reach the intended people, off-shift users are skipped, ownership changes are visible, and the next analyst receives the current investigation state. An escalation that exists only in a process document but has never been exercised is an operational assumption.