Insurers are prime targets because they concentrate personal, health, identity and payment data and move money, across an ever-wider surface of portals and broker/aggregator integrations. In the GCC they're supervised much like banks — CBB in Bahrain, the Insurance Authority and NCA in Saudi Arabia, the Central Bank in the UAE — with PDPL over personal/health data and PCI DSS over card flows. A test should prioritise customer and broker portals, policy and claims systems, payment flows and API integrations, with heavy focus on access-control and business-logic flaws (can one customer see another's claim). Test at least annually and after significant change, timed to your supervisor's cycle. Details below.
// 01 Why insurers are a prime target
If you designed the perfect target for a data-hungry attacker, it would look like an insurance company. In one place sit dense personal and financial records, health data for medical and life lines, identity documents, banking details and full claims histories — the raw material for identity theft, fraud and extortion. Insurers also move money, collecting premiums and paying claims, which invites payment fraud on top of data theft. And the modern insurer is connected: customer self-service portals, broker and aggregator platforms, bank and reinsurer integrations. Rich data, payment flows and a wide, integrated surface add up to a top-tier target for ransomware and fraud — which is precisely why regulators and reinsurers expect regular penetration testing.
// 02 The regulatory drivers
Across the GCC, insurers are supervised by the same authorities that oversee banks, so the testing expectations rhyme with the banking ones. In Bahrain, the CBB licenses and supervises insurers and requires periodic penetration testing on its cycle. In Saudi Arabia, insurers sit under the Insurance Authority and the NCA's cybersecurity controls, with the sector long shaped by SAMA-aligned expectations. In the UAE, the Central Bank supervises insurance alongside the relevant standards. Layered on top of the sector rules are two cross-cutting drivers every insurer faces: the PDPL, governing the personal and health data they hold, and PCI DSS, wherever card payments are processed. Map yours precisely with the requirements finder.
// 03 What to test
Portals
Customer, agent and broker portals — the internet-facing front door to policy and claims data.
Core systems
Policy administration and claims platforms, and the actuarial and underwriting data behind them.
Payment flows
Premium collection and claim payout paths — the money-movement attack surface.
Underneath those targets, testing covers the web and API layers, the network and Active Directory, and cloud configuration as insurers migrate core systems.
// 04 Business logic is the real risk
For insurers, the finding that keeps executives up isn't a textbook technical bug — it's a broken access control that lets one customer read another's policy or claim. Insurance apps are full of authorisation boundaries: customer vs agent vs staff, one policyholder vs another, one broker's book vs a rival's. When those boundaries are enforced only in the UI, an attacker who manipulates an ID or an API call walks straight into other people's health and financial records — a mass data breach with no exotic exploit required. So a good insurance test weights business-logic and access-control testing heavily: object-level authorisation, function-level checks, and the claims/underwriting workflows where a manipulated request could approve, inflate or reroute a payout. Classic technical vulnerabilities matter, but the logic flaws are where insurers get hurt.
// 05 How often, and how it runs
Test at least annually, aligned to your supervisor's reporting cycle, and again after any significant change — a new portal, a core-system migration, a major broker integration. Regulated GCC insurers run this as a recurring programme: for CBB licensees, timed to the twice-yearly rhythm; elsewhere, to the applicable cycle — booking ahead of each deadline so findings can be remediated and retested before reporting. Reinsurers and enterprise clients may also ask for a recent test or an attestation letter. The engagement itself follows our standard shape — scoped rules of engagement, manual-led testing, and a report mapped to your regulator and to the frameworks you answer to — per our methodology.
// 06 Frequently asked questions
Why are insurers a target?
They concentrate dense personal, financial, health and identity data with full claims histories, and they move money through premiums and payouts — while running customer portals and broker integrations that widen the surface. That mix of rich data, payment flows and connected systems makes insurance a high-value target for theft, fraud and ransomware, so regulators and reinsurers expect regular testing.
Which regulations require testing for GCC insurers?
Insurers are supervised much like banks: the CBB in Bahrain requires periodic testing; in Saudi Arabia insurers fall under the Insurance Authority and NCA controls with SAMA-aligned expectations; in the UAE the Central Bank supervises insurance. On top, the PDPL governs personal and health data, and PCI DSS applies wherever cards are handled.
What should an insurance pentest cover?
Customer and broker portals, policy administration and claims systems, payment and premium flows, and API integrations with brokers, aggregators, banks and reinsurers — across web, API, network/AD and cloud. Because insurers hold health and financial data, access-control and business-logic testing (can one customer see another's policy or claim) is as important as classic technical vulnerabilities.
How often should insurers test?
At least annually, aligned to the regulator's cycle, and after significant change such as a new portal, migration or major integration. Regulated GCC insurers run it as a recurring programme timed to their supervisor's cycle — for CBB licensees, the twice-yearly rhythm — booking ahead so findings are remediated and retested before reporting. Reinsurers and enterprise clients may also ask for a recent test or attestation.
// 07 Related reading
- Penetration testing for banks — the closely-related financial-services playbook.
- CBB requirements and the GCC compliance calendar.
- Broken object-level authorisation and the requirements finder.