FortiAnalyzer Log Management in Dubai, UAE
A useful log-management platform does more than keep records. It must help an IT or security team bring together events from distributed systems, find meaningful activity quickly, retain the right data for operational and audit needs, create reports, and support investigation when something goes wrong. FortiAnalyzer is Fortinet’s platform for centralised logging, analytics and broader security-operations workflows. It can be deployed as dedicated hardware, a virtual appliance or a cloud service. The right choice depends on how much data the organisation generates, how long logs must be kept, which systems will send data, where the platform should run, and which security services or automation functions are required.
Start with these sizing facts
A quotation is more accurate when the requirement is described in operational terms rather than by product name alone.
- Approximate log volume in GB per day
- Number and type of log sources
- Analytics and archive retention targets
- Appliance, VM or cloud preference
- Reporting, automation and optional service needs
Direct answer: what is FortiAnalyzer Log Management?
FortiAnalyzer is a central platform for collecting and working with logs and security telemetry from supported Fortinet and selected third-party environments. Businesses mainly use it to keep searchable records, generate reports, investigate events, monitor trends, support security operations and manage retention more consistently than they can with isolated device logs. It is most relevant to organisations running multiple security devices, distributed sites, regulated workloads, formal incident-response processes or a Security Operations Center. Before proceeding, buyers should confirm the expected GB of logs per day, device count, VDOM and ADOM needs, desired retention, deployment location, high-availability expectations and the specific licenses or optional services required for their use case.
What it does in a working network
Security devices continuously create evidence about traffic, policy decisions, authentication events, detected threats, system activity and administrator actions. When those records remain scattered across appliances, troubleshooting and investigation become slower because analysts must search several interfaces and may find that local retention is too short. FortiAnalyzer gives the organisation a central place to ingest supported logs, index the data needed for analysis, preserve archive data according to policy, run searches, build dashboards and produce reports.
The value becomes clearer when the network grows. A branch-firewall estate, for example, can generate events across many sites at the same time. Centralisation allows an engineer to compare activity instead of treating each branch as a separate island. A security team can investigate a suspicious IP, user or host across a broader data set. Operations teams can use historical records to understand connectivity patterns and recurring problems. Management can receive scheduled reports rather than asking technical staff to collect screenshots from individual devices.
FortiAnalyzer has also developed beyond basic log storage. Current Fortinet material positions it as a security-operations platform with analytics, incident handling, alert processing, automation, threat-intelligence integration and optional AI-assisted workflows. Not every capability is necessarily included in every deployment. The available function set can depend on software release, product form factor, service entitlement, log source and configuration, which is why a purchase should be based on the required workflow rather than a general feature list.
Who should consider it?
FortiAnalyzer is especially relevant when an organisation wants a dedicated logging and analytics layer for a Fortinet-focused environment. It can suit an IT department responsible for several FortiGate firewalls, a security team that requires central investigation, a multi-site business that wants unified reporting, or an enterprise that needs defined log-retention and audit processes. It can also be used where an organisation wants to forward selected information to a larger SIEM while keeping other data in FortiAnalyzer.
A small single-site customer with very low logging requirements may not need a large physical appliance. In that case, a smaller platform, VM tier or cloud approach may be more appropriate. At the other extreme, very high-volume environments should not select a model from device count alone; daily ingestion, logs per second, storage, retention, query load, reporting activity and future expansion all affect sizing. Managed-service providers and organisations using administrative domains must also examine ADOM limits and tenancy design.
The strongest candidates are buyers who can describe the operational outcome they want: longer searchable history, central reporting, easier investigations, SOC workflows, cloud-based logging, reduced dependence on local device storage, or a more structured path for security telemetry. FourTeck can translate those goals into the information needed for a model, license and deployment discussion.
Business problems FortiAnalyzer can help address
The main reason to introduce a central logging platform is usually operational friction. The following issues are common triggers for a FortiAnalyzer project, but the exact result depends on the quality of logging configuration, retention policy and deployment design.
Logs disappear too quickly
Local devices may retain only a limited history, particularly when traffic volume is high. A central platform allows the organisation to plan retention deliberately. FortiAnalyzer distinguishes between analytics data used for indexed search and reporting and archive data retained for longer-term storage. The correct periods should be designed around business, technical and compliance requirements rather than arbitrary defaults.
Investigations require too many consoles
Searching device by device can make it difficult to reconstruct an incident that crosses users, branches or systems. Centralised telemetry can provide a broader view and more consistent search workflow. The benefit still depends on whether relevant devices are logging the right events and whether timestamps, identities and policy data are available.
Reporting consumes engineering time
Recurring reports are easier to manage when they draw from centrally stored analytics logs. FortiAnalyzer provides report templates and custom report capabilities. Buyers should confirm that the required log fields and analytics-retention period will support the reports they expect to generate.
Security teams need faster triage
Modern FortiAnalyzer capabilities include alerts, incidents, playbooks, threat hunting and optional services that can enrich security operations. These functions are useful when the organisation has a defined triage process and staff who can act on the output. A tool cannot replace ownership of incident-response decisions.
Multi-site visibility is fragmented
Distributed offices create separate streams of operational data. Central logging can help compare locations, review network behaviour and support troubleshooting from a common interface. Network connectivity, bandwidth and secure log transport must be planned so remote sites can send data reliably.
The SIEM is expensive to feed
Fortinet describes log forwarding as one use case in which FortiAnalyzer can ingest and retain logs while selected or filtered data is forwarded to another platform. Whether this lowers cost depends on the external SIEM’s commercial model, the filter strategy and the operational requirement for complete data.
Core capabilities buyers should evaluate
Central log repository
Collect supported telemetry into a shared platform so operations and security teams are not dependent on individual device histories.
Search and investigation
Use indexed analytics data, filtering and contextual views to trace activity across time, users, devices and security events.
Dashboards and reports
Turn stored logs into repeatable operational, security and management views. Report usefulness depends on the available data and retention.
Alerts and incidents
Support security workflows with alert handlers, incident records and investigation context where the deployment and entitlements provide these functions.
Automation
Playbooks can trigger defined tasks around incidents and alerts. The organisation should validate each automated action before enabling production response.
Flexible deployment
Choose hardware, virtual-machine or FortiAnalyzer Cloud models according to infrastructure policy, capacity, operational ownership and regional requirements.
FortiAnalyzer fit matrix
| Requirement | Suitable when | Confirm before ordering |
|---|---|---|
| Central firewall logging | Multiple FortiGate devices need shared search and reporting. | Daily GB, LPS, device/VDOM count and retention. |
| Longer operational history | Local appliance logs do not cover the investigation period. | Analytics versus archive retention and storage design. |
| SOC workflows | Analysts need alerts, incidents, hunting and automation in a Fortinet-oriented stack. | Required services, integrations, workflow ownership and software release. |
| Cloud-first operations | The organisation wants central logging without managing an on-premises FortiAnalyzer server. | Per-device versus GB/day licensing, source support and region. |
| Private-cloud or virtual deployment | Existing compute infrastructure is preferred over a dedicated hardware appliance. | Supported hypervisor/cloud, compute, storage and license tier. |
| Tenant separation | Operational teams need administrative domains for separated visibility or administration. | ADOM entitlement, maximums, account model and reporting design. |
Licensing, storage and compatibility dependencies
Choose the commercial model before the SKU
A buyer can make the wrong purchase even when the technical platform is suitable if the commercial model does not match operations. Hardware appliances bundle compute and storage into a dedicated device. VM deployments place responsibility for the underlying compute and storage on the customer or cloud environment. FortiAnalyzer Cloud shifts more platform operation to the service while introducing source-specific subscription rules. These are materially different buying decisions.
For VM, current Fortinet guidance separates subscription bundles from perpetual ingestion licenses. Subscription bundles are stackable at defined daily-ingestion units and include a set of services. Perpetual licenses are also sized by GB/day, but associated support and service items can be purchased separately and may need to align with the total ingestion tier. A quotation should therefore identify not only total GB/day but also whether the customer wants a subscription or perpetual model and which security services are required.
Plan analytics retention separately from archive retention
Retention is often described as one number, such as ninety days or one year, but FortiAnalyzer distinguishes indexed analytics data from archive data. Reports use analytics logs. If a business needs to rerun historical reports or perform interactive searches over a long period, the analytics window must be long enough to support that activity. Archive retention can then preserve older records according to policy, but it should not be treated as a substitute for indexed history when operational users expect fast query and reporting access.
Storage planning should consider daily ingestion, burst behaviour, the proportion of logs retained for analysis, archive policy and expected growth. Large reporting jobs and investigation activity can also influence system load. FourTeck can help document the retention objective so the final design is based on how the data will be used, rather than simply multiplying today’s average log volume by a target number of days.
Validate every log source
FortiAnalyzer has deep alignment with Fortinet products, but buyers should still confirm each source and the logging method. FortiAnalyzer Cloud in particular has different licensing paths for FortiGate, FortiWeb and other supported devices. Current Fortinet guidance states that FortiGate and FortiWeb cloud logging uses device-based subscriptions, while shared GB/day licensing is used for additional capacity and supported source types. Third-party support may require specific parsers, services or architecture.
The presence of a connector does not automatically mean every field, event category or workflow will behave like a native Fortinet source. If an important business process depends on a third-party application, confirm what logs are ingested, how they are parsed, whether they appear in the required report or incident view, and whether the use case requires an optional service.
A practical FortiAnalyzer deployment and purchase journey
Measure the data
Collect real log-volume information from representative days. Separate average from peak periods and identify the devices producing the largest share. Include planned new sites and firewall upgrades so the sizing exercise is not obsolete on day one.
Define retention
Decide how long analysts need indexed data for search and reporting, then define longer archive requirements separately. Record whether retention is driven by policy, audit practice, troubleshooting or incident investigation.
Choose deployment type
Compare appliance, VM and cloud options based on infrastructure policy, data location, operational ownership, resilience, capacity growth and commercial preference. Do not assume cloud is automatically simpler for every source or license model.
Map sources and tenants
List FortiGate, FortiWeb, endpoint, email, network and third-party sources. Define VDOM and ADOM structure, administrative boundaries and any managed-service or multi-tenant requirement.
Select services
Identify which operations genuinely require IOC, outbreak, automation, OT, compliance, FortiAI-related or support features. Confirm whether the chosen bundle already includes them and whether add-on tiers must match ingestion capacity.
Design connectivity
Plan how every source reaches FortiAnalyzer, including remote branches and cloud networks. Consider routing, firewall policy, DNS, time synchronisation, secure administration, backup paths and bandwidth impact.
Test logging and reports
Before treating the platform as operationally complete, verify that key log types arrive, timestamps are correct, identity fields are populated, alerts behave as expected and required reports contain usable data.
Document ownership
Define who maintains retention, device authorisation, user access, reports, alert handlers, playbooks, upgrades, backups and license renewals. Central logging becomes dependable when operational responsibility is clear.
Capability focus: building a usable retention strategy
Retention is one of the most important FortiAnalyzer design decisions because it connects storage, performance, reporting and incident-response expectations. A requirement such as “keep logs for one year” is incomplete. The engineering team needs to know how much of that year must remain readily searchable and reportable, which sources are included, whether every traffic log is equally important, and what happens when the platform approaches its allocated storage limits.
FortiAnalyzer separates analytics logs from archive logs. Analytics logs are indexed and used for report generation. Archive logs can preserve data for longer periods but are not the dataset FortiAnalyzer uses directly for reports. This distinction matters to audit and security teams. If an auditor asks for a report covering a period older than the analytics window, simply having archived records does not mean the report can be generated in the same way as a current one. Buyers should therefore align the analytics period with real investigation and reporting needs, then use archive retention for older evidence where appropriate.
The second consideration is daily ingestion. A firewall estate may appear stable until a new branch, a logging-policy change or a security incident increases volume sharply. Retention planning should include growth headroom and a method for reviewing actual utilisation after deployment. A platform sized exactly to an average day can become uncomfortable during peak periods. The right design balances storage cost against the operational value of keeping data online.
Finally, policy ownership matters. Someone should be responsible for approving changes to retention, reviewing disk utilisation, validating that critical sources continue to log and confirming that archive behaviour matches the organisation’s information-governance requirements. FourTeck can help structure these questions during sizing, while the customer’s security, infrastructure and compliance stakeholders define the business policy.
Capability focus: faster investigation without losing context
A central log platform is most valuable during a problem that crosses boundaries. A user may report slow access to a cloud application, a security team may see a suspicious connection, or an administrator may need to determine which policy allowed traffic several days earlier. FortiAnalyzer can bring relevant records into one search and analysis environment rather than forcing the team to inspect each device separately.
The quality of the investigation still depends on the data that was collected. Traffic logs without user identity cannot answer a user-specific question. A report may show no data if the required analytics logs are missing or if logging was not enabled correctly. Time synchronisation is equally important because incident timelines become confusing when devices disagree about timestamps. A well-designed FortiAnalyzer project therefore includes validation of the source logging policy, not only installation of the central platform.
Current FortiAnalyzer releases also provide incident-oriented functions, alert handlers, threat hunting and playbooks. An incident record can bring together alerts and associated investigation context, while automation can execute defined tasks when configured triggers are met. These capabilities can reduce repetitive analyst work, but they should be introduced with governance. Teams need clear thresholds for escalation, a review process for automated actions and documentation of what a playbook is allowed to change.
For organisations that already operate a separate SIEM, FortiAnalyzer can still have a role. Fortinet describes architectures in which FortiAnalyzer collects and retains logs while selected data is forwarded onward. This can be useful where Fortinet-specific analysis and reporting are required locally, while enterprise correlation occurs elsewhere. The integration should be designed according to which platform is the system of record for each workflow.
Capability focus: scaling administration across sites and teams
As log volumes grow, administration becomes as important as raw capacity. FortiAnalyzer supports Administrative Domains, commonly called ADOMs, which can separate log data and administrative scope. This is useful for organisations with multiple business units, managed environments, delegated operations or distinct reporting boundaries. Each ADOM can also have its own storage policy. The number of ADOMs available depends on the platform, licensed capacity and software release, so an organisation that expects many tenants should treat ADOM scale as a core sizing requirement.
Role design should be planned at the same time. A SOC analyst may need broad search and incident visibility but should not necessarily change system-level settings. A regional administrator may need access only to a defined set of devices. Reporting users may need read-only access. Mapping these responsibilities before implementation makes it easier to configure privileges coherently and to avoid sharing broad administrative credentials.
Large environments may also need collector or high-availability architectures. Current Fortinet ordering guidance describes collector-only options and specific requirements for HA members, including matched platform characteristics and compatible operating modes. These designs should be treated as architecture projects rather than simple accessory purchases. Network placement, latency, capacity distribution, failure behaviour and operational runbooks all matter.
For VM and cloud deployments, scalability also has a commercial dimension because ingestion entitlement is licensed. A rising log volume can require additional GB/day capacity even if infrastructure resources appear sufficient. FourTeck can help buyers separate platform sizing from license sizing so both parts of the design grow together.
Suitable business environments and practical use cases
Multi-branch enterprises
Retail, logistics, professional-service, education and distributed office networks can centralise logs from branch security devices for common search, trend review and reporting. The design should consider WAN reliability and the volume each branch sends.
Security operations teams
SOC teams can use central telemetry, alerting, incidents, hunting, automation and optional security services as part of a defined triage and investigation workflow. Capabilities should be matched to analyst processes and license entitlements.
Audit and governance programmes
Organisations that must preserve operational records can use planned retention and reporting to support evidence collection. Regulatory requirements vary, so the customer should define the applicable retention and access policy with its compliance stakeholders.
Managed IT environments
Administrative domains can help separate customers, departments or operational scopes. Service providers should validate ADOM limits, access control, report segregation, ingestion scale and contractual data-handling responsibilities.
Cloud-oriented businesses
FortiAnalyzer Cloud may suit organisations that prefer a hosted logging service, while FortiAnalyzer-VM can run in supported public cloud environments when the organisation wants control over the virtual appliance. Licensing and operational ownership differ between the two approaches.
Hybrid monitoring architectures
FortiAnalyzer can form one layer of a wider security-monitoring design, retaining and analysing Fortinet data while forwarding selected information to another SIEM or data platform. Forwarding policy and event ownership should be documented clearly.
Integration and operational considerations
The central platform should be introduced as part of the network architecture, not as an isolated server. Every logging source needs a reachable path to the selected FortiAnalyzer instance. Remote branches may require routing and firewall policy changes. Public-cloud workloads may need security-group or network-policy configuration. DNS and time services should be reliable. Management access should use restricted administrative networks where possible.
Log settings on the source device must also be reviewed. Collecting everything can consume unnecessary capacity, while collecting too little can leave gaps during an investigation. Teams should decide which traffic, security, system and administrative events are required. A change-control process is useful because a source-policy change can materially alter daily ingestion and retention.
Reports should be treated as outputs of the logging design. If a report requires a field that the source does not populate, FortiAnalyzer cannot create that evidence retrospectively. Fortinet documentation notes, for example, that user-oriented reports rely on user information being present in the source logs. A pilot should therefore include the actual dashboards and reports the customer expects to use in production.
Backup, upgrade and recovery procedures are another area for planning. The organisation should know what configuration is backed up, where backups are kept, how appliance or VM updates are scheduled, and what the recovery objective is if the platform becomes unavailable. High availability can reduce some forms of service interruption but does not remove the need for operational procedures.
Compatibility and dependency notice
FortiAnalyzer capabilities are configuration, version and license dependent. Before ordering, confirm the exact FortiAnalyzer release, source-device versions, supported log types, VM or cloud platform, service subscriptions and any third-party parser requirement.
Optional services should not be assumed to be included. FortiAnalyzer Cloud, VM subscription bundles, VM perpetual licensing and hardware bundles have different commercial structures. HA deployments, FortiAI-related services, OT functions and other add-ons can create additional requirements.
For a current bill of materials, contact FourTeck with the source inventory and expected log volume so the recommendation can be checked against current Fortinet ordering guidance.
Questions buyers should resolve before requesting a quotation
How much data arrives each day?
Use measured log data if available. If not, provide source models, quantity, user scale and current logging policy so a realistic estimate can be developed. Include growth expected over the intended ownership period.
How long must data remain searchable?
Define analytics and archive periods separately. If ninety-day interactive investigation is required, the analytics design should reflect that rather than storing most history only as archive.
Where should FortiAnalyzer run?
A physical appliance can simplify dedicated-resource planning. VM can align with private-cloud standards. FortiAnalyzer Cloud can reduce platform administration. Data location, network architecture and commercial preference affect the choice.
Which services are actually needed?
List required incident, automation, IOC, outbreak, OT, compliance, AI-assisted or support functions. Then confirm how each is licensed for the selected platform.
How many administrative domains?
ADOM requirements can influence platform choice and licensing. Managed services, business-unit separation and delegated administration should be planned before sizing.
What must integrate with it?
Document Fortinet products, third-party devices, external SIEMs, ticketing or notification workflows, identity systems and cloud environments that are part of the operating model.
Procurement checklist for FortiAnalyzer Log Management
Share this information with FourTeck when requesting a quotation. If some values are unknown, provide representative firewall or security-device models and the expected environment size so the requirement can be reviewed before the bill of materials is finalised.
How FourTeck can support the buying process
FourTeck can help turn a broad request for “FortiAnalyzer logging” into a requirement that can be quoted and deployed with fewer assumptions. The process can include source inventory review, log-volume sizing, retention planning, hardware-versus-VM-versus-cloud comparison, license mapping, ADOM requirements, compatibility review and identification of optional services.
Where implementation support is required, the quotation can also define tasks such as platform setup, device authorisation, basic retention configuration, reporting, alert configuration, migration planning or integration with an existing Fortinet environment. The exact scope depends on the customer’s network, access arrangements and operational expectations.
For broader Fortinet planning, buyers can also review FourTeck Fortinet firewall guidance and network security services.
UAE availability and support guidance
Contact FourTeck to confirm current UAE availability for the required FortiAnalyzer model, VM entitlement or cloud subscription. Availability can depend on the exact SKU, quantity, license term, region and vendor lead time. A product family name is not enough for a reliable stock or delivery statement because FortiAnalyzer includes hardware, virtual and cloud options with different ordering structures.
If installation or configuration is required, include that scope in the quotation so access, change windows, remote or onsite coordination and customer responsibilities can be planned. Delivery and project scheduling should be discussed only after the exact requirement is confirmed. Use the FourTeck contact page to share the log-volume and deployment details.
Dubai, Abu Dhabi, Sharjah and Ajman coverage
Businesses across Dubai, Abu Dhabi, Sharjah and Ajman can contact FourTeck for FortiAnalyzer requirement review, quotation coordination and deployment planning. A multi-emirate organisation should identify where the FortiAnalyzer platform will be hosted and which branches will send logs to it. That helps determine network paths, WAN impact, administrative ownership and whether a single central instance or a more distributed architecture is appropriate. For cloud deployments, the physical location of branch devices still matters because source connectivity and licensing must be considered. For appliance and VM deployments, data-center location, resilience and remote-access policy become part of the design. FourTeck can coordinate the commercial and technical discussion after the business provides the main source inventory, daily log estimate and required retention period.
GCC Availability
Organisations planning FortiAnalyzer across the GCC can ask FourTeck to review the requirement before model and license selection. Projects may involve the United Arab Emirates, Saudi Arabia, Kuwait, Qatar, Bahrain or Oman, but the correct commercial and technical approach depends on where the logging platform will run and where the data sources are located. FourTeck can assist with requirement review, ingestion sizing, license or subscription mapping, quotation coordination, configuration scope, installation planning and renewal guidance. Product availability, cloud entitlement, service visits, delivery schedules and vendor lead times can vary by country, model, quantity and license term. Buyers should share the destination country, expected GB/day, device types, desired deployment model, retention target and project timeline. For Kuwait-related regional enquiries, customers can also review FourTeck Kuwait resources. No regional project should assume local stock or a fixed installation date until the exact order and scope are confirmed.
Africa Availability
For African deployments, FortiAnalyzer planning should begin with the destination country, source inventory and data-location requirement. FourTeck can help organisations evaluate appliance, VM and cloud approaches; identify likely license and subscription needs; review accessories and support requirements; and prepare a clearer procurement request. Availability and fulfilment may depend on the destination, product model, license region, quantity, power or data-center conditions, shipping arrangements, vendor lead time and local implementation scope. Businesses should provide the required product or service, expected log volume, quantity, deployment location, preferred schedule and any installation or support expectations. For regional technology enquiries, see FourTeck Africa, FourTeck Kenya or FourTeck Uganda. Country-wide onsite coverage, customs outcomes and immediate shipment should be confirmed separately rather than assumed from a regional enquiry.
Related products and services to consider
FortiGate firewalls
A common source of FortiAnalyzer logs. Confirm firewall models, VDOM count, firmware level and logging policy when sizing.
FortiManager
Centralised device and policy management can complement FortiAnalyzer in larger Fortinet estates. The products address different operational functions and should be scoped separately.
FortiAnalyzer Cloud
A hosted option for supported central logging and analytics. Licensing varies by source and ingestion requirements.
FortiAnalyzer-VM
Useful where private or public cloud infrastructure is preferred. Compute, storage, platform support and license capacity should be checked together.
Configuration services
Can include source onboarding, retention setup, reporting, access roles, alerting, documentation and integration according to agreed scope.
Why businesses contact FourTeck for FortiAnalyzer planning
The difficult part of FortiAnalyzer procurement is rarely the product name. It is translating operational requirements into an order that has enough ingestion capacity, the correct retention design, compatible deployment resources and the appropriate licenses. FourTeck can help clarify those inputs and coordinate a quotation around the actual environment.
Typical assistance includes identifying whether hardware, VM or cloud is the more practical fit; checking model or license tiers against daily ingestion; reviewing ADOM and device scale; discussing high-availability or collector requirements; mapping optional services; and separating the platform quotation from implementation work. This reduces the chance of buying a license tier that does not match the logging objective or overlooking a dependency that becomes apparent only during deployment.
FourTeck can also coordinate related firewall, network and security requirements. Buyers who are still deciding the wider architecture can browse FourTeck technology products or contact the team for a requirement-led discussion.
What buyers usually need to know before choosing FortiAnalyzer
People researching FortiAnalyzer often start with simple questions such as whether they need an appliance, whether the VM license is based on storage, how FortiAnalyzer Cloud is licensed, or how much retention a particular model provides. Those questions are useful, but they become much easier to answer when the buyer first understands the sizing model. FortiAnalyzer is not selected only by the number of firewalls. Daily log ingestion is a primary capacity measure, and the real design also considers logs per second, device or VDOM scale, ADOM needs, analytics retention, archive retention and the operational load created by reports and investigations.
For VM and cloud options, entitlement is commonly expressed in GB/day. Storage must still be sufficient for the desired retention. In cloud, the service scales backend resources according to entitlements and policy, while VM deployments require the customer to provision resources. For hardware, each model has its own storage and performance characteristics.
A common misunderstanding is that keeping an archive for a year automatically provides one year of historical reporting. FortiAnalyzer reports use analytics logs. If the reportable investigation window must be longer, the analytics retention setting needs to reflect that requirement.
Another frequent question is whether FortiAnalyzer is only for FortiGate. FortiGate is a major logging source, but current Fortinet materials describe broader Security Fabric telemetry and supported third-party integration. Buyers should not assume universal support, however. The exact source, parsing method, fields and license path should be checked. FortiAnalyzer Cloud makes this especially important because FortiGate and FortiWeb use per-device subscriptions, while shared GB/day licensing is used for additional ingestion and other supported source types. When several source categories are involved, a source-by-source license worksheet is more reliable than a single broad estimate.
Customers also compare FortiAnalyzer with a full enterprise SIEM. The right answer depends on the use case. FortiAnalyzer provides central logging, analytics, reporting and modern security-operations capabilities within the Fortinet ecosystem, and Fortinet positions it as a platform with SIEM, SOAR and XDR-related functions. A large organisation may still operate another SIEM for cross-vendor enterprise correlation, long-term data-lake requirements or specialised integrations. In that architecture, FortiAnalyzer can remain valuable for Fortinet-focused analysis, local retention and controlled forwarding. The decision should be based on workflow ownership, data sources, investigation requirements and commercial structure rather than on labels alone.
Sizing questions often become urgent when an organisation has a fixed retention policy. A practical approach is to gather at least several representative days of log volume, including a busy period. Identify which sources produce most of the data, then project known changes such as new branches, more users, additional security profiles or increased firewall throughput. From there, define the analytics window. If the security team usually investigates thirty to ninety days back, keeping only a short analytics period may undermine the project even if the archive is large. Conversely, keeping every log indexed for an unnecessarily long time may increase infrastructure requirements without proportional operational value.
Buyers should also ask what happens when licensed ingestion is exceeded. Current FortiAnalyzer Cloud guidance warns that logs can be throttled or dropped if ingestion exceeds entitlement. This makes capacity monitoring important after deployment. A design is not finished when the license is activated; someone should review actual consumption, growth and retention behaviour. The same principle applies to VM and hardware environments, where storage and performance headroom should be monitored before the platform reaches operational limits.
The final research question is often price. FortiAnalyzer pricing varies widely because hardware models, VM capacity, subscription terms, services, support level and cloud licensing are different products. A useful quotation request therefore lists deployment preference, GB/day, source count, retention, optional services and required term. FourTeck can use that information to help identify the correct current SKU and quotation path instead of giving a price for a product that may not fit the requirement.
Decision questions that affect sizing and deployment
Do we need FortiAnalyzer hardware or a VM?
Hardware gives the project a dedicated Fortinet appliance with model-defined capacity. VM can fit organisations that already standardise on virtual infrastructure or public cloud. The decision should consider operational ownership, storage architecture, resilience, support model and growth. A VM is not automatically cheaper because the customer must still provide suitable compute, storage and backup processes.
When is FortiAnalyzer Cloud preferable?
Cloud can make sense when the organisation wants central logging without operating a local FortiAnalyzer platform. The trade-off is that source support and licensing must follow the cloud service rules. Confirm how each FortiGate, FortiWeb or other supported source will be entitled and whether shared GB/day capacity is needed.
How much retention should we buy?
Start with the investigation and reporting period, not a generic number. Keep enough analytics history for the searches and reports users actually perform, then add archive retention for older evidence. The answer can differ between an operational troubleshooting team and a compliance-led organisation.
Do we need high availability?
HA is relevant when loss of the logging platform would create unacceptable operational risk. It requires compatible FortiAnalyzer members and coordinated configuration. Buyers should also consider network design, storage, support entitlements and what happens to log forwarding during a failure.
Can we use FortiAnalyzer with an existing SIEM?
Yes, a layered design can be appropriate. Decide which data FortiAnalyzer retains, which events are forwarded, which platform owns correlation and incident handling, and how duplicated alerts will be controlled. The integration objective should be documented before implementation.
What information should we send for a quote?
Provide source models and quantities, measured or estimated GB/day, retention targets, deployment preference, ADOM count, HA expectation, license term and optional service needs. If installation is required, include the number of sites and whether access will be remote, onsite or coordinated with an existing IT team.
Frequently asked questions
1. What is FortiAnalyzer mainly used for?
FortiAnalyzer is mainly used for central log collection, analytics, reporting and security-operations workflows across supported Fortinet and selected third-party sources. It helps teams retain logs, search historical activity, investigate incidents and create reports from a shared platform.
2. Is FortiAnalyzer available as hardware, VM and cloud?
Yes. Fortinet provides FortiAnalyzer hardware appliances, virtual-machine licensing and FortiAnalyzer Cloud. The right option depends on log volume, infrastructure preference, retention, source types, regional policy and the organisation’s preferred operating model.
3. How is FortiAnalyzer VM licensed?
Current Fortinet ordering guidance includes stackable VM subscription bundles based on GB/day and perpetual VM ingestion licenses at defined GB/day tiers. Support and optional services differ between the models, so the total ingestion requirement and service scope should be confirmed before ordering.
4. How is FortiAnalyzer Cloud licensed?
FortiAnalyzer Cloud uses source-dependent licensing. FortiGate and FortiWeb can use per-device subscriptions, while shared GB/day subscriptions support additional ingestion and other supported source categories. Exact entitlement varies by device and should be checked against current Fortinet guidance.
5. What is the difference between analytics and archive logs?
Analytics logs are indexed data used for search and report generation. Archive logs are retained for longer-term storage. Because reports use analytics logs, buyers should make the analytics retention period long enough for the historical reporting and investigation window they require.
6. Can FortiAnalyzer support multiple departments or customers?
Administrative Domains can separate logs and administrative scope, making them relevant to multi-department or managed environments. ADOM availability and maximums depend on platform, licensed ingestion and software release, so the required count should be included in sizing.
7. Does FortiAnalyzer include every security service by default?
No. Service inclusion depends on the hardware bundle, VM subscription, VM perpetual deployment, cloud subscription and selected add-ons. IOC, automation, OT, compliance, FortiAI-related functions and support tiers should be checked individually.
8. What should be measured before sizing FortiAnalyzer?
Measure or estimate daily GB of logs, peak logs per second where possible, device and VDOM counts, analytics retention, archive retention, ADOM needs and expected growth. Also list required reports, integrations and optional services because they can influence the final design.
9. How can I request FortiAnalyzer pricing and UAE availability?
Send FourTeck the preferred deployment type, source inventory, expected GB/day, retention target, quantity, license term and any installation or configuration requirement. FourTeck can then help confirm the appropriate current SKU, quotation path and UAE availability.
Plan the FortiAnalyzer requirement before you buy
Share the log sources, daily volume, retention target and deployment preference with FourTeck. The team can help compare hardware, VM and cloud approaches, map licensing and optional services, and prepare a quotation around the actual environment. Current availability and lead time should be confirmed after the exact SKU and quantity are selected.