A cyber insurance disclosure audit checks that a current policy exists and that the coverage limit and period actually cover the balance sheet date, reads the specific exclusions in the policy rather than assuming the headline coverage amount is what would actually be paid, and, where a cyber incident occurred or was suspected during the year, traces how management assessed the incident against both the insurance policy's terms and the financial reporting requirement to recognize a provision or disclose a contingent liability if the loss is probable or possible and material.
Coverage existence is not coverage adequacy
- Confirm the policy's coverage period actually spans the balance sheet date and the period during which any known incident occurred — a policy that lapsed and was renewed with a gap, or one bound after an incident, does not provide the protection the entity may be assuming it has.
- Read the policy's exclusions specifically for conditions the entity's own IT environment may already have breached — common exclusions include losses arising from unpatched systems beyond a specified period, failure to maintain stated minimum security controls, or incidents involving an insider with authorised access.
- Check the sub-limits within the policy, which are often materially lower than the headline coverage figure for specific loss types such as business interruption, regulatory fines, or ransom payments — the entity may be under-covered for the specific type of loss most relevant to its own risk profile.
Disclosure for a known or suspected incident
| Check | Evidence | What it catches |
|---|---|---|
| Incident identification and scope | IT incident log, forensic report if obtained | An incident treated as contained with no assessment of actual data or financial exposure |
| Insurance claim status | Correspondence with insurer, claim acknowledgment or denial | A claim denied or disputed by the insurer, leaving the entity exposed beyond what it assumed |
| Provision or contingent liability assessment | Management's own evaluation memo | No formal assessment performed at all, with the incident treated as an IT matter rather than a financial reporting one |
| Subsequent events | Date of incident discovery relative to the balance sheet date and the audit report date | An incident discovered after year end but before the audit report date that still needs evaluation as a subsequent event |
Regulatory requirement
Recognition and disclosure of a cyber incident's financial consequences follow the same accounting standard applicable to provisions, contingent liabilities, and subsequent events generally — there is no separate standard for cyber losses. Confirm the applicable standard's criteria before concluding on treatment.
How we think about this
The auditor is not expected to assess the technical adequacy of the entity's cybersecurity controls. The auditor is expected to read a policy's exclusions as carefully as any other contract relied upon for disclosure purposes, and to treat an insurer's denial of a claim as a fact that changes the exposure, not as a dispute to wait out before deciding whether disclosure is needed.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit data & extractsHandling client data securely during fieldworkPen-drive discipline, who can open the shared drive, and what happens to the client's data after sign-off: the practical hygiene that protects a firm handling someone else's accounting records.
- Internal audit & IFCFraud risk assessment: building it into the audit planThe fraud triangle applied practically rather than as theory, why management override is a presumed risk on every engagement, and what journal entry testing is actually looking for.
- Audit workflow & automationSA 570: going concern, and when it actually changes the audit reportMost going-concern evaluations end exactly where they should: no material uncertainty, no change to the report. The standard is about the minority of cases where that's not true.
- CARO & Companies ActCARO clause 3(xix): material uncertainty on meeting liabilities, and how it differs from going concernThis clause looks only one year ahead, using financial ratios and ageing as its stated basis. SA 570's going-concern window is longer, and its basis is broader.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.