Legacy insurance modernisation and identity governance in regulated change

At a glance

What this is: This is a case study of P&V Group’s insurance modernisation, showing that modular architecture can improve service and responsiveness only when governance keeps pace with integration change.

Why it matters: IAM teams should treat modernisation as an identity operating model change, because shifting systems, partners, and business workflows also shifts ownership of access, lifecycle, and control boundaries.

By the numbers:

• P&V Group distributes the P&V and Vivium brands through 170 exclusive P&V agencies and more than 1,000 brokerages.
• P&V Group has roots dating back to 1907.
• The transformation program launched in 2020 and has run for five years.

Context

P&V Group’s modernisation is not just an application refresh. It is a change in how the insurer connects business processes, distribution channels, and governance across a regulated operating model.

For identity and access teams, that matters because legacy replacement changes ownership boundaries as much as it changes code. When an insurer moves to modular software and a partner-led delivery model, access administration, integration responsibility, and lifecycle discipline must be redefined, not merely migrated.

The article’s broader point is that business-led transformation only stays controlled when the operating model for identity and governance is updated alongside the architecture.

Key questions

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. Every new module, integration, and external delivery relationship should have a named owner, a defined entitlement scope, and an offboarding trigger. Without that discipline, temporary project access becomes standing access and auditability deteriorates.

Q: When does partner access create the biggest governance risk in transformation projects?

A: Partner access becomes highest risk when implementation roles blur into operational roles. If a consultant, vendor, or integrator retains broad access after delivery milestones move on, the organisation inherits standing exceptions that are hard to review and harder to remove. The control problem is not trust alone, but unclear ownership of the access lifecycle.

Q: What breaks when legacy entitlements are left in place after migration?

A: Legacy entitlements break governance by creating two operating models at once. The new platform may be controlled, but old admin rights, integrations, or service accounts can still bypass the intended process. That makes cutover look complete while hidden access paths remain active, which is exactly where audit and operational drift start.

Q: Should insurers re-evaluate IAM governance before or after modular transformation?

A: Before. If identity ownership is not defined up front, the transformation will inherit the old ambiguity and multiply it across more components, more parties, and more integration points. The right sequence is to establish approval, recertification, and offboarding ownership before decommissioning the legacy platform.

Technical breakdown

Modular insurance architecture and identity boundaries

Modular software breaks a legacy platform into services or functional components that can change independently. In regulated insurance, that changes where authentication, authorisation, and integration controls sit, because the identity boundary is no longer one monolithic system. Instead, brokers, agents, customers, internal staff, and partner services all interact across separate components with different trust assumptions. That makes lifecycle ownership, entitlement design, and interface governance more important than the application wrapper itself. The real challenge is not only replacing code, but preserving control when the system becomes distributed.

Practical implication: map identity responsibilities to each modular component before cutover, not after it.

Third-party delivery and delegated access governance

The project model described by the article includes Comarch, P&V Group, and Ensur, which means delivery responsibility is shared across organisational boundaries. Shared delivery usually creates shared access paths, shared environments, and shared assumptions about who can provision, change, or troubleshoot. In identity terms, that means the programme must define how partner access is approved, scoped, monitored, and removed across environments and project phases. Without that, modernisation work can leave persistent exceptions behind even after the implementation is complete. Governance needs to follow the delivery chain, not just the production system.

Practical implication: formalise partner access and offboarding rules for every integration and implementation team.

Internal integrator model and lifecycle ownership

P&V Group says its IT department is moving into the role of internal integrator as legacy software is phased out. That shift sounds operational, but it has a direct identity consequence: the organisation now owns more of the decision-making around access, integration, and control consistency. In practice, internal integrator models often fail when teams assume vendors or implementation partners will continue to carry lifecycle responsibilities after go-live. Once the architecture becomes modular, the business must know who owns provisioning, recertification, service account oversight, and exception handling across the new stack.

Practical implication: assign named owners for access lifecycle and integration controls before retiring legacy platforms.

NHI Mgmt Group analysis

Legacy modernisation is an identity governance programme, not only an IT replacement exercise. When a regulated insurer moves from a monolithic estate to modular software, the access model changes with the architecture. Business workflows, partner interfaces, and internal control ownership all shift at the same time, so governance has to be redesigned around new trust boundaries. The practitioner conclusion is simple: modernisation succeeds when identity ownership is treated as part of the target operating model.

Shared delivery models create shared governance risk unless accountability is explicit. The tripartite model in this article shows how easily implementation, integration, and operational access can blur across the vendor, the consultant, and the insurer. That blur is manageable only when access decisions, environment privileges, and offboarding responsibilities are assigned by role and phase. The practitioner conclusion is to make delegated access and integration ownership auditable from day one.

Internal integrator models raise the governance burden on the enterprise, not just the IT team. Once the business depends on internal integration capability, identity lifecycle discipline can no longer live in a project plan or a vendor runbook. It must be owned as an ongoing control function spanning human access, service accounts, and partner connectivity. The practitioner conclusion is to treat integration maturity and identity maturity as the same programme outcome.

Modular architecture exposes control fragmentation, so identity policy has to become composable too. Legacy systems could hide weak ownership because most access paths converged in one platform. Modular environments spread those paths across services, partners, and workflows, which means policy, approvals, and review processes must be aligned component by component. The practitioner conclusion is to design governance that survives architectural decomposition.

For regulated insurers, transformation control is now measured by whether access exceptions disappear with the old estate. A modernisation effort that leaves legacy privileges, orphaned integration accounts, or vague partner access behind has not actually reduced operational risk. The practitioner conclusion is to verify that retirement of the old system also retires its identity exceptions.

What this signals

Identity governance has to be redesigned at the same time as application architecture. When systems are decomposed into modular services, the question is no longer whether access exists, but which component, team, or partner owns each access decision. If that ownership is not explicit, the programme ends up modernising the user interface while leaving control fragmentation intact.

Compositional governance becomes the new baseline for regulated transformation. Insurance organisations that rely on partners, consultants, and internal integrators need access policy that can move with the project phase and the service boundary. The practical signal for IAM teams is that lifecycle control, partner offboarding, and integration ownership must be designed as one operating pattern, not three separate tasks.

For practitioners

• Map identity ownership to the new operating model Define who approves, provisions, reviews, and removes access for each modular component, including business users, brokers, agents, and internal support teams.
• Separate partner access from production entitlements Give implementation partners only the access required for the current phase, then remove that access as soon as their role changes or ends.
• Retire legacy entitlements with the old platform Confirm that accounts, integrations, and admin rights tied to the legacy estate are not left behind after migration and cutover.
• Assign an internal integrator owner Name a single accountable team for access lifecycle decisions across systems, environments, and third-party connections once legacy software is phased out.

Key takeaways

• Legacy insurance modernisation changes identity governance by redistributing control across modular components, partners, and internal teams.
• The article shows a five-year transformation that improved service and responsiveness, but the governance lesson is that access ownership must be redesigned with the architecture.
• Modernisation programmes should retire legacy entitlements, define partner access rules, and assign a named internal integrator before cutover.

Key terms

• Modular Design: An architecture that divides a system into separate components with clear responsibilities. Each module can be developed, tested, and updated independently, which helps SaaS teams move faster without changing the entire application. It is especially useful when products need customisation, frequent updates, and controlled operational risk.
• Internal Integrator: An internal integrator is the enterprise team that owns how systems, partners, and services are connected and governed after implementation. For identity programmes, that role becomes the practical owner of access consistency, lifecycle decisions, and exception handling across the new operating model.
• Partner Access Governance: Partner access governance is the ongoing discipline of reviewing, validating and removing third-party access across the full integration lifecycle. It covers ownership, periodic certification, scope changes, remediation and offboarding. The goal is to keep business access aligned to current need, not historical approval.
• Lifecycle discipline: Lifecycle discipline is the practice of managing identities through joiner, mover, and leaver states so access stays appropriate as roles change. In regulated environments, it is what keeps access, approvals, and evidence aligned with the organisation’s actual operating state.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.