Risk assessment 101: Working backwards from the controls

Performing an information security risk assessment in order to meet the requirements of ISO 27001, SOC 2, PCI DSS, or HIPAA can feel a bit daunting at first. The truth is there are a number of different approaches and methodologies that can work. In this article, I’m going to provide you with a simple and practical example of how you can start with a controls framework, like the ISO 27001 Annex A, and work backwards.

‍

Start with any control. In this example let’s use the first control from the ISO 27001 Annex A:

Section A.5 Information Security Policies includes an information security objective, which is: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.

‍

‍The first control is A.5.1.1 Policies for Information Security: A set of policies for information security shall be defined, approved by management, published and communicated to employees and relevant external parties.

‍

In summary, this control activity indicates that companies should communicate approved policies to personnel so that those personnel know how to perform their job roles in accordance with the direction and rules set by management.

‍

Facing vulnerabilities in the org

‍

The first step after we read and understand the control is to assess how well our organization has implemented it. To the extent that we haven’t implemented the control, those gaps will be listed on our Risk Assessment document as Vulnerabilities.

Policy vulnerabilities could include things like the following:

• We don’t have any security policies
• Policies are old and out of date
• Policies are inaccurate and/or contradictory
• Policies have not been reviewed and approved by management
• Policies haven’t been published or communicated to personnel
• Policies haven’t been acknowledged or accepted by personnel
• Personnel can’t find or access policies when needed
• Policies are too long, too technical, or generally not understandable by the user

What’s the risk then? The risks of not effectively implementing policies could include:

• Personnel don’t understand the rules or management’s direction
• Personnel take actions that are not consistent with the will of management
• Personnel perform actions based on incorrect or out-of-date procedures
• Management lacks a mechanism to direct the organization’s behavior

The next question to ask is: If we have issues or weaknesses with policies, do we have any other controls that could mitigate those potential risks? We can list those as Existing Controls. For example:

• All employees perform security awareness training
• Employees receive targeted training relevant to their role
• Managers meet with direct reports weekly to review their work
• Managers are responsible to mentor and provide ad hoc guidance
• Logging and alerting systems detect and alert on technical misconfigurations or vulnerabilities

After considering the potential risks along with the vulnerabilities and existing controls, we will document a Risk Scenario which could be the most important potential risk or a combination of possible risks. An example risk scenario could be as follows:

• Users perform insecure actions because they are not aware of company security policies

{{cta_withimage4="/cta-modules"}}

‍

Identifying risk scenarios

‍

Having identified the Risk Scenario we now need to assess the likelihood and impact of the risk materializing which will be combined to give the overall Risk Score. Typically, the likelihood, impact, and overall risk are ranked on a scale of 1-3 or 1-5, which represents something like low, medium, and high.

For this example, we’ll say the likelihood of the risk materializing is a medium likelihood with a score of two (2). The rationale is that while we do lack clear policy direction, a mitigating factor is that employees can solicit management for direction and they do receive basic security training.

Let’s say the impact is also medium or two (2). The rationale is that we expect employees to have enough security awareness and competence to ask for help before taking an insecure action, but the possibility exists that that won’t always happen. An employee could make a serious mistake, like misconfiguring a publicly accessible datastore to allow unauthorized access to sensitive data.

Using a simple multiplication methodology, the overall risk score in this case would be four (4), which would represent a medium risk overall according to our method.

Now a common mistake is to get hung up on the scoring for likelihood, impact, and overall risk. Don’t worry about that too much. It’s a subjective determination, just do your best. The most important thing is to identify and document the risk scenario. You can always adjust the scoring later based on a reconsideration or new inputs.

The next step is to determine the Risk Treatment. The typical options are: Accept, Remediate, Transfer, or Avoid. In our case we’ll mitigate the risk through some planned actions which we’ll call our Risk Treatment Plan.

The last major step now is to document our Risk Treatment Plan, in ISO terms, or simply, the tasks that we will take to mitigate the risk. Our risk treatment plan will be as follows:

• Create, review, and/or update all relevant information security policies
• Obtain management approval for all final policies
• Publish and communicate policies to relevant users
• Obtain user acknowledgement or acceptance of all relevant policies
• Implement a process for new hires to acknowledge and accept policies at time of hire
• Implement a policy to review, update, approve, and communicate policies at least annually

In order for this risk assessment to meet ISO 27001 requirements we need to assign a Risk Owner to each risk and obtain their approval of the risk treatment plan.

That’s basically it. You can get a lot more fancy with information like threats, mappings to specific assets or control frameworks, but we’ve covered the essential elements.

Working backwards from control sets such as the ISO 27001 Annex A is a great approach for organizations that are relatively new to formal risk assessment. I recently worked through the Department of Health and Human Services’ HIPAA Risk Security Risk Assessment (SRA) Tool, and it took a very similar approach, based on the HIPAA Security Rule control requirements.

There are various methods for assessing risk, this is a simple and straightforward approach to help you get started.

‍

{{cta_simple1="/cta-modules"}}

‍

About the author: Matt Cooper is Principal, Cybersecurity & Data Privacy on Vanta’s sales team. Matt has been with Vanta since February of 2021.

‍