How to replace disconnected risk registers

Start with the problem, not the spreadsheet

A risk register can be useful within a defined team or purpose. The problem begins when separate registers use different language, scoring, ownership and review cycles while describing risks that affect the same objectives, services, assets, suppliers or obligations.

Replacing those registers is therefore an operating-model and information change. Moving rows into one system without resolving the differences can reproduce the same fragmentation in a new place.

Recognise what is disconnected

Common signs include:

• The same risk appears in several registers with different ratings or owners.
• Enterprise, technology, supplier, compliance and continuity risks cannot be related easily.
• Controls are recorded separately from the obligations, risks and business services they support.
• Assurance evidence, findings and remediation actions sit in email, documents or other tools.
• Reporting depends on manual reconciliation and interpretation.
• Accepted risks, exceptions and overdue actions have incomplete decision history.
• Teams cannot tell which register is authoritative for a particular decision.

These conditions do not automatically require a new platform. They establish the questions that the replacement approach must answer.

Define the operating model before the target system

Agree how risk and assurance work should operate before selecting or configuring technology. The operating model should define:

• the risk and assurance domains in scope;
• the decisions that executives, governance groups, risk owners and operational teams must make;
• the roles responsible for creating, reviewing, approving, accepting and closing records;
• the minimum information and evidence required for each decision;
• review, escalation, exception and remediation workflows;
• reporting, assurance and record-retention needs; and
• which information should be central, integrated or deliberately kept in a specialist source.

The first implementation may cover only part of the target model. The boundary should be explicit so that a staged delivery remains connected to the longer-term design.

Inventory every current register

Create an evidence-based inventory before deciding what will move. For each register, record its purpose, owner, audience, risk domain, format, volume, current status, review cycle, source data, reporting dependencies, access restrictions and retention needs.

Then classify each register or record set:

• retain: the current source remains appropriate and will be connected where necessary;
• consolidate: the information belongs in the shared target environment;
• archive: the record must be preserved but does not need to remain active;
• retire: the register is obsolete, duplicated or no longer required; or
• investigate: ownership, quality or obligations must be resolved before a decision.

Preserve source identifiers and migration decisions so that the origin and treatment of each record remain traceable.

Build a shared taxonomy

A shared taxonomy allows related information to be compared and connected. It may cover risk categories, causes, events, impacts, likelihood, consequence, ratings, statuses, treatment responses, control types, assurance results, action states, organisational units, services, assets and suppliers.

Do not begin by forcing every local term into one list. Identify where terms mean the same thing, where they are materially different and where a translation is required. Record the definitions, ownership and change process for the taxonomy itself.

Historical ratings should retain the method used at the time. Converting every old score to a new scale can create false precision unless the underlying assessment is reviewed.

Set ownership and decision rights

Every active record needs an accountable owner, but ownership involves more than a name in a field. Define who can propose a record, assess it, approve a rating, accept residual risk, approve an exception, confirm evidence, close an action and change the taxonomy.

Separate operational responsibility from approval and independent assurance where the organisation requires that distinction. Escalation should follow materiality, authority and due dates rather than relying on informal follow-up.

Connect risks, controls, assurance and actions

The target model should preserve the relationships needed for decisions:

• risk to objective, service, process, asset or supplier;
• obligation or policy to control and accountable owner;
• control to evidence, assessment or assurance activity;
• finding or incident to affected control and risk;
• risk response to action, due date and responsible person; and
• exception or acceptance to the approving authority and review date.

This relationship model helps teams understand why a control exists, which risks are affected by a failed control and whether remediation addresses the relevant finding. It also supports reporting without treating every record as an isolated row.

Choose the target information architecture

The target may be an improved existing system, a central Integrated Risk Management platform, a federated model with specialist sources, or a staged combination. Evaluate each option against the operating model, information relationships, security, privacy, integration, reporting, retention and implementation constraints.

Decide which system is authoritative for each information type. Where information remains in another source, define the data owner, transfer method, frequency, failure handling and reconciliation responsibilities.

Move data in controlled waves

Migration should be planned by risk domain, business area, register or decision need. A controlled wave normally includes:

1. Prepare: confirm scope, ownership, mapping rules, source quality and acceptance criteria.
2. Clean: resolve duplicates, obsolete records, missing owners, inconsistent values and known errors.
3. Map: relate source fields and values to the target taxonomy and relationship model.
4. Transform: apply approved conversions while retaining source identifiers and necessary history.
5. Load: use an appropriate import, API or database migration route for the selected platform and source.
6. Validate: reconcile counts, relationships, ratings, ownership, evidence and access with authorised business owners.
7. Cut over: agree the effective date, change controls, communications, support and rollback conditions.
8. Archive or retire: preserve required records and remove ambiguous active sources only after acceptance.

A replacement is complete only when the old register has an agreed disposition and users know where current decisions and updates must be recorded.

Pilot a complete decision path

A pilot should test more than data import. Select a bounded area and follow a complete path from risk identification through assessment, controls, evidence, approval, actions, reporting and review. Include realistic permissions, exceptions and incomplete data.

The pilot should produce evidence for the next decision: what worked, what needs configuration or operating-model change, which migration rules require adjustment and whether the next wave is ready.

Plan adoption as operating work

Adoption depends on clear responsibilities and regular use. Prepare role-based guidance, migration communications, training, review calendars, support arrangements and governance reporting. Give owners time to validate their records and make the first review cycle part of the implementation plan.

Useful measures can include assigned ownership, required-field completeness, overdue reviews, overdue actions, evidence currency, duplicate records, reconciliation exceptions and use of agreed workflows. These measures describe adoption and information quality; they do not by themselves prove that organisational risk has reduced.

Where Parapet fits

Parapet provides an Integrated Risk Management platform and related services. Existing risk registers can be migrated through spreadsheet import, API bulk loading and selected database migration. The appropriate route, mapping, validation and implementation scope are agreed for each organisation.

Hot Desk can provide product-neutral Integrated Risk Management advisory before a platform decision. A recommendation may involve Parapet, another platform, improved use of an existing system or no platform change. When Parapet is selected, its dedicated product team is responsible for Parapet implementation, configuration and support.

Continue the discussion

Read how Integrated Risk Management relates to GRC, explore obligation, control and evidence design, or discuss your risk-register replacement requirements.

About this insight

This article is published by Hot Desk Consultancy Services Limited as general information. It is not legal, regulatory, records-management or procurement advice and does not assess a particular organisation, migration or product.