Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: P&V Group’s move from legacy systems to modular insurance software is framed as a business-led transformation that improves user experience, operating efficiency, and product responsiveness, according to Comarch. For identity teams, the real lesson is that modernization programs only stay controlled when governance, lifecycle discipline, and integration ownership keep pace with architectural change.
NHIMG editorial — based on content published by Comarch: P&V Group’s insurance modernisation and modular software transformation
By the numbers:
- P&V Group distributes the P&V and Vivium brands through a network of 170 exclusive P&V agencies and more than 1,000 brokerages.
Questions worth separating out
Q: How should insurers govern access during large core-system modernisation projects?
A: Insurers should treat modernisation as an access governance change, not only a technology change.
Q: Why do legacy transformation programmes often create hidden identity risk?
A: Legacy transformation programmes often create hidden identity risk because teams focus on application replacement while access ownership, third-party credentials, and integration secrets remain distributed across the old operating model.
Q: What should security teams measure during an insurance platform transition?
A: Security teams should measure how many identities were created for the programme, how many were retired at each milestone, and how many integrations still rely on temporary access.
Practitioner guidance
- Map entitlements to business capabilities Rebuild the access model so each role, service account, and integration credential is tied to a specific business capability rather than a legacy application name.
- Create explicit offboarding triggers for third parties Define a removal event for every external consultant, implementation partner, and support provider so access is revoked when the delivery role ends, not when someone remembers to review it.
- Review integration access at every cutover Treat each module migration or release as an identity boundary change and verify that service credentials, API tokens, and delegated support rights still match the current operating model.
What's in the full article
Comarch's full article covers the operational detail this post intentionally leaves for the source:
- The programme structure behind the tripartite co-creation model with Comarch, P&V Group, and Ensur
- The business rationale for phasing out legacy software while keeping day-to-day operations running
- The specific product and experience changes delivered for customers, brokers, agents, and employees
- The implementation perspective on how IT shifted into an internal integrator role
👉 Read Comarch’s case study on P&V Group’s insurance modernisation programme →
Legacy insurance modernisation: what it means for IAM and governance?
Explore further
08/07/2026 7:34 pm
Modular transformation creates an identity governance expansion, not just an architecture refresh. Each new module introduces service accounts, integration keys, delegated support access, and changed approval paths. In regulated insurance, the control problem shifts from system replacement to entitlement proliferation across the new operating model. Practitioners should treat every module cutover as an identity boundary change, not merely a technical release.
A few things that frame the scale:
- From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable for access when a vendor supports a transformation programme?
A: Accountability should sit with the organisation that owns the business process, not with the vendor alone. External partners may administer systems or build components, but the enterprise must define approval, expiry, and revocation rules so access does not persist after the support relationship changes.
👉 Read our full editorial: Legacy insurance modernisation and identity governance in regulated change
