Why do you need it?
Most widely accepted security and risk-oriented frameworks discuss the need to adopt a formalized and structured approach to risk management and security. Most of them do not ask you to create a “risk register” but imply the need for such a repository. The Risk IT Framework, published by ISACA and associated with the COBIT 5 framework, does explicitly talk about this as a requirement for compliance. Specifically, Process Goal RE3 (Risk Evaluation) under “Maintain your Risk Profile”: “Maintain an up-to-date and complete inventory of known risks and attributes (e.g., expected frequency, potential impact, disposition), IT resources, capabilities and controls as understood in the context of business products, services and processes.”
In firms wishing to enhance maturity of risk management practices, systematic risk documentation and response can provide a solution accelerator, not in a prescriptive manner but as a platform upon which an improved set of practices can be built in the future. I have always maintained that managing risk is not a tactical maneuver but instead, it is a strategic choice. In over a decade of information security consulting I have mostly encountered firms not managing risk at all. Well, most do not document it to begin with!
The concept of the risk register is related to risk maps and risk scenarios. The risk register provides detailed information on each identified risk, including the risk owner, details of the risk scenario, details of the risk scores in the risk analysis, response and risk status. Risk registers serve as the primary reference for all risk-related information. Managers use the risk register prior to making risk-related decisions and there should be a strict “no-surprises” rule with risk registers, i.e., there is no new information here not already known to the firm: a risk register is just a convenient technique to store and maintain all collected information in a useful format for all stakeholders.
Template
Gartner has suggested firms use a table that allows a great deal of information to be conveyed in a few pages and provides flexibility in content and presentation as the document changes over time. The information recorded on the risk register could be structured as follows (derived from an ISO 27001 template):
| ID | Assign a unique reference in order to be able to identify each risk unambiguously (e.g. “15-2013” might be the 15th information security risk introduced into the analysis during 2013). Sequential numbers allow the table to be sorted sensibly! |
| Risk | Describe the information security risk briefly so that people will understand what risk you are assessing. |
| Asset owner | Who is the Information Asset Owner, the person who will be held to account if the risk treatments are inadequate, incidents occur and the organization is adversely impacted? It is in this person’s interest to assess and treat the risks adequately, or face the consequences. |
| Impact | Describe the potential impacts should the risk occur, ideally in business terms. Decide whether to use “worst case” or “anticipated” impacts and be consistent about it! Consistency is especially important as the risk register gets larger and more people get involved in the assessments. |
| Raw probability | Enter the probability or likelihood that the risk would occur if it was totally untreated, as a percentage value (see the section on scoring). |
| Raw impact | Enter the potential business impact if the risk occurred without any treatment, as a percentage value (see the section on scoring). |
| Raw risk rating | This is the product of the raw probability and impact values, in other words the raw/untreated/inherent level of risk. |
| Risk treatment | Describe how the risk is to be treated. Note that controls are just one option: risks can also be avoided, transferred or accepted. |
| Treatment cost | Estimate the total cost of mitigating the risk. |
| Treatment status | To what extent is the planned treatment in place? 0% means the treatment is only a plan at present – nothing has been done about it as yet. 100% means the treatment is fully operational. |
| Treated probability | Enter the probability that the risk will eventuate once the controls etc. are fully in effect, in the same way as for before mitigation (see the section on scoring). Treated values should be shown in bold if they are different to the raw values. |
| Treated impact | Enter the likely impact once the controls etc. are fully in effect, in the same way as before mitigation (see the section on scoring). Note that the impact of any incidents that actually do occur may increase with strong controls in place, since incidents due to control failures are not usually expected. Treated values are shown in bold if they are different to the raw values. |
| Target risk rating | This is the product of the anticipated probability and impact values once the risk treatment is fully implemented. |
| Current risk rating | This is the risk rating today, given the implementation status and anticipated probability and impact values when fully completed. For example, if the raw risk value is 50% and the treated risk value is 30% but the treatment is only 40% implemented, the current risk level is 32%. In reality, many security controls are either fully implemented and fully effective, or partially implemented and not at all effective – but the risk calculation here takes into account the fact that work is under way, hence management can assume it will be treated in due course. |
| Notes | Keep notes about the risks e.g. the factors you have taken into account and your reasoning, including any significant assumptions. |
| Last checked | Record the date on which the risk was last reviewed, updated and/or approved by management. Sort on this column to find risks that have not been checked in a long time and hence maybe should be reviewed or reconfirmed. |
| Residual risk assessment | This describes the risk levels after consideration of mitigating controls and treatment plan. Typically, mitigating controls will affect likelihood, impact or both, resulting in a lower level of risk. If a mitigating control doesn’t have a noticeable impact on risk, then its efficacy should be re-evaluated. Risk-averse organizations may choose to consider both the “typical case” and “worst case” of a particular risk. |
Risk scoring
An example structure for establishing scores is shown here:
Caution
What your risk register should not contain is also worth a mention. Since the risk register’s primary audience is “business folks”, or managers and senior executives, it should not be burdened with technical risks or threats. For example, don’t state that a particular set of servers is using a certificate that is susceptible to an MD5 collision vulnerability. Also, every conceivable threat should not be recorded, only the most significant ones that pose a serious challenge to the competitive position, operations and value system/chain of the firm. Keep separate details of the treatment plans, product information, etc as well since these items distract from the core idea behind the risk register: let the business stakeholders know what they are dealing with and have them formulate remediation strategies. Moving immediately to tool-based solutions assumes knowledge about the business impact of the risks that can only be properly defined by the business stakeholders themselves.
Hope you found the post useful!
The Berkeley MBA 
I have found plenty great imformation in this article! Definitely this deserves to be added to bookmarker for revisiting!
You can surf my blog – http://www.construction-partner.com