IDD Product Oversight and Governance: Turning POG Into a Product-Data Control, Not a Committee Minute

Most insurers can produce a POG committee pack. Far fewer can answer, per product, what the target market was, whether the product still delivers value to it, and what the distribution data actually shows — in a form a supervisor can query rather than read as prose.

Product oversight and governance under the Insurance Distribution Directive is usually run as a governance ritual. There is a policy, a committee, a quarterly pack, and minutes recording that products were reviewed and found satisfactory. All of that is necessary. None of it is what the regulation substantively asks a manufacturer to be able to demonstrate. Article 25 of the IDD, and the Delegated Regulation that fleshes it out, describe a set of obligations that are inherently about data held per product over its lifetime — who it is for, whether it still works for them, and where it is ending up. Treated as data, POG becomes evidence. Treated as minutes, it becomes anecdote.

What POG actually requires you to hold

IDD Article 25 requires manufacturers of insurance products to maintain, operate and review a product approval process. Commission Delegated Regulation (EU) 2017/2358, which has applied alongside the IDD since the directive came into application in October 2018, sets out what that process must contain. Read it as an engineer rather than a lawyer and it resolves into a small number of records that have to exist per product:

Free · 4 minutes

Is your engineering team shipping safely, or quietly accumulating risk?

Fourteen questions on how work gets from idea to production — cadence, testing, rollback, and the key-person risk in your delivery. Banded finding on screen, full sheet by email.

  • A product approval process (Article 4) — the documented arrangements under which the product was signed off, and by whom.
  • An identified target market (Article 5) — at a “sufficiently granular level”, together with the groups for whom the product is not compatible.
  • Product testing (Article 6) — including scenario analysis, showing the product meets the identified target market’s needs over its lifetime, before it goes to market and again after material change.
  • Product monitoring and review (Article 7) — continuous, at appropriate intervals, checking the product still meets the target market’s needs.
  • Distribution channels (Article 8) — selected as appropriate for the target market, with information passed to distributors under Article 9.

Every one of those is a field, or a set of fields, attached to a product. Target market is a record. The testing result is a record. The last review date, and its outcome, is a record. The approved distribution channels are a record. The moment you write them down that way, the question “can you demonstrate POG for this product” stops being a matter of finding the right committee minute and becomes a query.

Why the minute is the wrong artefact

A minute records that a decision was taken. It does not record the state of the thing decided about, and it does not stay current. Six months after a POG committee has noted that a unit-linked product was reviewed and found to offer value, the minute says exactly what it said on the day. The product’s charges, its claims ratios, its lapse rates and its actual customer base have all moved on. The minute is a timestamp, not a control.

This is the same failure mode I have written about in other regulated-product regimes: treating a registration or an oversight duty as a document to file rather than product data to wire into the system that runs the product. The regulator is not asking whether you held a meeting. It is asking whether this product, today, is reaching the people it was designed for and still doing what it was designed to do. A minute cannot answer that. A product record with a monitoring feed can.

What the product record should carry

The practical move is to give every manufactured product a governance record with fields that map directly to the delegated regulation, and to keep those fields live rather than static. At minimum:

  • Target market — positive and negative, expressed in attributes you can test distribution data against, not a paragraph of prose.
  • Value assessment — the metrics that evidence the product offers value to that market, with the date of the last assessment and the next one due. For insurance-based investment products this is where EIOPA has pushed hardest: its 2021 supervisory statement on the assessment of value for money in the unit-linked market set an explicit expectation that manufacturers test cost and value against the target market, and its supervisory work on this has continued.
  • Approved distribution channels — and the actual channels through which the product sold, so the two can be compared.
  • Outcome signals — lapse and surrender rates, claims acceptance and complaints, sales outside the target market: the data the distributor is obliged to feed back and the manufacturer is obliged to act on.
  • Review state — last review date, trigger for the next, and any remedial action taken.

Held this way, the distributor feedback loop that the delegated regulation requires — distributors reporting on distribution back to the manufacturer — becomes an inbound data feed against a schema, not a slide someone assembles by hand each quarter. That is a data-contract problem: agree the fields, the meaning, and the cadence up front, and the monitoring obligation runs itself instead of being reconstructed each cycle.

The board still decides; the data proves it

None of this removes the committee. POG requires human judgement about whether a product still serves its market, and that judgement belongs with people who are accountable for it. The point is that the committee should be reading a live product dashboard and recording its decisions against that data, not substituting for it. The minute then references a state the firm can reproduce, rather than asserting one it cannot.

This is the same discipline that turns any governance framework into something a supervisor will accept: evidence of control, not assertion of it. And it depends, unglamorously, on the product data being organised well enough to query in the first place — which is why POG is in practice a data-governance problem wearing a conduct-regulation badge.

When EIOPA or a national supervisor asks you to demonstrate POG for a given product, the firms that struggle are not the ones without a policy. They are the ones whose policy was only ever expressed as minutes. Encode the target market, the value assessment and the distribution outcomes as fields on the product, keep them current, and the demonstration is a query away. Leave them in the pack, and you are hoping the right meeting happened to record the right thing on the right day.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming