What the Insurance Module Does
Most organisations manage insurance and risk in separate places: policies with finance or the broker, risks in the risk register, and no link between them. The result is a question nobody can answer quickly — which of our risks are actually covered, and for how much?
The insurance module links policies to the risks they transfer, so coverage becomes a view of the risk register rather than a folder of PDFs.
Policies Linked to Risks
Each policy record carries insurer, broker, period, premium, limits, sub-limits, deductibles and excess, key exclusions, and renewal date — and links to the specific risks in your enterprise register that it transfers.
Once that link exists, two questions become reportable rather than investigative:
- For a given risk, what policy responds, up to what limit, with what deductible?
- For a given policy, which risks does it cover, and what is their assessed exposure?
Finding Under-Insurance and Gaps
With policies and risks connected, the platform surfaces the mismatches that usually only appear at claim time:
- Uncovered risks — risks whose treatment decision is transfer with no policy attached, which is a treatment plan that does not exist.
- Under-insurance — assessed exposure exceeding the limit that responds to it.
- Excess retention — deductibles disproportionate to the risk, indicating premium spent inefficiently.
- Duplicated cover — two policies responding to the same exposure.
- Coverage lapsing — renewals approaching on policies attached to live high-residual risks.
Transfer Is Not Elimination
Worth stating because it is the most common conceptual error in risk registers: transfer moves financial consequence, rarely reputational or regulatory consequence.
A risk marked "transferred — insured" still carries the regulatory finding, the customer impact and the operational disruption. ActiveERM keeps the residual assessment honest by distinguishing what the policy actually responds to from what the risk actually costs, so a red risk does not turn green because a policy exists.
Renewals and the Broker Cycle
Renewal dates drive scheduled notifications with enough lead time to act. At renewal, the register is the negotiating position: assessed exposure per risk, claims history, and the controls implemented since the last cycle.
Organisations that walk into a renewal with evidence of control improvement rather than a submission form tend to have a materially different conversation.
Claims
Claims are recorded against the policy and the risk, with status, reserve and settlement. Because incidents are already logged in the risk platform, the incident that generated the claim and the claim itself are connected rather than living in separate systems.
Claims history also feeds risk reassessment — a realised loss is evidence about your likelihood estimate.
Certificates and Third-Party Requirements
Insurance requirements flow both ways. Certificates you must supply to customers, and certificates you must collect from suppliers as part of third-party risk management, are tracked with expiry dates and gaps flagged.
Who It Suits
Organisations with a meaningful insurance programme and a functioning risk register that are currently unable to connect them — typically insurance-buying corporates, brokers advising clients, and regulated entities that must demonstrate risk treatment rather than merely assert it.
If you hold three policies and twelve risks, a spreadsheet is honestly fine.
Related
- Risk OS — the register policies attach to
- Risk matrices and treatment options — where transfer sits among treat, tolerate and terminate
- GRC Cloud — the platform this runs on
Request a demo to see policy-to-risk linkage and gap analysis with your own programme loaded.