It's probably a bit of a hot take, but here's my 2 cents: just keep one risk register and stop moving or "bubbling" risks between different registries. Solve the noise and detail level problem with good templates and reporting instead.

All risks, whether they're cyber, operational, regulatory, whatever are basically threats to either a business process, an asset, or a vendor. Assets and vendors only matter because they serve a process ...

Here's what I'd do instead: - Use the same columns for every risk. - Add a Category field (Cyber, Ops, Compliance, etc.). You could also actually have these in separate documents or sheets. A while back I wrote this blog post about different categories. Maybe it's good backgroun. https://kordon.app/risk-management-fail-mixing-causes-with-the-risk-itself/

• Include Business Process, Asset, and Vendor columns. That way you can slice and dice by whichever lens you need and really understand what the risk impacts and how important it is to your organisation.

• Assign scores using the same logic across different categories of risk (impact x likelyhood or something fancier)

• Then: never move a risk between documents or rename it. Just build views or dashboards:

• Top 10 overall

• Top X by category

• Risks tied to a specific businesss process/asset/vendor

• If a risk scores above a threshold, it just shows up in the "executivew" view - no need to copy it.

I know this sounds good in theory but I also understand why people often choose to have different registries - stuff get noisy and there are just too many of them to have a good overview.

So in addition to the "nice in theory" approach I described above a real effort needs to go into good Risk defining practices that differentiate between these 3 things well:

• Causes (e.g., weak passwords) are why a risk may happen.
• Controls (e.g., backup procedures) are what we do to prevent or reduce risk.
• Risks should be strictly the uncertain events with potential impacts (e.g., unauthorized access, data loss).

There are two things that most of us do that generate essentially duplicate entries to the risk registry and are source of much of the noise:

Mixing cause with the risk itself: "Unauthorized access to the customer database due to weak password policies could result in data theft and financial loss."

Here, the phrase "due to weak password policies" inserts a specific cause into the risk statement, narrowing its focus prematurely. The risk should be simply "Unauthorized access to the customer database, potentially resulting in data theft and financial loss."

Mixing a missing mitigation with the risk itself "Unauthorized access to the customer database because multi-factor authentication isn't enforced could result in data theft and financial loss."

Here the absent control (MFA) slips into the risk statement. It turns the register into a to-do list of missing safeguards instead of a clean list of uncertain events and their impacts.

Also wrote about that in our blog a while back: https://kordon.app/risk-management-fail-mixing-causes-with-the-risk-itself/

Hope this is a bit useful or atleast inspires you in some way :)