Understanding Sophos Next-Gen SIEM and planning retention

Sophos Next-Gen SIEM is an optional add-on for Sophos XDR Powered by Secureworks and Sophos MDR. The account must be upgraded to Sophos Fusion before use. The technical admin help describes 13 months of data retention as standard, with the option to extend it to up to 10 years. It also includes threat and compliance telemetry and custom integrations in addition to the ready-made XDR/MDR integrations. This assessment is current as of 28 October 2026; the product page’s different one-year figure is explained below in the procurement context.

Start by recording the data sources and retention periods you need. Then have the specific add-on scope confirmed for your tenant and use a small pilot source to check whether the intended events are actually ingested and can be found again. An existing XDR or MDR license alone does not prove that the optional add-on is enabled.

When Next-Gen SIEM fits the task

SIEM stands for Security Information and Event Management: event data is collected centrally and made available for analysis. Next-Gen SIEM extends the shared XDR/MDR data architecture for longer retention and compliance analysis. It is particularly worth considering when you need historical events over longer periods or want to ingest a source through a custom integration.

If the immediate task is to set up an existing product integration, start with MDR and XDR integrations in Sophos Fusion. That article explains their data flow and operational checks. Connecting Sophos Firewall to syslog covers transporting firewall logs to a receiver. It does not establish which Next-Gen SIEM scope has been purchased or enabled for a source.

The primary platform for detection, investigation, response, and automation remains Sophos XDR. Next-Gen SIEM adds compliance-oriented data collection, historical evidence, and longer retention to these workflows. The SIEM add-on is therefore not a blanket prerequisite for XDR detection or response functions already licensed; conversely, XDR alone does not enable the additional SIEM capabilities.

Avanet recommends choosing the add-on for more than just the longest possible retention period. Retention means keeping data. What matters is which events you will need later, which questions they should answer, who will analyze them, and how long they must remain available. Keeping data longer is of little help if the required event category is not supplied or important fields are missing.

Sophos also describes ready-made compliance dashboards. These analyses support evidence gathering, but do not replace checking data coverage, a legal assessment, or certification. The add-on does not automatically establish compliance.

Confirm the tenant and offer before implementation

Before purchasing, document the correct tenant, the XDR/MDR product in use, and the actual Fusion upgrade status. An announcement or a planned upgrade date is not sufficient clearance for operational use. Then ask the Sophos partner to confirm whether Next-Gen SIEM is available for that account and which retention and integration services the specific offer includes.

Sophos describes user- and server-based pricing without ingestion charges, meaning there is no charge based on the volume of data ingested. This describes the pricing model; it is not a quote or a promise of unlimited technical capacity. Before ordering, clarify the counting method, contract term, desired retention extension, integration scope, and any prerequisites of the third-party product. In particular, this description does not imply free third-party licenses or guaranteed throughput or event limits.

For custom integrations, the ability to create your own data integrations is confirmed. That does not establish a supported setup procedure for every source. Before the pilot, you therefore need a description suited to the specific source, covering transport, authentication, event format, field mapping, and supported analysis. Do not reuse existing connector menus or queries for a custom integration without checking them. The dashboard entry point is described below; it does not establish a universal setup procedure for every custom source.

Explicitly confirm the licence quantity and collector path

Next-Gen SIEM cannot be purchased as a standalone product. Its subscription count must match the total number of licensed XDR and MDR users and servers; servers must not be omitted from the count. Reconcile the actual inventory and offer with the partner rather than using only a pilot group or data volume as the licence quantity. In addition to the standard 13 months, retention extensions to three, five, seven or 10 years are purchasable options, not automatically enabled by an existing XDR/MDR licence. They do not retrospectively restore expired history or establish legal compliance.

The licensing guidelines effective October 16, 2026 also state a usage allowance of 1 GB of raw data ingestion per day, aggregated across all data sources. The table licenses by users and servers, but the data-volume sentence does not expressly say whether this allowance applies per subscription or per tenant. Therefore, neither calculate 1 GB × users and servers nor assume a fixed 1-GB tenant limit. Before sizing or ordering, obtain binding confirmation of the reference unit, aggregation, and behaviour when the allowance is exceeded. Pricing without volume-based ingestion fees does not mean unlimited usage.

The number of Retention Add-on subscriptions must also match the total number of NG-SIEM subscriptions. This does not establish extended retention for an arbitrarily selected subset or an individual source.

For Syslog integrations, old Sophos Log Collectors do not support the full retention scope of Next-Gen SIEM. Sophos therefore recommends moving to XDR Data Collectors; the existing collector migration runbook explains provisioning, deployment, source switchover and acceptance. Existing API integrations do not require reconfiguration solely because of this collector change. On a shared SVA, NDR remains a separate workload and must not be inadvertently shut down during the Syslog cutover. The new collector does not replace checking add-on entitlement, source format and effective retention.

The SIEM hub organises the existing guides around planning, source ingestion, transport and parser validation. The HTTP/parser practical example connects these steps with a synthetic lab source; practical acceptance in a tenant remains outstanding.

Custom data: separate transport, normalization, and detection

A Custom Integration transports data from a source not optimized by Sophos into XDR. This does not yet establish confirmed normalization, search, or detection for that source. Custom Parsers map log fields to the supported standardized XDR event schemas. Only then can you check whether the fields required for the intended search, a detector, or a Custom Detection Rule are available.

Custom Parsers require a Next-Gen SIEM subscription. Admin and Super Admin can manage them; other roles can only view the list of configured parsers. Messages that match no parser fall back to the generic schema. They can provide context for cases and custom rules, but appear in search results only when advanced search parameters are used. No results in a basic search therefore do not prove that no data has been ingested.

Even correctly normalized data does not automatically trigger every detector matching the schema. Sophos specifies certain supported detector paths with required fields; other detectors are not guaranteed. Validate the intended detection separately using suitable test events. The advertised AI assistance does not replace this check.

A newly created Custom Parser is turned off by default. Test it repeatedly with different sample messages, save it, and only then turn it on separately. Changes to an already active parser, however, take effect immediately when saved; test carefully before saving. Overlapping Confirm Strings can assign messages to the wrong parser, so the extractor path actually used must be checked too.

Sophos does not maintain or update Custom Parsers. A responsible operator must recheck field mapping, timestamps, and search or detection results after changes to the source format or parser. For the pilot, document ingestion, normalization, and the intended analysis as three separate outcomes; a green transport status is not enough.

Practical setup is covered by Custom HTTP Ingest, the S3 variants, Azure Event Hubs and Storage, and the custom parser runbook. For every variant, transport, schema, and the required analysis remain separate acceptance results.

Open the NG-SIEM dashboard to check evidence

With the add-on enabled, add the supplied view to your personal dashboard list as follows:

1. Open Dashboards > Manage dashboards.
2. Select Find dashboards and add NG-SIEM to the list.
3. Open the dashboard from the list and compare the displayed data with the source inventory, time range, and expected events.

The NG-SIEM dashboard contains widgets covering access control, network security, and audit events. Sophos also describes an ISO 27001 dashboard example that brings together authentication, changes, network/firewall events, email/file activity, and detection and case workflows. The information actually available for your evidence depends on the connected sources and their data quality; the view is not an ISO certification or automatic confirmation of compliance.

The general dashboard guide explains personal lists, available views, and PDF export. If NG-SIEM is missing, check the tenant, add-on, and permissions first; investigate an empty view against data provenance and time range. Neither missing nor green widgets replace checking the underlying events.

The current product-specific NG-SIEM help dated October 1, 2026 describes this entry point. The older shared dashboard help dated September 17 still mentions only the TAC dashboard. This is a documentation difference, not a guarantee about an unverified tenant view. If the entry is missing despite a matching offer, clarify the actual provisioning; do not create a second integration on suspicion.

Distinguish retention, search windows, and raw data

13 months in the admin help, one year on the product page

The technical overview dated 1 October 2026 specifies 13 months of standard retention. The public product page, by contrast, specifies one year, as reviewed on 28 October. Both name extensions to three, five, seven or ten years. This difference is not interpreted as a confirmed product change or merely different rounding; Sophos has not provided an unambiguous explanation.

The 13 months in the product-specific admin help are the reference for the technical explanation in this article. Before ordering or making a binding retention commitment, nevertheless obtain confirmation of the period that applies to the specific tenant, data types and quotation. Include that confirmation in the source inventory. If operations need more than twelve months of history, for example, do not assume the additional time solely from general product advertising. The retention inventory and acceptance procedure below check the agreed scope; they do not resolve the source conflict by assuming a period.

Search period and access to raw data

Long retention does not mean an arbitrarily large query can run in one go. The current schema help permits at most 31 days per query for normalized Events, with any start date within data actually retained. Split longer investigations into suitable windows. Searching detections is separate.

For @raw and original_data, the newer SQL-to-QL migration guide dated September 15, 2026 specifies a separate access limit of 20 days. Requests outside this scope are rejected, not silently shortened to the permitted range. The older query-language help also mentions 20-day increments; this does not establish guaranteed availability of older raw data. Splitting requests does not automatically make older raw data accessible. This search limit proves neither physical deletion after 20 days nor a general reduction in normalized-data retention.

Data Lake Search and exports explains schema selection, query limits, historical windows, and complete export evidence. The rule operations guide distinguishes a successful search from a continuously evaluated detection or suppression rule.

Create a retention inventory for each source

The inventory belongs in the operational documentation, not just in the offer. Record the following for each source; different event categories from the same application may need separate entries:

• Source system, source tenant, event categories, and responsible person.
• Purpose of ingestion and the specific future search or evidence question.
• Required fields, such as event time with time zone, action, result, and an identity suitable for the investigation.
• Data classification, permitted content, and approval for transmission and access.
• Desired retention with its justification, and the confirmed scope that actually applies.
• Integration method, required permissions, and credential owner, without copying secrets into the inventory.
• Ingestion start, expected processing delay, and a reproducible test event.
• Verified search method, oldest record found, last successful check, and next review date.
• Procedure for outages, source changes, retention changes, and decommissioning.

The product specification 13 months, extendable to up to 10 years must not automatically be recorded as the effective period for every existing record. Clarify the scope, start date, and access to historical data for your source. Do not assume that old data will be imported retrospectively or that already expired data can be recovered.

Example of a pilot source

The following example is a planning record, not a Sophos configuration or a verified connector. The values are freely chosen requirements of a fictional organization:

Source: internal business application, test environment
Events: successful login and administrative role change
Purpose: trace who changed a permission
Required fields: event time with time zone, test account, action, result
Desired retention: 24 months
Justification: internally approved investigation period
Confirmed scope: still to be clarified before ordering and the pilot
Connection and search method: still to be confirmed for this custom source
Test: approved role change on a dedicated test account
Rollback: restore the initial role and verify the change
Responsible teams: application team together with security operations

Here, 24 months is an internal requirement, not a general statutory period or a product default. It exceeds the standard retention described, so an appropriate extension must be confirmed before approval. Replace the accounts and events with your own approved test data. Do not change production permissions for this test.

Accept ingestion and retention separately

For the pilot, record the initial state and ingestion start. Keep existing logging paths in place until the new source has passed acceptance. Then generate a harmless, approved event belonging to the intended event category. In the example, the test account’s role is changed and then restored to the documented initial value.

After the expected processing time, use the search or analysis method confirmed for that source to check:

1. Is the exact test event present in the correct tenant?
2. Do the source system, event time, action, and result match the source evidence?
3. Are the required fields mapped intelligibly, rather than available only as unusable raw text?
4. Can further expected events be traced throughout the pilot period?

A newly found record proves ingestion for this test, not multi-year retention. For retention acceptance, also compare the confirmed scope with the effective setting or a tenant-specific confirmation. Check existing historical data using a targeted time window; record the oldest record found and any known gaps. For a new source without historical data, document that long-term retention has not yet been demonstrated by elapsed time, and schedule later checks.

The ingestion check does not require a security alert. An ordinary audit event may be needed as a record without creating an incident. Data Collection and Live Discover explains existing XDR queries; it does not provide a universal query for a new custom source.

Isolate faults and reverse changes safely

If the add-on or a feature is missing, first check the tenant, actual Fusion upgrade status, and confirmed add-on scope. Do not create a second integration speculatively or change an endpoint protection policy to resolve a suspected licensing gap.

If current events are missing, first compare the source evidence with the ingestion start, event category, authentication, format, and agreed processing delay. If records exist but are unusable, check field mapping and time handling. If only older events are missing, investigate ingestion start, data gaps, effective retention, and search time window separately. Extending retention later is not a guaranteed way to repair data that is already missing.

Before shortening retention or decommissioning, clarify with the responsible parties which data is still needed and how it can be preserved where supported and necessary. Do not assume that returning to the old value later will restore lost history. Likewise, removing an integration does not prove that already ingested data has been deleted.

If a pilot fails, reverse only the documented change to the pilot source, using its confirmed rollback procedure. Leave shared credentials, collectors, and other sources untouched. Then check the restored source state and the old logging path that is still needed. Data deletion and cancellation of the add-on must be clarified separately with the partner or responsible parties; this article promises no universal switch for either.

Operational handover requires the source inventory, confirmed scope, pilot evidence, outstanding historical gaps, outage responsibility, and review date. If the data format, search method, or retention for a required source remains unclear, that source has not yet passed acceptance. For escalation, initially provide the tenant mapping, time window, event category, and sanitized error evidence; do not include secrets or unnecessary raw personal data in the request.