Updated: Sep 20
What is risk management?
How do you implement a risk management process?
The most common control gap observed in SOC 2 and ISO 27001 readiness assessments, is the lack of a defined and established risk management process. It’s a concept that is somewhat counterintuitive to tech startups, where risk-taking has been a key component of their success.
A well-designed risk function is about supporting the organisation's objectives, not hindering them. It’s a way to consciously accept or even pursue the risks that support those objectives, and avoid or reduce those that don’t.
What is risk management?
Risk management is an intuitive practice. When we look before crossing the road, or stay indoors during a storm, we’re managing the risks in our own lives. It’s the same concept when operating a business.
One of the common examples of this is with vendor risk management. Software startups choose vendors like AWS and Microsoft Azure because they have an industry-leading reputation, a long history of strong performance, and provide comprehensive and flexible services that can adapt to evolving needs. Ie. They are chosen because they are lower risk.
The theoretical practice of risk management is that you: (1) Identify, (2) Assess, (3) Treat, (4) Monitor, and (5) Report, your risks. Standards like SOC 2 and ISO 27001 require an established and defined approach to managing risks.
How do you implement a SOC 2 risk management process?
A risk function can come in all shapes and sizes. We’ll take a look at the core components that should be present in every risk process, in one form or another.
SOC 2 Risk Management Framework
The policy or framework sets out the purpose, responsibilities, and key requirements of the risk process. There are many templates available online, although it's often best created in-house to ensure it's fit-for-purpose and gets buy-in from important stakeholders.
The responsibilities and key requirements of the risk process relate to how the purpose of the risk function is achieved. How risks are identified, assessed, monitored, treated and reported to support the objectives, including the responsibilities related to them.
There should be a risk assessment criteria to be used as a common language to rate and compare the risks. This is usually a matrix of Likelihood and Impact, which in combination, define a risk rating. There are many cookie-cutter templates available through a quick Google search ("risk assessment matrix") to avoid re-inventing the wheel. However, the scales used need to be tailored to each company reflect the operating environment.
SOC 2 Risk Register
The Risk Register is a log of all the identified risks. It records key details from the risk assessment including the risk ratings, the means of mitigating each risk, the residual risk after considering those mitigations, and any planned actions or risk mitigation strategies to address each risk (as applicable).
A useful template for the Risk Register that also addresses other aspects of the risk management framework is available here.
SOC 2 Risk Assessment Process
The Risk Assessment Process (RAP) can take many forms. The important thing is that it brings together the relevant information and people to conduct an effective review of the risks. The assessment should consider:
> Company objectives: These set the context for the risk identification. Risks threaten the achievement of one or more objectives;
> Operating events: Incidents, problems, service desk requests, bugs, vulnerabilities, customer complaints, HR issues and vendor failures can all identify new risks or highlight existing risks are more prevalent or important to consider;
> Changes: Changes in the operating environment, personnel, vendors, product and services, can all identify new or emerging risks; and
> Observations: Any observations raised from independent reviews, monitoring of the controls, external audits, or other external feedback.
These items can be considered by using formal inputs to the RAP. This may be logs with the above items, or simply by including the relevant personnel with awareness of these items. In either case, the objective is to ensure all the relevant risks are identified and can be accurately assessed.
The RAP should be conducted at least annually. Quarterly, or even monthly, helps embed the process and a culture of risk management from a more frequent cadence.
The RAP should involve or report into an appropriate level of management to approve the final list of risks (risk identification), risk ratings (risk assessment) and mitigation strategies (risk treatment). This covers the first three parts of the risk management practice and inherently covers the remaining areas of monitoring and reporting if the key stakeholders are directly involved in the process.
SOC 2 Risk Monitoring and Reporting
In the simplest of risk functions, the risk monitoring and reporting can form part of the RAP. By including executive management and even the Board in the RAP, there is direct oversight.
In other cases, periodic reporting to the top level supports effective governance of the risks. It typically wouldn't include all the detail of the risk register or risk assessment process. It could be a 'Top 5 Risks' view, reporting new risks for awareness, or reporting Key Risk Indicators (KRI's).
Key risk indicators tell a story of the underlying risks in the company. For example, this may include things like the number of incidents, open vulnerabilities and departing staff. These can give a high-level view and health check of the company performance and risks. It allows the executive management and Board level audiences to determine whether further investigation or action is required and whether there are trends that may indicate an emerging area for concern.
Pulling it all together
Risk management processes can vary in many ways, but the core components and principles are the same. The key to success with a risk management process, is effectively embedding and integrating it. It should be holistic and enterprise wide, with buy-in at all levels of the company.
When it is applied effectively, it supports the achievement of company objectives. It allows measured and conscious decisions around where to prioritise risk mitigation efforts. It can even be used to support risk taking in pursuit of objectives, which can open up new opportunities.
In large companies there can be many components and layers of responsibilities and steps for managing the risks. In small companies, there may simply be a quarterly workshop that is supported by a risk management framework and a risk register. What's most important is the culture of risk management and strong engagement of those responsible for risk management.
Read our other posts for further insight into SOC 2:
