Skip to main content
Insurance · Cyber Risk Governance

Insurance
cybersecurity: why
defensibility
beats compliance.

Australian insurers are not short on cybersecurity policies. They are short on evidence that their decisions would survive scrutiny. Under APRA CPS 234 the board is ultimately responsible for information security, and when something goes wrong, the question is not whether you had a policy. It is whether you can show who owned the decision, what evidence they relied on, and what happened when that evidence was missing.

The regulatory pressure is intensifying. CPS 230 took effect on 1 July 2025. The Financial Accountability Regime has made individual executives personally accountable. APRA's tripartite reviews have exposed systemic gaps across 300+ regulated entities. For insurance leadership teams, the gap between compliance and defensibility is where careers and organisations are most exposed.

Written by practitioners who are ISO 27001 certified and advise APRA-regulated insurers on CPS 234 compliance, vendor risk governance, and Lighthouse Assessments.

01 / The evidence problem

Most insurers have frameworks. Few can evidence their decisions under pressure.

Insurance leadership teams do not lack cybersecurity frameworks. Most APRA-regulated insurers have risk policies, security standards documents, vendor onboarding checklists, and board reporting templates. The frameworks exist. The problem is that when pressure arrives, the question APRA, auditors, incident responders, or cyber insurers will ask is not "did you have a policy?" It is "can you show us the evidence behind your decisions?"

Defensibility is that narrow strip between what your organisation believes is covered and what can be proved. It requires three things: named ownership of every material cybersecurity decision, documented evidence supporting each decision, and time-bound treatment for any gaps identified. If any of those three are missing, you are carrying risk without knowing it.

The data makes the urgency clear. Verizon's 2025 DBIR found that third-party involvement in breaches doubled to 30%, and vulnerability exploitation rose 34%. That is exactly the attack profile Australian insurers should expect: ecosystems built on vendors, brokers, third-party administrators, SaaS platforms, outsourced claims, and contact centres, all holding sensitive policyholder data.

The OAIC's July to December 2024 reporting period recorded 595 notifiable data breach notifications, with Finance (including superannuation) in the top five sectors at 54 notifications (9%). The ASD Annual Cyber Threat Report recorded 84,700 cybercrime reports in FY2024-25, roughly one every six minutes, with average self-reported business losses of $80,850 per report.

None of these numbers are abstract for insurers. You hold the data that attackers want. You run the supply chains that attackers exploit. And you operate under a regulator that has demonstrated it is willing to act when evidence of good governance is missing.

The uncomfortable truth: When pressure hits, you do not rise to your policies. You fall to your operating model. If your operating model allows material initiatives to reach go-live without evidence, you have engineered risk by default.

02 / What APRA actually expects

The regulatory stack is no longer theoretical. Individual accountability is here.

APRA's CPS 234 is unambiguous: the board is ultimately responsible for ensuring the entity maintains information security, including for assets managed by related parties and third parties. The standard requires entities to classify information assets (including those managed by third parties) in a way that reflects potential impact. It requires controls commensurate with threats and the stage in the asset lifecycle. It requires systematic testing and assurance. And it requires internal audit to review the design and operating effectiveness of information security controls, including those maintained by third parties.

If a material information security incident occurs, CPS 234 requires the entity to notify APRA within 72 hours of becoming aware. If a material control weakness is identified that cannot be remediated in a timely manner, notification must occur within 10 business days. The clock starts from awareness, not from when the incident occurred.

But CPS 234 is no longer operating in isolation. The regulatory stack now includes:

  • CPS 230 Operational Risk Management (effective 1 July 2025): replaced the old outsourcing standard and added critical operations identification, business continuity requirements, and enhanced third-party management. CPS 230 explicitly requires entities to meet CPS 234 information security requirements when managing technology risks.
  • The Financial Accountability Regime (FAR): makes individual executives personally accountable for CPS 234 compliance. Cybersecurity failures are no longer just organisational problems. Named individuals face personal regulatory consequences.
  • The Cyber Security Act 2024: adds mandatory ransomware reporting with its own 72-hour clock, running alongside the CPS 234 notification obligation.

APRA has also demonstrated it is willing to use enforcement. The $250 million additional capital charge imposed on Medibank Private following its 2022 data breach established that the consequences of cybersecurity governance failures are material, not hypothetical.

APRA's tripartite assessment programme, covering 300+ regulated entities, identified six systemic gaps: incomplete asset classification, limited third-party security assessment, inadequate control testing, untested incident response plans, limited internal audit of security controls, and inconsistent reporting of incidents to APRA. If your organisation has not addressed these six areas with evidence, you already know where APRA will look.

For insurance boards: The combination of CPS 234, CPS 230, and FAR means that board members and named executives can no longer treat cybersecurity as a technology problem delegated downward. If the decisions are not defensible, the accountability is personal.

03 / Where insurance cyber risk really lives

The attack surface is not your perimeter. It is your vendor ecosystem and your data.

Insurance carries a distinctive cyber risk profile. The combination of sensitive personal data, complex vendor ecosystems, and legacy technology platforms creates an attack surface that looks nothing like the simple perimeter model most frameworks assume.

Policyholder data
Personal details, health information, financial records, claims history. Insurers hold the kind of data that creates regulatory, reputational, and legal exposure in a single breach. The OAIC has consistently placed financial services in the top five sectors for notifiable breaches.
Vendor and broker networks
Brokers, TPAs, claims assessors, actuarial services, SaaS platforms, and outsourced contact centres all touch policyholder data. Each connection is a potential access path that your perimeter controls cannot see or govern.
Legacy platforms
Policy administration systems, claims platforms, and underwriting engines often run on ageing technology stacks that are difficult to patch, hard to monitor, and expensive to replace. They persist because they work, until they become the entry point.
Operational dependencies
Claims processing, policy issuance, and customer service rely on systems that must be available. A cybersecurity incident that disrupts operations creates regulatory obligations under both CPS 234 and CPS 230, alongside the direct business impact.

The pattern in Australian breach data is consistent: attackers target credentials, vendors, and exposed systems. They do not need sophisticated zero-day exploits when a compromised broker credential or an unpatched vendor portal provides access to policyholder data. This is why risk management for insurers must extend well beyond the corporate network.

04 / Five defensibility tests

Practical tests your board should be able to pass. Most cannot.

Defensibility is not abstract. It can be tested with specific questions. If your leadership team cannot answer these five questions with evidence, your cyber risk governance has gaps that will be visible under scrutiny.

1
Decision ownership
For every material system, vendor relationship, and data flow, can you name the person who accepted the residual cybersecurity risk?
Not the team. Not the committee. The named individual who reviewed the evidence, understood the residual risk, and accepted it on behalf of the organisation. Under FAR, this is no longer a governance nice-to-have. It is a regulatory requirement with personal consequences.
Common failure
Risk is accepted implicitly through project delivery timelines. No one formally owns the decision. When something goes wrong, accountability is diffused across committees and steering groups.
2
Evidence currency
Is your evidence for critical controls current, tested, and independently verified, or is it based on vendor attestations and self-assessments?
CPS 234 requires systematic testing of information security controls, including those maintained by third parties. Internal audit must review design and operating effectiveness. "The vendor said they're ISO 27001 certified" is a starting point, not evidence. You need to verify scope, currency, and relevance to your specific risk.
Common failure
Evidence packs are assembled at onboarding and never updated. Vendor certifications expire. Penetration test reports are 18 months old. No one checks whether the scope of the vendor's certification actually covers the services they provide to you.
3
Exception discipline
Do your cybersecurity exceptions have named owners, documented justifications, and expiry dates, or do they age indefinitely?
Every organisation carries exceptions. That is normal. What is not defensible is carrying exceptions without owners, without time limits, and without a funded plan to remediate. An exception that has been open for two years with no expiry date is not an exception. It is an accepted permanent vulnerability.
Common failure
The exceptions register exists, but half the entries have no expiry date, no remediation plan, and the original owner has left the organisation. No one re-validates whether the risk acceptance is still appropriate.
4
Third-party visibility
Can you demonstrate, with evidence, that your critical third parties meet the security obligations you expect of them?
CPS 234 explicitly requires entities to assess the information security capability of third parties managing information assets. CPS 230 adds further requirements for critical and material service providers. The test is whether your third-party risk management programme produces evidence, or just questionnaires.
Common failure
Vendors complete security questionnaires at onboarding. No one validates the answers. No one re-assesses at renewal. Contracts contain security obligations but no mechanism to verify compliance or enforce remediation.
5
Incident readiness
Has your incident response plan been tested under realistic conditions in the last 12 months, including scenarios involving your critical vendors?
CPS 234 requires incident response plans to be reviewed and tested at least annually. But a plan that has only been reviewed on paper is not tested. The question is whether your team has exercised the plan under pressure, with realistic scenarios that include vendor dependencies, 72-hour notification timelines, and cross-functional coordination.
Common failure
The incident response plan was last tested two years ago with a simple desktop scenario. It does not cover vendor-originated incidents. Key personnel listed in the plan have changed roles. The 72-hour APRA notification process has never been rehearsed.

If your board cannot pass all five tests, the priority is not more policy. It is building the operating discipline that connects decisions to evidence. Security governance is the mechanism that makes this work at scale.

05 / Vendor risk in insurance

Contracts are governance. If you sign without leverage, you have accepted the risk.

Insurance operates through ecosystems. Brokers originate policies. TPAs process claims. SaaS platforms manage policy administration. Contact centres handle customer interactions. Actuarial firms model risk using your data. Each of these relationships carries cybersecurity risk, and under CPS 234 and CPS 230, the insurer remains accountable for that risk regardless of where the data sits or who manages the system.

Vendor questionnaires do not create leverage. Contract terms do. Enforceable vendor security means your contracts contain:

  • Measurable security obligations, not vague references to "industry standard practices" or "reasonable security measures"
  • Remediation SLAs with reporting cadence so you know when gaps are identified and when they will be closed
  • Incident notification timelines that give you enough time to meet your own 72-hour APRA obligation
  • Audit and assurance rights including the right to validate evidence, not just receive self-attestations
  • Data handling specifics: residency, access paths, subcontractors, retention, secure deletion, and exit support

CPS 230 strengthened these expectations. Its transitional arrangements for pre-existing service provider contracts run until 1 July 2026. If you have not reviewed your material vendor contracts against CPS 230 requirements, the window is closing.

The practical test: If your most critical vendor had a data breach tomorrow, could you demonstrate that your contract required them to notify you promptly, that you had audit rights over their security controls, and that you had evidence of their security posture from the last 12 months? If not, your vendor governance is aspirational, not enforceable.

06 / Building a defensible operating model

Defensibility is a discipline, not a document. Here is what the operating model looks like.

The difference between compliance and defensibility is operating discipline. Compliance produces documents. Defensibility produces evidence. The operating model that delivers defensibility has four components:

Gated decisions with evidence requirements

Material cybersecurity decisions, vendor selection, system go-live, risk acceptance, exception approvals, should not proceed without documented evidence. This is the principle behind Cliffside's Six Security Gates model: forcing decisions to the point where you still have leverage, rather than retrofitting controls after the risk is already operational.

For insurance, the critical decision points are vendor selection (before you sign), solution design (before you build), go-live (before you release), and BAU handover (before you operationalise). At each point, the question is the same: can we evidence that this decision is defensible?

Board reporting that shows defensibility, not activity

Boards do not need 40-page cyber reports. They need a defensibility view. A workable monthly pack includes:

  • Material initiatives and their evidence status (not project status, evidence status)
  • Residual risk accepted this month, with named owners and expiry dates
  • Exceptions ageing by owner, highlighting any without remediation plans
  • Assurance sampling results on evidence packs
  • Incidents tied to delivery, vendor, or handover gaps

This shifts the board conversation from "are we secure?" to "are our decisions defensible?" The first question is unanswerable. The second is specific, measurable, and actionable.

Continuous assurance, not point-in-time audits

Annual cybersecurity audits are necessary but insufficient. Defensibility requires ongoing evidence that controls are operating effectively between audits. This means regular testing of critical controls, periodic re-assessment of vendor security posture, exception register reviews with ageing analysis, and incident response exercises at least annually.

Accountability that survives personnel change

Defensibility fails when the person who understood the risk leaves and their successor inherits undocumented decisions. The operating model must ensure that risk acceptance is documented independently of individuals, exception ownership transfers when roles change, evidence packs are maintained in a central register, and escalation paths remain current.

07 / What to do in the next 90 days

A practical timeline to move from compliance to defensibility.

This will only stick if you pilot it on real work. Do not try to transform everything at once. Pick one material vendor relationship and one material delivery initiative, and apply the defensibility discipline to both.

Days 1-30
Establish the foundation
Define materiality triggers for what requires formal risk acceptance. Publish the defensibility policy with evidence requirements at each decision gate. Create templates: risk acceptance memo, exceptions register, vendor evidence pack, BAU handover checklist. Name decision owners and escalation paths. Conduct a gap assessment against APRA's six tripartite findings for your own environment.
Days 31-60
Pilot on live work
Apply the defensibility model to one active vendor procurement or renewal. Apply it to one delivery initiative approaching go-live. Test whether evidence requirements are practical and adjust where they create friction without adding value. Start a weekly cadence for exception and evidence reviews. Run a tabletop exercise covering a vendor-originated incident.
Days 61-90
Embed and scale
Integrate evidence requirements into existing PMO stage gates. Begin assurance sampling on completed evidence packs. Deliver the first board defensibility report. Review and update the approach based on pilot findings. Extend the model to remaining material vendor relationships and delivery initiatives.
08 / How Cliffside helps

What the Cliffside approach to insurance cybersecurity defensibility looks like.

We hold ISO/IEC 27001:2022 certification ourselves. We advise APRA-regulated insurers on CPS 234 compliance, vendor risk governance, and cybersecurity operating models. We understand the difference between documented compliance and genuine defensibility, because we have assessed both and helped organisations move from one to the other.

Our approach starts with the Lighthouse Assessment: a comprehensive, multi-specialist evaluation of your current cybersecurity posture against CPS 234 requirements and defensibility standards. The output is an independently assessed view of where your evidence holds up and where it does not.

We will tell you honestly:

  • Where your evidence is strong and where it has gaps that would be visible under APRA scrutiny
  • Whether your vendor governance is enforceable or aspirational
  • Which CPS 234 obligations you are meeting in substance, not just on paper
  • What a realistic path to defensibility looks like for your specific environment
  • Where the quick wins are and where the hard structural work is needed

If the honest answer is "your policies are fine but your evidence is missing," we will say that. If the honest answer is "your vendor contracts need to be renegotiated before your governance is defensible," we will say that too.

Insurance defensibility

Know where
your evidence
holds up, first.

The Cliffside Lighthouse Assessment gives you an independently assessed view of your cybersecurity defensibility under CPS 234 and CPS 230, with a prioritised gap analysis and honest advice about where your decisions are defensible and where they are not.

What you get from the Lighthouse Assessment
  • Independently assessed CPS 234 compliance posture across all obligation areas
  • Evidence gap analysis identifying where your defensibility breaks down
  • Vendor governance assessment against CPS 230 requirements
  • Prioritised remediation roadmap with realistic timelines
  • Transferable report, yours to use with any provider