FortiAnalyzer turns security-device logs into searchable operational evidence, reports, events, and incident context. In the current Fortinet certification program, the available FortiAnalyzer 7.6 analytics material aligns with the NSE 5 FortiAnalyzer 7.6 Analyst role: collecting and analyzing telemetry, investigating events, working with Security Fabric data, and automating parts of detection and response. That is a broader responsibility than simply storing logs.
The key architectural distinction is between data retention and data that remains immediately usable for analytics. FortiAnalyzer maintains indexed Analytics logs for interactive views, event processing, and reporting, while older or policy-selected data can move into an Archive state where it is retained but not immediately available for the same analytic functions. Capacity planning, data policy, and operational expectations therefore have to be designed together.
Begin with reliable log collection and device authorization
Analysis is only as trustworthy as the telemetry entering the system. Managed devices need to send the expected log types to the correct FortiAnalyzer, and the FortiAnalyzer must recognize and authorize the devices according to the deployment model. Administrators should verify time synchronization, connectivity, device identity, ADOM placement, and log reception before troubleshooting a missing report or event.
Log settings on FortiGate also determine which evidence exists. If a firewall policy does not log accepted traffic, FortiAnalyzer cannot reconstruct those sessions later. If security profiles generate rich threat logs but administrative events are not retained, a different class of investigation will have gaps. Collection requirements should be derived from operational, security, and compliance use cases.
Network-device telemetry is easier to reason about when each source has a defined purpose. The deeper discussion of network device logs provides useful context: traffic records, system events, configuration changes, authentication activity, and threat detections answer different investigative questions and should not be treated as interchangeable records.
Understand Analytics logs versus Archive logs
FortiAnalyzer’s log workflow distinguishes indexed Analytics logs from compressed Archive logs. Analytics logs are online and indexed so FortiView, Log View, Incidents & Events, and Reports can use them directly. Archive logs preserve data for longer-term retention but are not immediately available for the same interactive analytic operations.
This affects data-policy design. Keeping every log indexed forever would increase storage and database requirements, while archiving too aggressively can make ordinary investigations slow or impossible without restoration workflows. Define how far back analysts routinely search, how long reports need source data, and what retention obligations apply beyond that window.
Capacity decisions should use observed log rates rather than device count alone. Two FortiGates can generate very different volumes depending on traffic, policy logging, security profiles, and user population. Monitor actual daily ingestion, growth, and indexed-retention consumption, then adjust policy before disks become an emergency.
Use Log View to answer concrete investigative questions
Log View is most effective when an analyst starts with a question. “Why was this user blocked from this server?” suggests filters for time, source, destination, policy, action, and perhaps user. “Did this host contact a malicious domain?” suggests traffic, DNS, web-filter, or threat logs around the incident window. Narrowing the question produces a smaller and more defensible evidence set.
Filters should preserve chronology. Security incidents often span several log types, so analysts may start from a threat detection and pivot into traffic or authentication records before and after it. Consistent timestamps and device time are therefore essential; a time skew can make cause and effect appear reversed.
Saved searches and repeatable filters can standardize common workflows, but analysts should understand the underlying fields. A filter that depends on one device’s custom logging behavior can silently miss another device. Validate queries against known examples before turning them into operational procedure.
Build reports from datasets, charts, and macros
FortiAnalyzer reports are built from structured data components rather than screenshots. Datasets query relevant log information; charts present dataset results; macros can insert calculated or selected values; templates arrange those elements into a repeatable report. Predefined content provides a starting point, while custom datasets and templates support environment-specific questions.
Current FortiAnalyzer documentation notes that ordinary reports use Analytics logs, not Archive logs. That makes report design inseparable from retention policy. A monthly report that needs 30 days of source data cannot be generated reliably if the required log types move to archive after seven days.
Reports should be designed for decisions, not volume. A security leader may need trends in critical events and response status, while a network team may need top denied destinations or bandwidth consumers. A 100-page report that no one acts on is less useful than a short report tied to an owner and review cadence.
Use event handlers to turn logs into security signals
Event handlers evaluate logs and generate events when defined conditions are met. Basic handlers can trigger when one of their rules matches, while correlation handlers can evaluate sequences and logical relationships between rules. This allows FortiAnalyzer to raise a higher-level signal from activity that would be tedious to watch log by log.
Data selectors define which devices, subnets, or filters the handler uses, and notification profiles control how an event is communicated. Keeping these components reusable helps prevent inconsistent copies of the same logic. Analysts should know which ADOM owns the handler and which log sources it can actually see.
A useful handler has a threat hypothesis behind it. Repeated failed logins from one source, for example, may matter only when frequency, target, and time window are considered together. The goal is not to turn every log into an alert but to identify patterns that deserve analyst attention.
Distinguish events from incidents
An event is a detected condition; an incident is a tracked investigation or response object. FortiAnalyzer can raise incidents from events so analysts can attach context, assign ownership, record comments, review audit history, associate related events, and carry the case through investigation. This is an important step from “something happened” to “someone is responsible for deciding what it means.”
The distinction mirrors the broader SIEM workflow: collection produces data, detection produces signals, and incident handling creates an accountable response process. Treating all three as one stage leads either to alert overload or to investigations that lack traceability.
Analysts should define criteria for raising, merging, suppressing, and closing incidents. A low-severity event may be important when it repeats across many hosts, while a high-severity detection may be benign in a sanctioned testing environment. Context determines priority.
Keep report and event logic aligned with ADOM boundaries
Administrative Domains separate devices and data for management and analysis. In multi-tenant, geographic, or large-enterprise designs, the correct ADOM context is essential because event handlers, reports, and searches operate against the data available there. An analyst in the wrong ADOM can conclude that logs are missing when the data is simply outside the current scope.
ADOM structure should follow operational ownership and data-separation requirements. Too many tiny ADOMs can fragment investigations across related systems, while an overly broad ADOM can violate tenant or responsibility boundaries. Design the grouping before building large libraries of reports and event handlers around it.
When content must be reused across ADOMs, use documented export/import or standardized configuration processes rather than ad hoc recreation. That helps preserve consistent detection logic while still respecting data separation.
Validate reports and detections against known traffic
A report that generates successfully is not necessarily correct. Test datasets against known log records, confirm fields and time ranges, and compare totals with Log View. For event handlers, create or identify a controlled condition that should trigger and verify the resulting event, severity, notification, and incident workflow.
This validation catches subtle mistakes such as a filter that matches a text representation rather than the intended field, a report scoped to the wrong device group, or a handler that evaluates only Analytics logs while the relevant data has already aged into Archive storage.
Keep validation examples with the content definition. When a report or detection is modified months later, an analyst can rerun the same known case and determine whether the logic still produces the expected outcome.
Log normalization and field quality become increasingly important when FortiAnalyzer ingests data from several product types. Analysts need consistent meanings for source, destination, user, action, severity, and device identity if they want one query or report to work across the environment. Where the SIEM database and parsers are used, validate normalized fields against raw records so important detail is not lost in abstraction.
Reports also need scheduling and distribution controls. Decide who receives each report, how often the data is meaningful, and whether recipients need the full document or only an exception summary. Sensitive reports can contain user identities, internal addresses, and security findings, so delivery locations and access permissions should match the sensitivity of the underlying logs.
Event-handler tuning should track false positives and missed detections. If analysts repeatedly suppress the same benign pattern, improve the filter or correlation rule rather than relying on human memory. If a confirmed incident produced no useful event, work backward from the relevant logs and identify which handler condition or data source was missing.
Data restoration procedures should be understood before an old incident occurs. Archive retention is valuable only if the organization can locate and restore the required logs within an acceptable time. Periodically test a historical retrieval so compliance or forensic requests do not become the first time the team discovers how archived data is recovered.
Backup and disaster-recovery planning should include the FortiAnalyzer configuration and the log evidence the organization cannot afford to lose. Define how configuration, certificates, report content, and retained logs are protected, and test restoration procedures on a schedule. An analytics platform becomes part of the incident-response dependency chain once teams rely on it for investigations.
Define who owns content maintenance. Reports, datasets, and handlers can become stale as fields, products, and threat patterns change. Assign review dates and keep a small validation case for each critical detection or report so upgrades do not silently erode the analytics the SOC depends on.
Operate FortiAnalyzer as an evidence platform
The strongest FortiAnalyzer deployments connect retention, search, reporting, detection, and incident handling into one evidence lifecycle. Collection settings ensure the right logs exist. Data policy keeps them analytically available for the required period. Searches and datasets extract meaning. Event handlers identify patterns. Incidents create ownership and preserve response context.
That lifecycle also requires maintenance: monitor storage, ingestion, database health, licensing where relevant, FortiGuard content, connectors, and clock synchronization. A beautifully designed report library will not help during an incident if data collection stopped silently three days earlier.
For current Fortinet candidates, the useful mental model is to follow one security observation from raw log through investigation. Know where it is stored, how it can be filtered, which dataset or event handler can use it, when it becomes an incident, and how a report communicates the result. That ability is more durable than memorizing the location of a particular GUI button.