Why the proposal form is harder to answer than it looks
A cyber proposal form asks about security controls in a shape that admits only yes or no. Behind every tick is a technical claim about scope, enforcement and coverage across an environment where none of those three is uniform. The accurate answer to whether you enforce multi-factor authentication has three clauses in it: on these identities, by this mechanism, with these exclusions.
The form does two jobs at once and the second one is easy to miss. It is underwriting input, so the answers drive the terms and whether a quote appears at all, and it is also a disclosure document. A business cyber policy is not a consumer insurance contract, so it still sits under the duty of disclosure in section 21 of the Insurance Contracts Act 1984 (Cth), not the duty to take reasonable care not to make a misrepresentation that replaced section 21 for consumer contracts entered into from 5 October 2021. Where a non-fraudulent failure to disclose or a misrepresentation is established, section 28 gives the insurer a proportionate remedy: liability on the claim is reduced to the amount that would put the insurer in the position it would have been in had the failure not occurred. What a particular wording does with any of this is a question for your broker, and this note stays on the control questions and the evidence behind them.
The duty runs again at each renewal, and that is where an accurate declaration quietly turns into an inaccurate one. A control that was true when you first answered can regress across a year without anyone deciding to let it happen: an exclusion group gains a member during a migration, a rebuilt server is never re-onboarded to the endpoint console, a retention lock is loosened for a storage move and left open. At proposal time your answer is a sentence typed into a web form, and after a loss the same claim is tested against records the systems wrote at the time.
What are the cyber insurance requirements in Australia?
No Australian law requires a business to carry cyber insurance, and no regulator publishes a control list that insurers must underwrite against. What people mean by cyber insurance requirements in Australia is the set of controls the market has converged on as a condition of quoting, and increasingly as a condition of quoting at a premium a smaller business will accept. Contracts push in the same direction from the other side, since tenders, supply agreements and franchise arrangements often name a cover amount and leave you to satisfy whatever the insurer asks for. The control set itself is short, stable and driven by claims experience, so it varies little between one proposal form and the next.
If you have done Essential Eight work, most of it will look familiar. Both exercises aim at the same losses, so they converge on the same controls, and patching, administrative privilege, multi-factor authentication and backups appear on both sides. What changes is what happens after the answer. An Essential Eight assessment measures maturity against a published model and produces a finding you own and can schedule work against at your own pace. A proposal answer becomes a statement made to a counterparty with an economic interest in testing it, examined later by a forensic provider working during an active incident.
That difference decides where the preparation time goes. A control you plainly lack is a disclosure problem you can describe and an underwriter can price. The costly questions are the ones where the control exists, the answer feels obviously yes, and the scope has a hole in it nobody has gone looking for. The recurring set is short enough to walk line by line.
- Multi-factor authentication on email, on remote access and on privileged accounts, with the scope of each one stated in the answer.
- Endpoint detection and response across workstations and servers, counted by devices reporting in, which is usually fewer than the licences bought.
- Backups that cannot be deleted or shortened by a compromised administrator, plus a restore performed recently enough to mean something.
- A patching regime with a shorter clock for internet-facing systems, evidenced by install dates on the devices themselves.
- Administrative privilege restricted, time-bound where the platform allows it, and reviewed on a schedule someone owns.
- Email filtering, staff training and phishing simulation, reported as completion and click rates across successive campaigns.
- An incident response plan with a version date, an exercise behind it, and contact details that work outside business hours.
- Supported operating systems and software, with any end-of-life exception identified, segmented and named.
What each proposal question is really testing
A question phrased as though it asks whether a technology exists is almost always asking about scope and enforcement, and claims experience is what put it in that shape. The table below sets each recurring question against the control it is testing and the evidence that still holds months later, when the same question is asked by someone with a different incentive. Most of that evidence is produced by a system as a by-product of running it.
The distinction matters when the two sources disagree. A spreadsheet of devices records what someone believed the inventory to be, while an export from the console that manages those devices records what the console can currently see. They disagree in almost every environment, and the size of the disagreement is your real coverage gap.
| Proposal question | What it is testing | Evidence that answers it |
|---|---|---|
| Do you enforce multi-factor authentication on email and remote access? | Whether every authentication path into mail and remote access is covered, including protocols that never present a prompt | The exported access policy with its named exclusions, plus a sign-in log query returning no successful single-factor interactive sign-ins over a defined period |
| Is multi-factor authentication enforced on all privileged accounts? | Whether administrative roles are covered separately from staff, and whether emergency exclusions are bounded and monitored | Role assignment export with the authentication state of each account, plus the alert rule that fires when an emergency access account signs in |
| Is endpoint detection and response deployed across the environment? | Whether the agent is installed and reporting everywhere it should be, with servers the usual gap | Console export of onboarded devices reporting in the last week, compared against the asset inventory, with unmanaged and passive-mode devices named |
| Are backups immutable or held offline? | Whether an administrator, or malware holding administrative credentials, can delete the copy or shorten its retention | The retention policy showing it is locked, the identity separation between production and backup, and the record of the most recent restore test |
| How often do you patch? | Measured time from vendor release to installed, especially on internet-facing systems | A patch compliance report showing install dates by device, taken from the update management tooling |
| Do you restrict administrative privileges? | Whether privilege is held continuously or requested for a window, and whether anyone reviews the list | Role assignment export split into permanent and eligible, with the dated record of the last access review |
| Do you have an incident response plan? | Whether it has been exercised, and whether the people named in it can be reached outside business hours | The plan carrying a version date, notes from the most recent exercise, and a contact tree with out-of-hours numbers |
| Do you run unsupported operating systems or software? | Which end-of-life systems remain reachable, and whether anything separates them from everything else | Asset inventory filtered by build and support status, with the network position and compensating control for each exception |
| Do third parties have access to your systems? | Whether an external party holds standing administrative access that sits outside your own controls | The delegated or partner relationships in your directory, the roles and expiry attached to each, and the access policy that applies to those sign-ins |
| Do you train staff and run phishing simulations? | Completion and click rates over time, and what happens to a repeat clicker | Campaign reports by period showing completion and click rate, and the documented consequence path for repeated failures |
Ten recurring proposal questions, the control each one is testing, and the evidence that holds up later
The multi-factor answer is the one most often wrong
Multi-factor coverage is a property of each identity and each authentication path, and the paths outnumber the identities by a wide margin. A policy that requires a second factor for interactive sign-in to a web application does not govern a protocol that never presents an interactive prompt, and it does not govern an identity the policy excludes. Both of those exist in most environments, and neither is visible from the admin summary screen that reports multi-factor as on.
The second half of the problem is which plane enforces it. A single tenant can carry legacy per-user settings, a set of conditional access policies and a security defaults switch, and those planes do not always agree with each other. Policies left in report-only mode look complete on the policy list and enforce nothing at all. A policy that excludes a location, a device platform or a group has a bounded scope its name rarely mentions. The reliable test is empirical: query the sign-in logs for successful interactive sign-ins over the last thirty days where no second factor was satisfied, then account for every result that comes back. That query answers the proposal question better than a screenshot of a policy screen, because it reports what the system actually did with each sign-in.
The answer that belongs on the form carries its scope with it. Something of this shape: multi-factor is required by conditional access for all interactive sign-ins by licensed users, three accounts are excluded and named, two of those are emergency access accounts whose sign-ins raise an alert, and legacy application authentication is disabled across the tenant with two mailbox exceptions restricted by source address. It takes a paragraph where the form wanted a tick, and it is the version a forensic timeline will confirm. Before writing it, walk the authentication paths that escape a confident yes, because they are consistent enough to check by name.
- Exclusion groups created for a migration or a broken connector, still populated years later because nobody owned removing the membership.
- Service accounts and shared mailboxes with interactive sign-in still enabled, holding permissions a person would need approval to hold.
- Application authentication to mail, where a protocol such as SMTP AUTH remains enabled on individual mailboxes for a scanner, a monitoring alert or a line-of-business application.
- Remote access appliances that authenticate against directory credentials directly instead of federating to the identity provider, so the appliance never applies the policy the rest of the estate runs under.
- External administrators, including a managed service provider holding delegated access, whose sign-ins arrive through a relationship your own policies may not scope.
- Guest identities and consented applications holding directory roles or permissions granted for a project that finished.
Do insurers require immutable backups, endpoint detection and a patch window?
Backup questions look like they are asking whether backups exist. They are asking whether someone holding administrative credentials in your production environment can destroy the recovery path. Immutability is the specific property being tested: for the retention period, the copy cannot be deleted and its retention cannot be shortened by anyone, including the administrator who configured it. The detail that catches people is that a time-based retention policy can often be configured in an unlocked state, where it looks identical in the console and stays editable, and only locking it makes the storage genuinely write-once.
The second backup question is identity. If the backup console authenticates against the same directory that runs production, and a domain or global administrator can reach it, the backup sits inside the blast radius of the compromise you are insuring against. Separate credentials, a separate authentication path, soft delete on the vault and a second approver on destructive operations are what make the answer defensible. Retention policies and legal hold inside a productivity suite preserve items against user deletion and are worth having, but they do not give you a restore path for a tenant-level event.
Endpoint detection questions usually get answered from the licence count. The number that matters is onboarded devices reporting within the last week, divided by the assets that should carry the agent. Most organisations cannot produce the denominator, and that gap is itself the finding. The recurring gaps are servers, which frequently sit on a distinct plan nobody purchased, devices onboarded once and no longer reporting, agents running in passive mode because another product owns real-time protection, and tamper protection left off, which leaves the agent as a service an intruder disables early.
The patch question asks about cadence and the loss asks about latency. Cadence is a configured setting, while latency is the measured interval between a vendor releasing a fix and that fix reaching the last device that needed it, and the honest way to report latency is a percentile, because an average hides the tail that gets exploited. A deferral ring set to seven days does not mean the fleet is patched in seven days, since a machine that is switched off, or waiting for a restart nobody performs, is not patched. The Essential Eight Maturity Model gives you a defensible clock to answer against: patches for internet-facing services applied within two weeks of release, and within 48 hours where an exploit exists. The systems most likely to need the shorter clock, edge appliances and remote access gateways, are usually the ones sitting outside the patch tooling entirely, because the tooling manages endpoints and these are appliances.
Privileged access is the control most often held standing
The privileged access question is asking whether administrative rights are held continuously or requested when they are needed. Standing privilege makes a credential valuable every hour of every day, which is what makes stealing it worth an attacker's effort. Time-bound privilege, where an account is eligible for a role and activates it for a defined window with approval, changes the economics of the theft and produces an audit record of every legitimate use as a side effect. That record is also the evidence for this proposal question, which is a rare case where the control and its proof are the same artefact.
The exercise starts with a count most organisations have never done. Export the directory role assignments and split them into permanent and eligible. Count the accounts holding the highest directory role, then count again including accounts that can reach it indirectly: through group membership, through an application permission that allows role assignment, or through the elevation path that lets a directory administrator take ownership of cloud subscriptions. Look at subscription and management group scope separately, because owner rights inherited from a parent scope do not appear where people look for them.
Two changes move this answer materially and most organisations can make both in a fortnight. Reduce permanent assignments of the highest roles to a number small enough to name the holders, make everything else eligible with activation logged, then run one access review and keep the record of it. The question behind the question is whether anyone owns the list, and a dated review with names against it answers that in a way no policy statement does.
Where do the gaps sit in a Microsoft and Azure estate?
The gaps below surface repeatedly the first time someone checks a yes against the system. None of them require a tool you do not already have. They require looking where the system keeps the record, which in every one of these controls is a different place from where the intention was written down.
Work down the third column with an admin session open and a note file beside it. Every line resolves either to a configuration you can change this week or to an exposure you will need to describe honestly, and sorting them into those two piles is most of the exercise. Do the log retention row first, because it decides whether the other nine can still be evidenced for the period that matters.
| Control | The gap that is usually there | Where to look |
|---|---|---|
| Multi-factor authentication | Exclusion groups created for a migration that still carry members, and service identities left outside policy scope | Access policy assignments and exclusions, then sign-in logs filtered to successful single-factor interactive sign-ins |
| Legacy and application authentication | SMTP AUTH left enabled on individual mailboxes for a scanner or a line-of-business application | The per-mailbox SMTP AUTH setting against the tenant default, plus sign-in logs for non-interactive and legacy clients |
| Third-party administrative access | A managed service provider or contractor holding delegated administrative access your own policies never scoped | Partner relationships and delegated roles in the directory, guests holding directory roles, and the expiry on each |
| Application and workload identities | Consented applications and service principals holding permissions no sign-in policy touches | Enterprise application consent grants, credentials registered against each service principal, and the owner named on each |
| Backup immutability | A retention policy an administrator can still shorten, because it was configured and never locked | The lock state of the retention policy on the backup storage, the delete protections on the vault, and who holds the role that can change them |
| Backup identity separation | The backup console authenticating against the same directory that runs production | The sign-in path for the backup administrator, and whether it shares a directory, a device or a password manager with production |
| Endpoint detection coverage | Licences assigned but devices never onboarded, and servers on a separate plan nobody bought | Onboarding state per device in the endpoint console, compared against the asset inventory, since user count is the wrong denominator |
| Patch latency | Deferral settings read as compliance while devices sit pending a restart | Update compliance reporting with install dates by device, and the separate patch state of edge appliances outside the tooling |
| Standing privilege | Permanent role assignments that were meant to be temporary, and owner rights inherited from a parent scope | Directory role assignments split into permanent and eligible, plus role assignments at subscription and management group scope |
| Log retention | Sign-in and audit retention shorter than the time it takes to notice an intrusion | The retention period on directory sign-in logs and the unified audit log, and whether a copy is exported anywhere durable |
Ten controls, the gap usually present when the answer was yes, and where to check it
How do you evidence a control instead of asserting it?
Evidence comes in three grades, and underwriters, auditors and forensic providers rank them the same way. An assertion is a person stating that the control is in place. An artefact is a system-generated record showing the configuration, dated and scoped. A test result is a record of the control being exercised and behaving as claimed. Each grade costs more to produce than the one before it and is worth more when someone examines it.
Two habits make evidence usable. Date and scope every artefact at the moment you produce it, because an undated export proves nothing about the period the policy is supposed to cover. Keep the artefacts together as one pack. The same set answers the insurance proposal, the customer security questionnaire and the tender response, and the second and third uses take a fraction of the effort of the first.
The signature is its own problem. The controls sit with an internal team or an external provider, the form sits with finance or the practice manager, and the person signing the declaration often has no way to verify what they are signing. The fix is organisational: whoever signs receives the artefacts themselves, keeps them with the policy documents, and reruns the same queries at the next renewal. Against multi-factor authentication, the three grades look like this.
- Assertion: the IT provider confirms that multi-factor authentication is enabled for all staff.
- Artefact: the exported access policy showing assignment, conditions, grant controls and named exclusions, with the export date recorded on it.
- Test result: a sign-in log query over a defined period returning no successful single-factor interactive sign-ins, alongside a deliberate sign-in attempt from an unmanaged device that was blocked, with the log entry for the block.
What the insurer's forensic firm looks at after a loss
When a claim is notified, the insurer commonly appoints its own incident response and forensic provider, often from a panel it maintains. That team carries two briefs at once: help contain the incident, and establish what happened. The same evidence serves both, which is why a forensic engagement reaches straight for the records that also test your proposal answers. Your own clock keeps running underneath all of it, because the Notifiable Data Breaches scheme in the Privacy Act 1988 (Cth) requires a reasonable and expeditious assessment of a suspected eligible data breach within thirty days, and notification as soon as practicable once you form the belief that one has occurred. Those two timelines are not the same, and the statutory one does not pause while a forensic investigation is still forming a view.
The artefacts the forensic team pulls are predictable: sign-in and audit records for the compromised identity, multi-factor registration events and their dates, the access policy set and its change history, the endpoint timeline for the first affected host including the date its agent was onboarded, mailbox rule creation events, application consent grants, the backup catalogue with job and deletion history, and the patch state of the exploited system at the moment it was exploited. Nobody goes looking for your declaration specifically; the investigation produces the material that bears on it as a by-product of being done properly.
Each of those records carries a date written before anyone knew it would matter, which is what turns a declaration into something testable. If the form said multi-factor authentication was enforced across remote access in March, and the registration record for the account used in the intrusion is dated the week after the incident, there is nothing left to interpret. The same holds for an endpoint agent onboarded onto the compromised server the day after containment began, or a backup retention policy that was locked in the middle of the response. None of that requires anyone to allege bad faith, and the conversation about the claim changes shape regardless.
The trap runs in the other direction too, and organisations rarely plan for that one. The records that would prove your control was working have their own retention window, and on the free directory tier that window is seven days for sign-in and audit logs, extending to thirty days on the paid identity tiers. If the intrusion began weeks before anyone noticed, and that is the usual pattern, the records covering the period you need to account for have already rolled off, and the party who made the statement is the party who needed them. Exporting identity and audit logs to durable storage is a small piece of configuration, and it protects you in the direction people never plan for, which is proving that what you told the insurer was true.
What to fix before you answer, and what to disclose
Sort every gap into one of two piles. The first pile is what you can close before the form goes back, and it is larger than most teams expect. Emptying a stale exclusion group, disabling legacy application authentication on the mailboxes that no longer need it, locking a backup retention policy, onboarding the servers that were licensed but never enrolled, converting permanent administrative assignments into eligible ones, and extending log retention are all changes measured in hours of work, each leaving a clear before and after record you can point at.
The second pile is what you cannot honestly fix in a fortnight: an end-of-life system carrying a business process, a flat network, an application that requires an authentication method you would rather not permit, an external provider whose standing access is written into a contract you cannot vary this quarter. Disclose those, describe the compensating control that genuinely exists around each, and attach a remediation date you intend to meet. Underwriters price known exposure every day, and a described weakness with a date against it is easier to quote than an unexplained gap. A yes that turns out to be wrong removes that option and leaves the same fact to be argued about during a claim.
Answer at the scope you can evidence, and put the qualifier in the answer instead of the covering email. If the form leaves no room, attach the scope as an annexure and reference it from the answer itself. The version of your control set that gets tested later is the one that was written down and returned.
The work behind a defensible answer is mostly measurement: what the policies say, what the logs show, what the environment looks like from outside, and where the evidence for each claim is going to come from. That is the standard we hold ourselves to on our own systems, and it comes from building software where the record has to survive examination. The operations and compliance portal we built and run for GRM LAW keeps an append-only audit ledger, and the staff portal we built for Stone Leaf Capital captures actor, action and before and after state on every change. Essential Eight assessment work covers most of the insurance question set against a published measuring stick, attack surface monitoring gives you the outside-in view an underwriter forms before reading a word of your form, and a vCISO engagement puts an owner on the declaration who can produce the pack. All of it starts with checking each yes against the system that would have to defend it.