Initial Steps Towards A Risk Management Plan: Creating A Basic Risk Register

Have you ever read old to-do lists? I do. It’s a good way to see what was and wasn’t a priority when I wrote them. Once an item gets on a to-do list, you have an obligation to do it, or at least worry why it isn’t done. It becomes real.

Today, we’ll explore a few different ways to build your company’s risk register and to gain some actionable insights into your overall risk profile. A risk register is just a more formal way to tell stakeholders at your organization the things you’re supposed to worry about. You’ll track your risks, what you are doing about them now and in the future.

At an operations level, it may seem silly. It doesn’t stop breaches, but it does make sure you’re doing the right things. The goal of a risk management process is to identify relevant threats and ensure that the organization is aligned to respond to these issues.

The process of risk management begins with a series of risk assessments, during which weaknesses in information systems, external threats, vulnerabilities inherent in data stores or business processes, and other sources of risk are identified and reviewed, and written down into your “risk register.” Information from these risk assessments should ideally also be collated into a higher-level view and aligned with the business and strategic goals to help prioritize work on the risks you’re tracking.

This sounds great, but how do you actually create a risk register, and how do you do a risk assessment on all those items you’re now tracking?

Performing Risk Assessments

What goes into your risk register in large part depends on the risk analysis framework that your company has chosen. At a basic level, you will want to track some information about each risk and provide some way to derive an overall view of your organization’s risk profile.

Binary Risk Analysis is a lightweight risk analysis framework that is used to encourage disparate viewpoints to reach a common understanding and facilitate discussion. It uses a set of 10 yes/no questions to capture Attack Effectiveness, Threat Likelihood, and Impact, which are used to derive the overall risk level. You can learn more about using Binary Risk Analysis in our white paper on A Minimum Viable Risk Management Program and experiment with the workcard and web hosted tools. The advantage of BinRA is that it is quick and easily understood, and the results are easy to capture. In some cases, it may not be clear that BinRA is the appropriate risk assessment methodology, such as for larger systems level risks. In those cases, practitioners may want to look to FAIR analysis, or perform a NIST 800-30 based risk assessment.

Often, at the individual risk level you will want to assign some identifier such as an ID to the risk, and capture a short description of the risk. Next, you’ll want to capture the results of your risk analysis so that you can revisit the analysis as needed. If you’re using Binary Risk Analysis, you can save either a short string of ones and zeros (“010011101”) indicating the “yes” or “no” answer to each question used in the Binary Risk Analysis, or you can build the questions right into your spreadsheet risk register and save a yes/no in the column for each question.

If instead you’re using a framework like the NIST 800-30 analysis, you’ll want to begin with documenting the assets or systems that are in scope. Inventory management and asset discovery tools can assist here, to ensure that you’ve accounted for all assets. For each asset, take note of any “pre-disposing conditions” that affect it, such as whether the system holds electronic Protected Health Information, or ePHI, or whether the system runs older software that can no longer be updated and patched.

Next, you’ll need to identify and classify the threats to information systems and prioritize the vulnerabilities that pose the highest level of risk to the organization. Risk assessors should capture a short description about each vulnerability considered, and then assign it a severity rating. The severity ratings used in NIST 800-30 assign values from Very High (“exposed and exploitable, and its exploitation could result in severe impacts”) to Very Low. Next, the risk assessors would assign a likelihood, and classify the level of impact to the organization. The impact and likelihood together combine to derive an overall level of risk: look up the impact and likelihood in the table they provide and see what Risk level they assign. Note that each of these sub-component scores should ideally be captured in your risk register.

Now that you have a list of “risks” and some information about impact, likelihood, and overall risk, you will want to prioritize your tracked risks. Ideally, you will first tackle the “Very High” risk items, but there may be other factors that come into play. Do you have a project already scheduled and budgeted to tackle some items related to some of your “moderate” risks, which you could expend to address the risks easily? The business priorities and strategic risk appetite can also weigh prioritizing some risks higher or lower.

Creating the Risk Register

Risk registers can be tracked using a variety of tools, from a list on a whiteboard (which we don’t recommend, but it can be a start!) to using highly specialized GRC tools. We’ll give you details on two different systems, but the right tool is the one that works best for your organization.

Excel or Google Spreadsheets

One of the simplest ways to track risks is using a spreadsheet. Open up a new spreadsheet, and create columns for “risk id,” “risk name,” “likelihood,” “asset value” and whatever else you want to track.

We recommend that you include some of these columns:

  • Risk Entry Date and Risk Last Reviewed Date: the date you first put the item into your register, and when you last reviewed it. Ideally, each risk should be reviewed at least annually

  • Affected Assets: this can be general (“Azure Cloud Environment”) or specific (a list of AWS subscription IDs, a set of user laptops, a SAAS tool used by your marketing team…)

  • Priority: What is the importance of this risk, and in which order will you plan to address the risks you’re tracking?

  • Compensating Controls: these sometimes are best tracked on a different sheet in your workbook, because you many have several compensating controls per risk

Fill in the rows as you go, and have it sort items by the overall risk you determine. Congratulations, you now have a risk register!

Jira

If your company makes extensive use of Jira, it may make sense to put your risk register into Jira, so that you can link to issues  where you track work to address vulnerabilities or to implement compensating controls. You can leverage many of Jira’s built in features, like a reported date, due date, and assignee. In addition, we would recommend including several of these fields in your risk register issue type:

  • Name: title of the risk issue

  • Business unit/owner: Who is ultimately accountable for where the risk lives (IT, Product owner, etc.)

  • Score: Quantification from Binary Risk Analysis or other risk framework

  • Likelihood: Low, medium, high or scale

  • Impact: Low, medium, high or scale

  • Risk rating/severity: Low, medium, high or scale

  • Priority: Separate from the actual scoring of the risk, what is its priority to the organization to resolve?

  • Treatment plan: Summary level plan to address the risk (not a complete spec, project plan, etc. but maybe a link to it with a statement). You can also use related issues link for detailed plans (story, epic, etc.)

  • Signoff: Authoritative signoff for moving to mitigated or closed states, restricted to users with a role permission.

You can use a standard Jira state workflow (Open -> In Progress -> Closed), but that may not fit with tracking items that are likely to remain open for long periods, need comments from various groups, and otherwise don’t necessarily behave like functional bugs. Some of the states we would recommend adding to your Jira risk register include:

  • Open: The initial state, usually unassigned. Indicative that no work has been done yet.

  • Assessing: Initial assessment, triage, and validation of the issue by an SME.

  • Verified Issue: has been assessed and should now be scored. It may not yet be assigned or prioritized, which may be done by a different person or committee.

  • On hold/deferred: A verified issue that won’t be addressed near term. A comment or custom field should indicate why. This uses a standard workflow state but may alter its flow or meaning.

  • Accepted: Accepted by management. This action should be restricted to those able to accept a risk for the organization. A comment or custom field explaining why should be required.

  • Review: Action has been taken to mitigate the risk; the issue is in validation to determine if resolved or mitigated. Review may be limited to a department, SMEs, or other authoritative parties.

  • Mitigated, resolved: Mitigated to the extent possible or deemed sufficient, or fully resolved (depends on implementation). Either can be returned to an earlier state based on additional developments (new vulnerability elevates risk, mitigation proven ineffective, etc.).

  • Closed: Fully resolved, usually not closed out until some time has passed (like an audit cycle) to fully verify actions taken, any cleanup, etc. has proven effective. Should be limited to authorized management.

In conclusion

However you decide to track risks, remember that this should be a living document and risks as well as compensating controls and treatment plans should be reviewed at least annually. Risk assessments shouldn’t be performed in isolation by an IT or Security team, but should be a dialogue with technical and business leadership in your organization.

Previous
Previous

Common Security Certifications & Audits: A Review of Some Standard Security Certifications for SaaS Vendors

Next
Next

Contingency Planning and Business Continuity