FortiAnalyzer gives analysts several ways to look at security data. Log View exposes records directly. FortiView summarizes activity through dashboards and widgets. The SOC Dashboard in FortiAnalyzer 7.6 emphasizes incidents, events, alerts, connectors, and affected entities. Reports provide scheduled analytical output. Choosing the right view helps an analyst move from signal to evidence without getting trapped in a single screen.
The NSE 5 FortiAnalyzer 7.6 Analyst includes FortiView dashboards and widgets as well as incident analysis, events, playbooks, and reports. The practical objective is to use dashboards as investigation starting points rather than passive wall displays.
FortiView summarizes activity for rapid pivots
FortiView includes predefined dashboards for threats, traffic, applications, endpoints, indicators of compromise, and other operational views depending on the managed devices and available data. Many dashboards combine a ranked table with a historical view so an analyst can see both current prominence and how activity changed over the selected period.
The value is speed. Instead of writing a query to discover the top threat destination, the analyst can begin with a FortiView widget and then drill into the relevant entity or time period. That drill-down should lead toward the underlying logs when the case requires evidence.
FortiView is therefore best treated as a pivot layer. It summarizes; it does not replace detailed log validation.
The SOC Dashboard centers incidents and alerts
FortiAnalyzer 7.6 introduced a SOC Dashboard that provides an overview of incidents, events, and alerts. Its statistics can include high-severity incidents, outbreak alerts, compromised hosts, affected users, active connectors, and device types.
Additional widgets can show event relationships, incident categories, top incidents, event and incident severity, and connector health. Many widgets are interactive: clicking a statistic or incident can open the corresponding filtered investigation pane.
This makes the dashboard useful for triage. An analyst can start with “what needs attention now?” and move directly into the incident or evidence rather than manually rebuilding the same filters in several screens.
Time range and filters define the story you see
Dashboards can be misleading when analysts forget the selected time window, device scope, or filter. A sharp increase over five minutes may disappear when viewed across a day; an apparently quiet environment may simply be filtered to one device group.
Before escalating an anomaly, confirm the scope displayed by the widget. When comparing two screenshots or shifts, make sure the time range and device filters are equivalent. Otherwise the comparison may describe the interface state rather than a real change in security activity.
Time synchronization in source logs also matters. A dashboard cannot place events accurately on a timeline if devices report incorrect timestamps.
Custom views make repeated investigations faster
FortiAnalyzer allows custom FortiView views that preserve selected widgets, filters, device selection, and time period. This is useful for recurring operational questions such as internet-edge threats, high-risk applications, data-loss events, or a specific customer environment.
Custom views should be designed around roles. A malware analyst, network-security analyst, and SOC manager may need different default widgets even though they use the same underlying logs. One universal dashboard tends to become crowded and less useful to everyone.
Document the purpose of custom views and review them periodically. A widget that was valuable for an old incident may become permanent clutter long after the detection or infrastructure changed.
Monitors support the wallboard use case
FortiView monitors are designed for network and security operations centers that display multiple dashboards on larger screens. Fortinet describes using several panes to show important security, network, endpoint, and system information simultaneously.
A wallboard is useful for shared awareness, but it should not become the primary investigation interface. Large displays favor aggregated information and visual alerts; analysts still need detailed incident and log views on their workstations.
Choose wallboard widgets that support action. If a statistic changes but nobody knows what threshold matters or who responds, the display adds visual motion rather than operational value.
Move from dashboard signal to incident evidence
A disciplined workflow is signal, scope, context, evidence, and action. Start with the dashboard signal. Scope the affected user, host, device, or time window. Open the incident or event to collect context. Pivot to raw logs and related indicators. Then decide whether containment or escalation is warranted.
This sequence aligns with a mature incident response process. Dashboards reduce time to discovery, but the response decision should be supported by evidence rather than by the visual severity color alone.
Capture the pivots that were useful during important investigations. They can inform new custom views, event handlers, or playbooks so the next analyst reaches the same evidence faster.
Understand the boundary between FortiView, Log View, and reports
FortiView is optimized for interactive summary and drill-down. Log View is the place for detailed record inspection and custom log views. Reports are designed for repeatable, formatted analysis over a defined dataset. The SOC Dashboard focuses attention on incidents, alerts, and operational status.
Using the right tool reduces frustration. If an analyst needs the exact raw event that triggered a case, a high-level widget is not enough. If a manager needs a monthly trend, repeatedly opening FortiView and taking screenshots is less reliable than a validated report.
The common data foundation links these features. A missing parser, incomplete source logging, or incorrect retention policy can affect all of them in different ways.
Empty widgets should be troubleshot from the data source backward
When a widget shows no data, confirm the time range and device selection first. Then check whether relevant logs exist. If the widget depends on normalized fields, verify that parsing and normalization succeeded. If the widget represents incidents or events, confirm those upstream objects were generated.
For SOC Dashboard connector widgets, connector health is itself part of the signal. A response integration that is offline can change what the SOC can safely automate even if event detection remains healthy.
The SIEM data pipeline mindset prevents dashboard troubleshooting from becoming cosmetic. The screen is only the final presentation layer.
Good dashboards reduce cognitive load without becoming proof
Prioritize widgets that answer the shift’s most important questions: which incidents are severe, which entities appear compromised, which detections are increasing, which connectors are unhealthy, and where analysts should drill next. Remove redundant visualizations that compete for attention.
Use severity carefully. If every widget is red, color stops helping. Tune upstream detections so high-severity dashboard items deserve immediate attention. Dashboard design and event tuning should reinforce each other.
Review dashboards after major incidents. Ask which widget first exposed the problem, which pivots were missing, and which views created noise. Updating the dashboard from real investigations keeps it aligned with how the SOC actually works.
The strongest FortiAnalyzer analysts use dashboards to decide where to look next. They do not treat a chart as the end of an investigation. Every meaningful conclusion should be traceable to events, incidents, logs, or other evidence that explains the summarized number.
This habit also makes handoffs easier. Instead of saying “the SOC dashboard looked bad,” an analyst can provide the affected incident, entities, time range, underlying logs, and response actions. That evidence survives after the widget changes.
FortiView and the SOC Dashboard are powerful because they compress a large amount of telemetry into an operational view. Their value is highest when that compression accelerates a disciplined path back to the original security evidence.
Analyst handoffs should include the dashboard scope that produced the signal. Record the time range, device filter, widget, and drill-down path when escalating a case. Another analyst should be able to reproduce the view instead of receiving only a screenshot with no filter context.
Widget granularity should match the operational question. A global top-threat widget can be useful for command-center awareness, while a customer-specific or business-unit view may be necessary for actual ownership. Use custom views to prevent broad fleet activity from hiding a smaller but important local anomaly.
Connector-health widgets deserve the same attention as threat widgets because response automation depends on them. A red connector may mean the SOC can detect an incident but cannot execute its normal containment path. Treat that as degraded security operations, not merely an integration nuisance.
Role-based dashboard design can reduce alert fatigue. A shift analyst may need top incidents, event severity, and compromised hosts, while a SOC manager may need trends and workload. Tailor the default view to the decisions each role makes, while keeping drill-down paths consistent so teams can collaborate on the same evidence.
Dashboard thresholds should be connected to staffing and response capacity. If the SOC can investigate only a limited number of high-priority cases per hour, upstream detection and dashboard design should help that queue represent the most consequential risk. Visual priority without operational capacity creates chronic backlog.
Use the SOC Dashboard to monitor the health of the response system as well as the threat landscape. Connector status, incident volume, and event trends can reveal that analysts are losing response capability even before a specific attack is missed. Operational health is part of security visibility.
During post-incident review, recreate the original dashboard view before changing filters or widgets. This helps the team understand what the analyst could actually see at the time. Improvements can then be based on genuine visibility gaps rather than hindsight about evidence discovered later.
Dashboards should be versioned conceptually even if the interface does not provide source-control semantics. Record major widget, filter, and threshold changes so analysts know why the view changed. This is especially important when dashboard trends are used in management reporting, because a visual redesign can otherwise look like a change in the threat environment.