The last two posts have dealt with Risk Ontology, why we need one and what it contains; and Risk Framework – what it contains, and five key steps to get started. This post is about how to manage that information once it is defined.
What’s the best practice process and governance for managing a Risk Framework?
Managing updates to the Risk Framework can be a bear if you don’t have good governance around that information once it is defined.
Basically, we have three phases to the process, outlined below. Many GRC Technology platforms (shameless plug, yes, RSA Archer does this) support this type of process, but word of caution: you still need to define the Risk Framework that makes sense for your organization, and work through the step by process for each stakeholder community, and of course, train people on it, and implement the governance process to support it.
- Risk Framework – That’s what we talked about last post – With the Stakeholder Community, define the risk hierarchy of classes and types, identify risks through residual rating, and associate metrics to risks.
- Risk Remediation – For all risks with an inherent risk that is above the threshold, go through a remediation cycle. Some of these activities will be part of a regular risk assessment – but need not be.
- Content Review - Use the Stakeholder Community as a Review Board for Risk Content. New risks will emerge through audits and assessments, so make sure you have a regular review and governance process in place to accept new risks into the framework, and prune risks that are no longer relevant for your organization.
If you follow this type of best-practice process, you will go a long way to implementing a GRC ontology that gives your organization the visibility and control of risks that really matter.
