Not all risk assessments are created equal.
Some are low and others are high.
Yeah, that’s really helpful. Right?
Risk assessments are so crucial to information security that the American Institute of Certified Public Accountants (AICPA) requires them from every single company seeking SOC 2 compliance. SOC 2 Risk Assessments fall primarily under the Security (or Common) Criteria – which is the only required Trust Services Criteria. Regardless of what other SOC 2 Trust Services Criteria you select, you must complete a risk assessment.
With so much emphasis placed on risk assessments, and the amount of time an organization seeking SOC 2 compliance will need to spend on one, it’s worth getting one that will provide the biggest return on investment possible.
First, let’s take a look at what a SOC 2 risk assessment needs to be compliant.
SOC 2 Risk Assessment Requirements
SOC 2’s risk assessment requirements are scattered throughout the Trust Services Criteria guide. Most notably (but not limited to) Common Criteria 3: Risk Assessment.
1. SOC 2 Risk Assessments must have clearly defined objectives.
Risk assessments create value by guiding organizational decision making and helping them to identify risks that need to be addressed with one of the four risk treatment methods (Mitigate, Accept, Transfer, Avoid).
However, organization’s can’t make those decisions without first determining what their objectives for the program are. SOC 2 calls out a number of different areas that objectives should be established, most notably including:
Risk Tolerance Objectives: Organizations need to decide how much risk they are willing to accept, so they can decide how to treat the risks identified in the assessment.
Objectives for Operations and Financial Performance: Cyber attacks cost money and organizational time and risk tolerance is often tied to the financial loss that an organization is willing to accept. Treating risks also costs money and time. Management needs to balance decisions to reduce risks to fit their tolerance while allowing themselves to meet their financial goals (or updating their financial goals to allow for their desired risk treatment).
Reporting Objectives: How will the security, compliance, and management teams report the findings of the risk assessment?
Compliance Objectives: The SOC 2 standard, other cybersecurity standards, and many laws and regulations may establish their own requirements that the company must keep in mind and include in the risk assessment.
2. Risk Assessments must identify risks to the achievement of its objectives.
The risk assessment is not just completed by asking and answering “what cyber attacks are we vulnerable to?”
SOC 2 risk assessments are conducted by assessing risks against the organization’s objectives. In practice, this still includes a lot of “what cyber attacks are we vulnerable to?” but it means that the organization’s specific circumstances must be considered.
3. SOC 2 risk assessments identify and assess the criticality of information assets and significance of threats of vulnerabilities against them.
Each system an organization has and all of the data they store can be assigned a level of importance or criticality. For example, customer data is critical while marketing assets like logos or slideshow templates are somewhat less important.
A low-probability vulnerability is not particularly concerning if it only threatens low-value data. That low-probability vulnerability is hugely concerning if it threatens something critical such as patient health information.
This is one of the few areas that SOC 2 is prescriptive about its requirements. The compliance guidelines explicitly state the following.
“The entity’s risk identification and assessment process includes
- Identifying information assets, including physical devices and systems, virtual devices, software, data and data flows, external information systems, and organizational roles.
- Assessing the criticality of those information assets.
- Identifying the threats to the assets from intentional (including malicious) and unintentional acts and environmental events.
- Identifying the vulnerabilities of the identified assets.”
The common criteria also provides the following guidance for assessing the significance of the risks.
“The entity’s consideration of the potential significance of the identified risks includes
- Determining the criticality of identified assets in meeting objectives.
- Assessing the impact of identified threats and vulnerabilities in meeting objectives.
- Assessing the likelihood of identified threats.
- Determining the risk associated with assets based on asset criticality, threat impact, and likelihood.“
4. SOC 2 risk assessments include threats and vulnerabilities from vendors and other parties.
Every business today uses many different vendors for a huge variety of services. By using vendors, an organization is tying its security to theirs, especially if that vendor is storing or processing confidential data.
As such, all SOC 2 compliant companies will have a vendor management program and be expected to consider the risks posed by their vendors.
5. The business determines how to respond to risks.
There are four ways to address an identified risk. Despite being the most commonly thought of, “mitigate” is not the only option.
Risks can also be avoided, for example, by discontinuing the use of a vulnerable system or service. Risks can be transferred (this is what cyber insurance does), and risks can be accepted (do nothing).
Risk treatment is not usually mentioned in the risk assessment report. Usually, a risk registry is used to present a list of risks and the treatment option the business selects.
6. SOC 2 risk assessments consider the possibility of fraud.
As an organization of accountants, the AICPA is worried about fraud in all things. Their guidelines instruct organizations to consider that fraud could be committed in reporting losses, and particularly that fraud could be committed by using IT resources. Wire transfer fraud and credit card fraud are very common risks companies need to account for.
Internal fraud isn’t to be overlooked either. SOC 2 wants people to be able to blow the whistle at fraudulent activity in their organizations. Most companies create whistleblower hotlines to facilitate this.
7. SOC 2 risk assessments consider changes.
Change management is a common theme in the SOC 2 regime. Risk assessment is one of the many places it comes up.
New product lines, changes in leadership, system changes, new (or ending) vendor relationships, and even external factors all change the risks a business is exposed to.
SOC 2 risk assessments are updated at least once per year (assuming a 12-month audit period). Between the update periods, changes to the environment should be tracked, discussed, and action applied if needed. Businesses need to document these items to provide evidence supporting this requirement.
8. (If pursuing the Availability Criteria) Risk assessments identify environmental threats.
This requirement only comes into play if a business is pursuing the Availability Trust Services Criteria. It requires businesses to identify environmental threats such as inclement weather, fires, and water damage that could cause system or service downtime.
The Best SOC 2 Risk Assessment is a Quantitative Risk Assessment
There are two elements to determining the criticality of a risk: the likelihood of the event occurring, and the impact level the event would have.
It has long been a practice in cybersecurity to assign both of these elements with a rating of “low,” “medium,” or “high.” Sometimes “very low,” and “very high” or “extreme” are also used.
This does everyone in the organization a disservice. What does “low” or “high” even mean? This practice isn’t acceptable anywhere else in the business world. Imagine the accounting firm telling the CEO that expenditures are “high” this year. It communicates something but not enough to make any real decisions with!
A quantitative risk assessment transforms a “Low chance of a high loss” into “A 10% chance of a $1 million loss.”
This can further be defined as an expected loss of $100,000 (10% x $1 million).
Three example risks:
Risk 1: 5% chance of a $3 million loss. Expected loss: $150,000.
Risk 2: 15% chance of a $1 million loss. Expected loss: $150,000.
Risk 3: 25% chance of a $100,000 loss. Expected loss: $25,000.
How exactly does this help?
This type of language is simple and understandable by everyone at the business, and allows for much better decision making. Plus, a quantitative risk assessment will better help organizations meet the requirements of SOC 2 compliance.
In referring back to the above list of requirements, the quantitative risk assessment is particularly helpful in the following areas:
1. Clearly defining objectives: The quantitative risk assessment is particularly helpful for determining risk tolerance levels. Businesses can calculate their maximum acceptable risk in terms of expected losses.
3. Assessing criticality of the risks: As discussed above, the quantitative approach provides much more granularity and precision than simple “lows” or “highs.”
5. Responding to risks: What risks are worth mitigating, and which risks are worth accepting? The quantitative approach helps business leaders decide what approach they will take with each risk.
Risk 3 is the lowest expected loss, so it is the least important one to approach. Risk 1 and 2 are of equal value, so should be addressed first.
The effectiveness of risk treatments can also be considered.
If a security control used on Risk 1 can reduce its chance of occurrence to just 1% (expected loss of $30,000) while a security control on Risk 2 will only reduce its chance of occurrence to 5% (expected loss of $50,000), then you should prioritize the Risk 1 control which has a greater impact.
Not just for Compliance
All SOC 2 compliant companies must have risk assessments, but not all risk assessments are created equal.
A quantitative risk assessment will provide significantly more value to an organization by enabling better communication, smarter decision making, and higher returns on security investments.
If you’re going to put the work into a risk assessment for compliance anyways, wouldn’t you rather get a “high” one than a “low” one?
Want to get great cybersecurity content delivered to your inbox? Click here to sign up for our monthly newsletter, Tales from the Click.