Answering the Cyber Insurance SIEM and Logging Question

To answer the cyber insurance SIEM question, copy the exact wording, confirm that a central platform is collecting and correlating events today, count the critical assets actively sending logs, and check how long those logs stay retrievable. Those are separate facts. The forms checked here do not all ask the same things, and a product label, license or planned connector establishes none of them. No answer guarantees eligibility, pricing, coverage, renewal or a claim outcome.

This is a guide to answering an application, not a SIEM buying guide, and it ranks no vendors. It is not legal advice. If wording or scope is unclear, ask your broker or carrier in writing before signing.

What is the cyber insurance SIEM question actually asking?

On the forms checked for this guide, it asks for current facts about central log collection, not whether you own a security product. Together they illustrate three separate facts: whether a SIEM exists, what it covers and how long its logs remain available. Not every application asks all three.

At-Bay: use and percentage

At-Bay's Cyber Ransomware Supplemental Application, marked AB-CYB-RSA 06/2026 and copyright 2026, asks in Question 08:

Does the insured utilize a Security Information and Event Management solution (SIEM)? If Yes, what percentage of critical assets are being ingested into the solution?

The displayed choices are Yes, with the bands 90-100%, 75-90% and < 75%, and No. That is two current facts: whether a SIEM is used, and what percentage of critical assets is being ingested. The checked form has no log retention question. Its printed bands also share a boundary, so an exact 90% could fit two of them. Ask the broker or carrier how to record that value.

QBE: yes or no, plus an open percentage

QBE North America's The Solution for Cyber Risk Ransomware supplement, footer 830854 (3-25), copyright 2025 QBE Holdings, Inc., includes Question 7, Logging and Monitoring. It asks:

Does the applicant implement a Security Information and Event management (SIEM) tool to monitor activity logs and centralize tools?

It also asks whether the applicant monitors for unusual or suspicious network activity, whether EDR is deployed on all endpoints, and:

What percentage of the applicant’s most vital or critical assets are being logged and forwarded to a SIEM solution?

That is a yes or no SIEM question and an open percentage field. The form states no required percentage, and Question 7 does not ask for a log retention duration. EDR has its own line there, so keep it apart from your SIEM answer and see answering the EDR question.

AIG: why retention can be a separate question

AIG Australia's CyberEdge Ransomware Supplemental Questionnaire has a Security Monitoring and Incident Response section with two relevant questions:

• SMIR #4 asks what percentage of the applicant's "Vital Assets" are logged and forwarded to a SIEM. The bands are 0-30%, 31-50%, 51-70%, >= 71%, Don't know and Not applicable (no SIEM).
• SMIR #5 asks how long the SIEM retains logs. The bands are Less than 30 days, 30-59 days, 60-89 days, 90 days or more, Don't know and Not applicable (no SIEM).

A question is not a requirement. None of the questions quoted here states a minimum percentage, a minimum retention period or a need for round-the-clock monitoring, and none says how an answer affects underwriting.

What counts as a SIEM on an application?

A SIEM centrally collects events from multiple sources, normalizes and correlates them, supports searching and investigation, and generates detections or alerts. If your form defines the term, follow its definition.

The Canadian Centre for Cyber Security's guidance, ITSM.80.024, describes the same core: aggregating data from many sources, normalizing it, correlating events and issuing alerts. That is government security guidance written for large organizations and enterprises, not insurer wording. Common cases compare like this:

• A deployed SIEM with active connectors, central ingestion, search, correlation and alerting: a fair yes, limited to the coverage you verified.
• A managed SOC or MDR service: a fair yes only when the contracted service includes centralized, multi-source log collection and correlation, and you can verify which sources and retention are included. An endpoint-only MDR service is not automatically a SIEM.
• Microsoft Sentinel or a comparable platform: Microsoft describes Sentinel as a cloud-native SIEM, but that classifies the product, not your deployment. It is a fair yes when enabled and ingesting the sources you claim. Owning an eligible subscription or an Azure tenant is not enough.
• "Logs exist on every server": no. Local logs are not evidence of central ingestion, cross-source correlation, central alerting or resilient retention.
• A syslog collector or archive with no correlation or detection: describe it as centralized logging or log management unless its actual capabilities support your form's SIEM wording.

EDR does not equal SIEM. Endpoint telemetry can be one SIEM source, but endpoint-only collection does not prove central visibility across identity, email, firewall, VPN, backup and finance systems.

How do you work out the percentage honestly?

Define a repeatable denominator first, then count only the assets whose logs are arriving centrally now. Record the counting method and the date, because the percentage means little without them.

Build the inventory from your form's exact words and how the business actually runs. Include these where they apply:

• Domain controllers and identity providers, including the privileged identities behind your admin accounts answer
• Firewall and VPN infrastructure, matched against your remote access inventory
• Email, Microsoft 365 and relevant cloud audit sources
• Backup servers and backup management consoles
• Finance, payment, ERP and other business-critical systems
• Critical file, application, database and virtualization systems

For every asset or consistently defined asset group, record:

• Business owner and technical owner
• Why it is critical
• Which logs should exist
• Whether those logs arrive centrally now
• Latest successfully received event
• Searchable retention and archive retention
• Alerting and monitoring owner
• Exceptions or broken connectors

Do not count an installed agent, enabled local logging, a stale connector, a platform license or planned onboarding as current central ingestion.

Worked example: 5 of 7 is about 71%

This example is illustrative. A small company identifies seven critical assets using a documented, consistent counting method: two domain controllers, one firewall and VPN platform, Microsoft 365, one backup server, one finance application and one file server.

Both domain controllers, the firewall and VPN platform, Microsoft 365 and the file server are actively sending current events to the central platform. The backup server and the finance application retain only local logs. That is 5 of 7, or about 71%.

On At-Bay's checked 06/2026 bands, the current answer is < 75%, not 75% and not "all critical assets." The company can state the two exceptions and any future onboarding separately. The same arithmetic would land in AIG's >= 71% band, which shows why a band from one form should never be reused on another. Each form may also define the denominator differently, so answer from its exact wording.

How long do your logs actually stay available?

Find the oldest event you can retrieve today, and report searchable, archived and local retention separately. They are different capabilities.

• Searchable or hot retention: events can be queried in the SIEM immediately.
• Archived or cold retention: events still exist but may need restoration, rehydration, extra time or extra cost before investigation.
• Local device retention: logs remain only on the original system, where they may roll over, fail or be altered. Do not represent this as central retention.

A 7-, 14- or 30-day tier can leave investigators without the beginning of an incident discovered later. Do not assume every free tier uses the same duration. Verify the purchased plan, per-source settings, exclusions and oldest retrievable event.

If the current setup provides 14 searchable days and no archive, an honest answer looks like this, using your own dates (the ones shown are examples):

Central security logs are searchable for 14 days. We do not currently maintain a longer central archive. This was verified on March 12. Extending retention is planned for June 30 and is not represented as complete.

The Canadian Centre for Cyber Security recommends retaining important logs for at least six months and considering 13 months for more critical logs. It says the right period depends on industry standards, regulations, specific security concerns and storage costs, and it cites IBM's 2023 figure of a 204-day mean time to identify a breach. That is guidance, not a statement that At-Bay, QBE or AIG require those periods.

For Microsoft 365, read Microsoft's audit log retention documentation against your own tenant. Audit (Standard) records generated since October 17, 2023 default to 180 days. A one-year default policy covers Exchange Online, SharePoint, OneDrive and Microsoft Entra records, but only for users with E5 or qualifying add-on licensing, and custom policies take priority, including shorter ones. Inspect your licensing, record types, policies and oldest searchable event rather than quoting a duration. Microsoft 365 audit retention is also not SIEM retention unless those records are in the SIEM.

What can a small shop do with partial coverage?

Give the partial percentage and list the exceptions. A partial answer is more accurate than a full-coverage yes that your records cannot support, and planned work stays labeled as planned.

• Confirm Microsoft 365 and Purview audit is enabled, then determine the actual searchable window.
• Send firewall and VPN syslog to a central collector or SIEM and verify recent receipt.
• Use EDR telemetry as one source, without calling endpoint-only coverage a SIEM.
• Ask your MSP or MDR provider for the active source list, retention terms, alert and escalation procedure, and a recent sample alert.
• Prioritize identity, remote access, email, backup and finance sources before claiming broad coverage.
• When onboarding finance systems, collect security events rather than sensitive records. The Canadian guidance says to prevent a SIEM from collecting financial information, personal identifiers, passwords and keys.

What belongs in the evidence pack?

Keep a dated set of records that lets a reviewer trace each statement on the application to something you verified.

• Dated inventory of critical or vital assets and the counting method
• List of active log sources and connectors, with the latest received event for each
• Screenshot or export showing searchable retention, with archive retention and the restore procedure documented separately
• One redacted sample alert with source, event time, detection time, owner, disposition and escalation path
• Connector health or ingestion report
• MSP or MDR scope and retention evidence, if applicable
• Current exceptions, owners and target dates, visibly labeled as future work
• Exact application question, carrier, form, edition and evidence date

A 60-minute ransomware tabletop is a practical place to test whether an alert reaches its owner and whether the logs support a timeline.

Fill-in response template

Use one record per application question, and attach evidence separately.

• Exact question, carrier, form and edition:
• SIEM or logging service:
• Critical-asset denominator and counting method:
• Current centrally ingested numerator:
• Percentage and calculation method:
• Searchable retention:
• Archive retention:
• Monitoring owner and hours:
• Broken or excluded sources:
• Sample-alert date:
• Verification date and reviewer:
• Future improvements, owner and target date (not current state):

Sources

• At-Bay, Cyber Ransomware Supplemental Application, AB-CYB-RSA 06/2026
• QBE North America, The Solution for Cyber Risk Ransomware supplement, 830854 (3-25)
• AIG Australia, CyberEdge Ransomware Supplemental Questionnaire, SMIR #4 and SMIR #5
• Microsoft, What is Microsoft Sentinel SIEM?
• Microsoft Purview, Manage audit log retention policies
• Canadian Centre for Cyber Security, Using SIEM tools to manage cyber security risks, ITSM.80.024