An insurer can check what you told them in three places. They can read what your business publishes to the internet, they ask you to evidence the controls you declared, and later they read that record back from whatever was written down at the time. inSUPPORT has run more than 1,500 cyber audits for Australian businesses, and a renewal questionnaire is nearly always asking a factual question. Facts are checkable. That is the point.
Plenty of people answer honestly and still come unstuck. You tick yes to the question about email protection, because somebody set up the mail records when the domain was new. Those records are public. Anyone can look them up with a free online tool and read what your domain actually tells a receiving mail system to do, and that may no longer match the answer on the form. The setup was right once, and nobody has read it since.
Accuracy matters here for a legal reason. The Insurance Contracts Act 1984 puts a duty of disclosure on the insured. It also makes the insurer spell that duty out in writing first. Each answer on the form becomes the record of what you said on the day you said it.
Below are the three routes in the order an insurer meets them, and what each one can and cannot establish, with what an underwriter weighs in the first place set out in the five factors behind the questionnaire.
TL;DR: What the other side can actually check
- ✅ Three routes, not one. Insurers can verify security controls from the outside view of your business, from the evidence you hand over, and from the record read back afterwards.
- ✅ The duty is statutory. Section 21 of the Insurance Contracts Act 1984 puts disclosure on the insured, and the Act makes the insurer spell it out in writing first.
- ✅ An outside look can contradict an answer. It cannot confirm the ones that matter most, so the inside evidence is yours to produce.
- ✅ A control you cannot evidence reads like a control you do not have. Dated artefacts beat recollection.
- ✅ A blank is treated differently from a wrong answer. Where a proposal-form question goes unanswered, or the answer is obviously incomplete or irrelevant, the insurer is deemed to have waived the duty on that matter.
Contents
- The form is a declaration, not a survey
- What they can see before you answer anything
- The record gets read back, long after the quote
- Straight answers on who checks what
The form is a declaration, not a survey
Start with what the document is. It changes how you read every question on it. Under section 21 of the Insurance Contracts Act 1984, an insured has a duty to disclose. That duty covers every matter known to you that you know to be relevant to the insurer's decision whether to accept the risk and on what terms. It also covers what a reasonable person could be expected to know is relevant.
That Division of the Act applies to contracts which are not consumer insurance contracts. The Act then requires the insurer to inform you of the duty, clearly and in writing, before the contract is entered into. The warning in the proposal pack is statutory. Nobody added it for comfort.
Two details are worth holding onto. The duty is wider than the form. It reaches what you know to be relevant, not only what you were asked. A blank is also treated differently from a wrong answer. Where a person fails to answer a proposal-form question, or gives an obviously incomplete or irrelevant answer, the insurer is deemed to have waived the duty on that matter.
For an operator the practical reading is simple: your answers are an act with legal weight, and that is why the other side builds checks around them.
What they can see before you answer anything
Some of your environment is published by design, and anyone can read it. Mail authentication is the clearest case. Microsoft's own documentation describes the Sender Policy Framework as a TXT record in DNS. Receiving mail systems look it up to decide whether a message came from an authorised source for your domain. The same documentation notes that free online tools will show you that record and the rest of your DNS, and those tools are open to whoever is pricing your risk.
So an external look establishes real facts without your involvement. Which services you have exposed to the internet. Whether mail authentication is published, and what it tells a receiver to do with a message that fails. What names and certificates exist in your organisation's name, including domains nobody uses. An answer that contradicts any of that is cheap to catch.
Then it stops. Verifying a security control from outside has a hard limit. An outside view cannot tell anyone whether multi-factor authentication is enforced everywhere rather than merely available. It cannot say who holds administrative rights, whether a restore has ever been tested, or whether your backups would survive the incident that took everything else.
Those are the heaviest questions on the form, and they can only be evidenced from inside. The habit of looking is rarer than it should be. In the self-assessment survey behind the Australian Securities and Investments Commission's Report 776, 45 per cent of small organisations said they do not perform vulnerability scans.
- Look up your own public DNS records, mail authentication included, and read them the way a stranger would.
- List what is actually reachable from the internet, then check that list against what you believe is reachable.
- Account for registered domains you no longer use, because they are still in your name.
- Fix anything an outsider can see before you describe it on a form.
The record gets read back, long after the quote
The duty attaches before the contract is entered into. So the question that survives is what was true the day you answered. Memory does not hold that shape for twelve months. Environments drift. Exceptions get granted and forgotten, a device comes back unmanaged, an account nobody closed stays open. A control effective in March can be ineffective by September without anyone deciding anything.
Which is why the artefact matters more than the confidence. The Australian Signals Directorate's assessment process guide tells assessors to gather the highest quality evidence reasonably practicable. It says plainly that assessments done through interviews, reports and screenshots will always be inferior to assessments done with scripts and tools. The same scale is set out in why a checklist is not an assessment. Anyone verifying your controls later works from what the system can still show, not from what anybody remembers.
So keep the artefact beside the answer: its date, its scope, who checked it. inSUPPORT's part is the technical half, maintaining the agreed controls and evidencing them, which is what The 6 Step Cyber Strength System is built around.
Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment. Questions about wording, eligibility or whether a policy responds belong with those licensed parties. What an IT provider can tell you is narrower. A control you cannot evidence is, to the person assessing it, a control you do not have.
What each record gets read against
The records themselves are set out in what a cyber insurer wants to see. Whoever reads them later is checking each one against something else.
- A configuration export is read against the answer it supports: the same control, the same scope, and a date close to the day the form was signed.
- A restore record is read for what actually came back. A backup job reporting success is a different record, and it answers a different question.
- The list of administrative accounts is read against what you declared about who holds those rights, and against the date somebody last reviewed it.
- Anything visible from outside is read against your public record: the services reachable from the internet and the mail authentication your DNS publishes. That comparison needs nothing from you.
Straight answers on who checks what
Can an insurer check our security without asking us?
Partly, and that part is free to them. The externally visible pieces of your environment, such as the services you expose to the internet and the DNS records that carry your mail authentication, are published and can be looked up by anyone. What an outside look cannot establish is the inside position: whether multi-factor authentication is enforced everywhere, who holds administrative rights, whether a restore has been tested. That is why the questionnaire exists at all, and why the evidence behind those answers has to come from you. The useful habit is to look at your own outside view before anyone else does, because it is the same view and it costs nothing. Anything a stranger can see is worth fixing before you describe it.
Can our IT provider answer the questionnaire for us?
A provider can establish what is actually running and produce the evidence for it, which is the factual half of the work and usually the half that holds people up. The answers and the declaration stay the business's own, because the duty of disclosure under the Insurance Contracts Act 1984 sits with the insured. Anything about policy wording, eligibility or how a question should be interpreted belongs with the licensed party arranging the cover and with the insurer. Which part of the Act governs your particular contract is their question too.
How long does it take to get the evidence together?
Gathering evidence is faster than fixing what it exposes, and the two should not be confused when a renewal date is close. Remediation is the longer piece, and how long it runs depends on what the evidence turns up, so treat any number you are given as a scope question rather than a promise, and get it in writing alongside what it covers. Start before your notice deadline rather than before the renewal date, because they are rarely the same day. One more thing worth planning for: evidence has a shelf life. A configuration export taken in March describes March, so the useful version is the one dated close to the answer you are about to give.
What is the first step if we cannot evidence our answers?
Get the current position documented control by control, so the form is filled in from records rather than recollection. That means naming what is in scope, what is actually configured, who checked it and when. A Cyber Strength Audit does exactly that for Australian businesses of roughly 30 to 300 users, and returns a plain-English risk picture ranked by business impact with a costed path to closing each gap. What you do with it after that is your call.
If a questionnaire is sitting on your desk and you are not certain which answers would survive being asked twice, that is a factual question with a checkable answer. A Cyber Strength Audit documents the current position control by control, across identity and access, patching, backup and recovery, email and endpoint, and configuration drift, and gives you the artefacts to put beside each answer. You get the findings either way.
Book a Cyber Strength Audit →Citations
- "Insurance Contracts Act 1984 (Cth), Compilation No. 33, 8 October 2026", The source for the duty of disclosure in section 21, the deemed waiver where a proposal-form question is unanswered or answered obviously incompletely, the section 22 requirement that the insurer inform the insured of that duty in writing beforehand, and section 20E, which applies that Division to contracts that are not consumer insurance contracts. The endnotes record sections 21A and 21B as repealed by Act No. 135 of 2020. Compilation No. 33 was the latest compilation when checked on 21 October 2026. legislation.gov.au
- "Spotlight on cyber: Findings and insights from the cyber pulse survey 2023, Report 776", The Australian Securities and Investments Commission's own account of the survey, which was anonymous and voluntary and asked participants to rate their own capability, with about 30,000 regulated entities invited. The source for the finding that 45 per cent of small organisations do not perform vulnerability scans. Published November 2023. download.asic.gov.au
- "Set up SPF to identify valid email sources for your Microsoft 365 domain", Microsoft's documentation for the Sender Policy Framework, and the source for SPF being a TXT record in DNS that destination email systems check, and for the note that free online tools will display your SPF TXT record and your other DNS records. Updated 3 July 2026. learn.microsoft.com
- "Essential Eight Assessment Process Guide, Australian Signals Directorate", ASD's guide for assessors, as published by the Western Australian Government's Cyber Security Unit and last updated August 2023. The source for the instruction to gather the highest quality evidence that is reasonably practicable, and for the statement that assessments using interviews, reports and screenshots will always be inferior to assessments using scripts and tools. Framework guidance moves: ASD consulted on evolving the Essential Eight from 15 June to 12 July 2026 and published the result as the ASD Essentials on 15 October 2026, so check current ASD guidance before relying on a specific requirement. soc.cyber.wa.gov.au
Related Reading
- The 6 Step Cyber Strength System
- What Underwriters Check Before They Cover an Australian Business
- The Essential 8 Checklist, and Why It Is Not an Assessment
- What Your Provider Should Show You at an Essential 8 Review
- Cyber Strength Audit
About the author: Kane Nawrocki is the founder and CEO of inSUPPORT. He has spent more than 25 years in IT and built inSUPPORT to give Australian businesses managed IT, security and compliance as one model, with the remediation an audit finds included in the support fee rather than billed back as a surprise project.
Content reviewed by Probably Genius for accuracy and relevance.
inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.
CLICK HERE


