Cyber insurance asset and logging questions: how to answer them

Key facts

• Insurers ask four questions here: asset inventory, secure configuration, centralised logging, and shared IT with affiliated companies.
• The asset inventory answer underpins the endpoint protection coverage question and the end of life technology question. Neither can be evidenced without it.
• Secure configuration is asked as one yes or no covering six or more sub-items, so every sub-item has to be true for the yes to be accurate.
• The logging question asks whether all logs are sent to a centralised logging server, which is a higher bar than logging being switched on locally.
• Without central logs, an insurer’s forensic investigator cannot establish when an intrusion began or what it reached, and the scope of an incident is what drives the size of a claim.
• Attacker dwell time is frequently measured in weeks or months, so log retention shorter than the dwell time answers the question on paper and not in an investigation.

Why insurers ask about this in so much detail

These four questions are about whether you know what you own and what happened on it. An underwriter reading this section is working out two things: whether the coverage percentages you claimed elsewhere on the form are provable, and whether, if something goes wrong, anyone will be able to reconstruct it.

The logging question carries the most commercial weight and gets the least attention. When a claim is assessed, an incident responder works backwards through logs to establish when the intrusion started, which accounts were used, and which systems were reached. If those logs only exist on the machines that were compromised, or they rolled over a fortnight ago, the investigation cannot narrow the scope. An unbounded scope means every affected individual is treated as potentially notified, every system as potentially accessed, and the claim is priced accordingly. Central logging is the control that turns “we do not know” into “we know exactly”, and the difference is measured in money.

The questions below come from Australian cyber insurance proposal forms current as at September 2026. No insurer is named, and where forms differ the stricter wording is used. The full set of 45 technical questions is on the cyber insurance questionnaire guide.

The asset and logging questions insurers ask

Do you maintain an inventory of all your hardware and software?

Australian proposal forms ask hardware and software as two separate answers. It looks like the easiest question in this area and it is the most load-bearing, because the endpoint protection coverage question and the end of life technology question both depend on it. A coverage figure of 100% means nothing if it is measured against a list of the devices you already know about.

What needs to be in place is an inventory generated live from a management platform, covering every device and every installed application, refreshed automatically. A spreadsheet somebody updates when they remember is not an inventory, because the entries that matter are the ones nobody remembered: the machine attached to a piece of equipment, the server that was never decommissioned, the laptop belonging to someone who left, the switch installed by a contractor years ago.

The evidence is an exported inventory with a generation date on it. Answer this question first and then revisit the endpoint coverage and end of life answers, because the inventory usually changes both. That reordering is worth doing before the form goes back rather than after.

Have you implemented secure configurations to all hardware and software assets?

Proposal forms ask this as a single yes or no, then list the sub-items behind it: changing or disabling default accounts and passwords, disabling or removing unneeded services and features, applying vendor-specific security recommendations, enforcing encryption of local storage, enabling appropriate backups, and configuring logging of system logons, activity, warnings and errors.

What satisfies it is a documented build standard applied at deployment rather than configured by hand each time, plus something that detects drift afterwards. The two sub-items most often missed are default credentials on network equipment, printers and cameras, which are rarely part of anyone’s build process, and unneeded services left enabled because nobody wanted to test what breaks by turning them off.

The evidence is the build standard document plus a compliance report showing devices measured against it. Because this is one answer covering many things, work through the sub-items individually before ticking yes. Several of them overlap with user application hardening and macro settings in the Australian Signals Directorate Essential Eight, so a business working through that framework has already done part of this.

Are all logs sent to a centralised logging server?

Longer proposal forms ask this as a sub-item alongside whether assets are onboarded to endpoint detection and response or a security information and event management platform. It is the question in this area most Australian small businesses answer no to, and the one where no has the largest consequence.

What satisfies it is log forwarding from endpoints, servers, the firewall and the identity provider into a central store that is retained for a stated period and that an attacker who compromises a server cannot reach in order to delete the evidence. That last part matters as much as the collection: logs held only on the compromised machine are logs the intruder can edit.

Retention is where the answer is usually too optimistic. Intruders commonly spend weeks or months inside a network before doing anything visible, so a 30 day window can mean the beginning of the incident has already aged out by the time anyone notices. Size the retention to the question you would need to answer during a claim, which is when did this start, rather than to the cheapest option.

The evidence is the log source list, the retention setting, and something showing the central store is separately credentialed from production. This is also the question with a real cost attached, which is why it goes unanswered so often, and it is covered below.

Is any affiliated company’s IT fully separate and independent from yours?

Proposal forms ask this where you have listed affiliated companies, followed by a free text field asking you to describe any shared IT. It applies to a great many Australian businesses: group structures, family businesses operating two trading entities, franchisees sharing systems with a franchisor, and any arrangement where one office manager administers two companies.

What the insurer is assessing is whether one compromise reaches both entities. Genuine separation means separate tenants, separate directories, separate networks and separate credentials. Anything less is shared IT, including the common arrangement of two companies in one tenant with a shared file server, and including a single administrator account used across both.

The evidence is a tenant and directory listing plus a topology diagram covering both entities. Where IT is shared, describe it accurately in the free text rather than answering yes to separation. Shared IT is not a decline. An inaccurate claim of separation, discovered when an incident crosses between entities, is a disclosure problem, and those are treated very differently from a technical shortcoming.

The centralised logging problem, and what we do about it

Central logging is the one control in this area that most small and medium businesses simply do not have, because it has historically been priced for enterprises. A platform sold per gigabyte of ingested data becomes unpredictable the moment you start forwarding firewall logs, and businesses either turn sources off to control cost or never start.

4iT builds and manages centralised logging for clients using Wazuh, deployed as a dedicated virtual machine for each client on our own infrastructure. A dedicated instance rather than a shared one is deliberate: these logs are what a forensic investigator works from during a claim, and separated client data avoids any question about whose events are whose.

What can be included:

• Log collection from Windows and Linux servers, workstations, firewalls, network equipment and your identity provider.
• File integrity monitoring, so changes to critical files and configurations are recorded.
• Detection rules mapped to known attacker techniques, with alerting into your existing support process.
• Vulnerability detection across the endpoints already reporting in, which also feeds the scanning question elsewhere on the form.
• Configuration assessment against recognised hardening benchmarks, which supports the secure configuration answer above.
• Retention sized to your requirement rather than to a default, including retention long enough to cover realistic dwell time.
• Reporting you can hand to a broker or an underwriter as evidence, rather than a screenshot of a dashboard.

It is quoted on requirements rather than sold as a fixed package. The variables that move the price are how many devices report in, which log sources you want, how long the data is kept and whether you want alerting handled as a managed service. Scoping it properly means you are not paying for capability you will not use, which is the usual complaint about logging platforms sold by the seat.

The evidence to assemble before the form arrives

• An exported hardware and software inventory with a generation date.
• Your documented build standard, plus a compliance report measuring devices against it.
• A default credential check across network equipment, printers and cameras.
• The log source list, showing what forwards to the central store.
• The log retention setting, stated in days.
• A tenant, directory and network diagram covering any affiliated entities.

The secure configuration sub-items overlap with several strategies in the Essential Eight, and the Essential Eight guide for Australian SMEs sets out how they fit together. Broader guidance on event logging and monitoring is published by the Australian Cyber Security Centre at cyber.gov.au.

One thing not to do

Do not answer yes to the central logging question because logging is enabled on your servers. The question asks whether logs are sent to a centralised logging server, and local event logs are neither centralised nor beyond the reach of somebody who has taken over the machine. If the honest answer is no, answer no. A no on this question with a yes on inventory, configuration and endpoint coverage is a perfectly respectable submission, and it is a great deal better than a yes that collapses the first time an investigator asks for six months of authentication events.

If a questionnaire has landed and the logging question is the one you cannot answer, 4iT scopes centralised logging against your actual environment and quotes it on what you need, so you are not paying for capability you will not use. We also work through the rest of the form and produce the evidence pack the underwriter will ask for. Request a callback and we will work out where you stand.