Insurance engineering teams should start with four priorities: oversight of third-party service providers, an inventory of software and data flows, access control and logging for systems with policyholder data, and an incident response plan that has been tested. Insurance regulators in many jurisdictions expect these, though the exact rules differ by place.
I did not fetch US state insurance regulator pages for this post, so it names themes rather than rule numbers. Read the data security law or regulation that applies to your licenses, such as a state insurance data security law in the US, or the Digital Operational Resilience Act in the EU. Not legal advice.
Why do insurers face a distinct mix?
Insurers hold sensitive personal, health and financial data, run on long-lived core systems, and depend on many vendors: claims platforms, brokers' portals, document processors, cloud hosts and analytics providers. A weakness in a vendor becomes the insurer's incident. Regulators have responded by adding explicit duties around third parties.
The EU's DORA, Regulation (EU) 2022/2554, is an example. Its scope includes insurance and reinsurance undertakings, and it requires financial entities to maintain a register of information on contractual arrangements for ICT services from third-party providers so supervisors can see dependencies.
1. How do you oversee third-party providers?
Keep a register: vendor, service, data they hold, contract owner, security contact, and exit plan. Rank vendors by the data and system access they have. Ask higher-risk vendors for evidence: audit reports, penetration test summaries, SBOM or dependency information for software they deliver, and incident notification terms. Record decisions and review dates. NIST SP 800-161 describes cybersecurity supply chain risk management in a form you can adapt.
2. What belongs in the inventory?
Systems, applications, data stores and their dependencies, plus data classification and flows. For software you build, generate dependency lists from lockfiles and keep SBOMs per release. Include vendor-hosted software, since that is where unmanaged exposure builds up. When a new vulnerability makes headlines, the inventory is how you answer "are we affected?" the same day.
3. What access controls are expected?
Least privilege roles for claims, underwriting and administration. Multi-factor authentication for staff and administrators. Regular access reviews, with removal on role change. Logs for access to policyholder data, retained and reviewed. A constructed example: a claims adjuster changes teams and keeps access to the prior team's files for a year. A quarterly review that compares roles to actual access catches this, and the fix is a ticket, not a project.
4. What does a tested incident response plan include?
Named roles, contact lists, decision rules for when to notify regulators, policyholders and partners, and the evidence you must preserve. Regulations in many places set notification clocks, so know which apply. Run a tabletop at least yearly with a scenario that involves a vendor breach, because that is the likelier case. Write the lessons into the plan.
How does software supply chain risk fit in?
Open source and vendor code run inside claims and policy systems. Lock dependencies, scan for known vulnerabilities in the build, review changes to pipelines, and track which services use which components. These steps support the third-party and inventory duties without a separate program.
What to do
- Identify which laws and regulations apply to each licensed entity.
- Build the vendor register and rank vendors by data access.
- Request security evidence and notification terms from high-risk vendors.
- Create the software and data inventory with owners.
- Generate SBOMs per release for systems you build.
- Review access quarterly and log access to policyholder data.
- Write and rehearse the incident response plan with a vendor-breach scenario.
- Keep evidence organized so you can answer a regulator or auditor quickly.
Safeguard's SBOM generation, dependency scanning and compliance automation can help produce the evidence for software you build. It does not certify you against any law or framework.
Quick check
Is the vendor register only required in the EU?
DORA formalizes it for EU financial entities. Many regulators and auditors elsewhere expect similar third-party records, so building one is sound practice.
Does cyber insurance replace these controls?
No. Policies have conditions and exclusions, and insurers increasingly ask for evidence of controls before they cover you.
Sources
- Regulation (EU) 2022/2554 (DORA) on EUR-Lex
- NIST SP 800-161 Rev. 1
- NIST SP 800-218: Secure Software Development Framework
Last reviewed: 18 October 2026.
