ISO 27001 Risk Register Setup: Step-by-Step Guide

While we talk a lot on this site about the US Government’s various cybersecurity frameworks, like FedRAMP and CMMC, there’s one significant framework that deserves just as much attention: ISO 27001.

ISO 27001, being an ISO standard, is an international framework for cybersecurity divorced from any one country’s government. It’s a way for businesses operating overseas – and even domestically – to demonstrate security in a way that is acknowledged by the international community.

Unlike frameworks like CMMC, which are based on set security controls and standards outlined by NIST, the ISO standard is more about conceptual elements of security; as long as you have something that meets the minimum accepted definition within each area of control, you can pass an assessment.

This makes ISO 27001 somewhat more complex because there’s no easy, templated, automatic way to handle it like there is for a lot of more specific security controls. Annex A is meant to be more specific, akin to NIST’s publications, but it’s still a different starting point and a different overarching aim.

One key element of ISO 27001 is the Risk Register. It’s a mandatory document and forms the backbone of the security framework you build according to ISO 27001’s guidelines.

What is the Risk Register, Specifically?

The ISO 27001 Risk Register is a document that outlines the risks your company faces.

Each risk is described with information including:

• The name of the risk, specific enough to make it readily identifiable.
• A description of the risk, aimed at being a digestible “elevator summary” for management.
• The likelihood of the risk happening, generally on a scale of 1-5.
• The severity of the impact that the risk would have on your business, again from 1-5.
• A description of the security controls you have implemented to mitigate that risk.
• The specific stakeholder within your organization whose responsibility is implementing and maintaining mitigation of the risk.
• An ongoing status reading of the risk, similar to continuous monitoring.

The data accumulated in the risk register can also be used to create a risk matrix, which uses the numerical scores above to prioritize risks.

• Risks with a low likelihood of occurring and a low impact are low-priority.
• Risks with a low likelihood of occurring but a high impact are mid-priority.
• Risks with a high likelihood of occurring but a low impact are also mid-priority.
• Risks with a high likelihood of occurring and a high impact are high priority.

This is a useful tool for organizing the order you implement, review, and pay attention to individual risks. It’s not a justification to ignore the low risks, but it’s a way to determine which risks get your attention more quickly.

An Example of a Risk Entry

To see this in action, here’s an example of what a single line item in a risk register might look like.

• Name of the risk: Email phishing attacks.
• Affected asset: Company email accounts.
• Name of threat: Phishing.
• Vulnerability: Lack of effective employee training.
• Likelihood of risk occurring: 5/5.
• Impact of the risk: 4/5.
• Overall risk level: High.
• Risk mitigation controls: Email spam filters, approved sender lists, Least Access account management, phishing training and testing, multi-factor authentication.
• Risk owner: IT Manager.
• Risk status: Ongoing.

This is a lot of information for a single risk. Now recognize that you have to have something like this for potentially hundreds of risks that could affect your company, and you see how this register can become an extremely important and intensive to create document.

Note that the specific categories and calculations don’t have to take this format, and some companies choose to include even more data. Some prioritize risks by multiplying the two numerical scores (resulting in a 1-25 numerical rating of severity.) Others use a 1-10 scale. Some include additional data about the risks and their mitigation strategies.

It matters a little less how you present the data and more that you record and present the data to ISO 27001 auditing organizations when it comes time to get your certification. This is one of the challenges of these audits; with less of a firm, templated idea of what goes into the documentation and implementation, an audit needs to be much more thorough.

Creating Your Risk Register

When it comes time to create a risk register for your business, get settled, because it’s going to be a lot of work.

It will never stop being a lot of work, either, because a risk register is a living document that serves as your control center for managing business risks.

Step 1: Decide on a Platform

The first thing you should do is decide on what kind of risk management platform you’re going to use.

Generally speaking, you have three options.

1. You can use a basic spreadsheet application. Many businesses choose to create an Excel sheet and keep a canonical version of it in a central location.
2. You can use a generalized risk management platform. The Ignyte Assurance Platform is a system-agnostic risk and control tracking platform we designed to work with ISO 27001 and many other frameworks.
3. You can use a specific ISO 27001 framework. There are many companies that offer tailored ISO 27001 platforms for building your risk register.

Generally speaking, we recommend option two, and not just because we’re one example. Option one is siloed and difficult to maintain without developing conflicts over time. Option three is fine if all you want is ISO 27001, but it falls flat if you want to add other security frameworks without starting from scratch. Only a platform like Ignyte helps you with all of the different security frameworks at once.

Step 2: Build a Template

If you aren’t using a template provided by a company, you will need to build your template. A spreadsheet with columns for each of the categories of information outlined above will do the job, and you can always adjust and evolve your template over time as your needs change.

You can also add, subdivide, and otherwise reformat information as you need, as long as it’s all there. For example, some templates include reference ID fields, external reference fields for association with Annex A or GDPR clauses, or other risk framework controls.

Step 3: Identify Risks

The single longest step of the process is identifying all of the possible risks your business will face. This is where the main ISO 27001 document, as well as the Annex A document, come into play. These outline the various risks you will need to identify and determine if they apply to your business.

Not all potential risks will apply. This is why one of the other key documents involved in ISO 27001 is an SoA or Statement of Applicability. This is the statement that identifies each risk and states whether or not that risk applies to your business.

For example, one business risk might be the physical damage of an earthquake to your servers. This is highly relevant for businesses in earthquake-prone regions but unlikely to matter for businesses in areas that are not seismically active.

Step 4: Describe the Risk

For each risk, you will need a brief description. This is the “elevator pitch” for the risk, something you can convey to a stakeholder in a few sentences to describe the risk. If you find that you need a longer and more detailed description to encompass the risk, there’s a good chance you’re trying to bundle several related risks and need to separate them out.

If you are using risk identifiers and categorization, you will add this data alongside the risk description. Otherwise, simply associating it with the relevant Annex A control is sufficient.

Step 5: Estimate the Impact of the Risk

The two dimensions of risk likelihood and risk impact need to be defined. Whether you use a scale of 1-5, 1-10, or another categorization method, you need to be consistent and outline what these values are.

Some businesses also use these two to define a third derived metric, the priority metric. This can be an external risk matrix or a third data column in your risk register. For example:

• Risk A: Occurrence 1/5, Impact 2/5. Derived priority: 2/25, low.
• Risk B: Occurrence 4/5, Impact 4/5. Derived priority: 16/25, high.
• Risk C: Occurrence 3/5, Impact 5/5. Derived priority: 15/25, high.

How you do this is, again, up to you, as long as you have the two important dimensions of likelihood and impact severity.

Step 6: Identify In-Place Controls

Unless your business is brand new or has been operating with effectively no security, there’s a decent chance you have some elements of risk mitigation already in place. You might use an email program with built-in spam filters and phishing protection. You might operate from a data center that has its own physical risk mitigations. You might already use multi-factor authentication as a matter of course.

Your goal for this step is to go through each risk and identify your current security posture for those risks. What do you currently have in place to mitigate those risks?

Step 7: Identify an Ideal Security Posture

The second piece of data for each risk that you need to have is what your goal security posture looks like. This might be “increase data encryption,” “implement more secure MFA,” or even adding physical security. There are many different ways to achieve security across these different security controls.

Part of the challenge of ISO 27001 is that it does not outline these methods like other security frameworks often do. You’re left more to your own devices to figure it out as it applies to your business. This leads to a more customized solution but also runs the risk of larger gaps in coverage if you aren’t sure of what you’re doing.

Step 8: Identify Mitigation Options

You know where you are, and you know where you’re going: now it’s time to perform a gap analysis to identify the security changes you need to make and the controls you need to implement to get to that ideal security posture. This is part of why the risk register is a living document.

Once you’re done with the risk register, you will have a document that gives you everything you need to move forward: a priority list of risks along with plans for mitigating them. You can then work down that list until you’ve achieved a viable minimum and can pass an ISO 27001 audit.

Step 9: Create a Mitigation Plan

Once your gap analysis is complete, you can develop your risk mitigation plan.

Broadly speaking, each risk falls into one of three groups. Some risks are avoidable: by making a change or implementing a security control, the risk becomes nonexistent. Some risks can be transferred: by working with an external supplier, you can offload the risk to someone else instead of assuming it yourself. Finally, some risks can be mitigated but not eliminated. By implementing security and training, you reduce the chances of the risk happening and minimize the potential damage it can do.

Identifying the risk mitigation plan for each risk gives you the tangible steps to take to fully achieve a secure state of operations.

Step 10: Assign an Owner to the Risk

Each risk needs to have a specific individual to assume responsibility for it.

This might be a C-level or director, or an upper manager in charge of a department; whoever it is needs to have the power and influence to make changes to mitigate or prevent the risk.

Step 11: Implement Risk Monitoring

Ongoing monitoring for the risk ensures that as the state of the world, the ambient threats, and the targeted threats all change, you change with it. Security is not a state of being; it’s a moving target and one that requires constant work to maintain.

As you go through and implement risk mitigation strategies or learn new data about new risks, your risk register will need to be updated. This is why a collaborative platform like the Ignyte Assurance Platform is ideal for the task. It’s not siloed, and it’s fully collaborative with your stakeholders, so your risks can be tracked and managed appropriately.

If you want to see what the Ignyte Platform can do for you, all you need to do is request a demo, and we’d be happy to show you.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Max Aulakh. Read the original post at: https://www.ignyteplatform.com/blog/iso-27001/iso-27001-risk-register/