How to Perform a Risk Assessment Ahead of a SOC 2: 5 Steps

This blog was originally published by Schellman here.

Written by Drew Graham, Senior Associate, Schellman.

When Alex Honnold scaled El Capitan in Yosemite without any kind of rope, his assessment of the risk was pretty simple.

Sure, he saw falling off the face of a mountain as a “high consequence” but he still considered his attempt as low risk. Why?

Because Honnold—an expert, professional climber—visualized his ascent, practiced individual moves, and rehearsed routes endlessly. He did all that so much that his definition of the risk he faced changed.

No, you're not climbing an iconic landmark with your bare hands. But when it comes to risk assessments ahead of your SOC 2 examination, the correlation is direct.

By definition, you cannot address your organization’s risk 100%. Neither could Honnold. After all, the nature of risk is the potential of uncertainty. But your risk assessment process can aid in preparation to yield a better audit outcome.

As SOC 2 assessors since the emergence of the SOC brand in 2011, we want to help you with this process of analyzing and documenting the threats and vulnerabilities that your organization and systems face.

We’re going to outline 5 steps to take so that you get what you need out of it ahead of your SOC 2 examination. After reading, you’ll have more direction on how to proceed so that you can best understand how your organization defines its risk appetite in the face of risk events.

SOC 2 Risk Assessments: 5 Steps

1. Define Your Objectives

Before you even start your risk assessment process, you should first define what the objectives are for the in-scope system or services.

Whether you provide software-as-a-service, managed services, or something else entirely, the “objectives” are exactly what you’ve promised your customers these services will do. These statements are commonly known as the Principal Service Commitments and Requirements or PSCRs, and they’re typically communicated through:

• Written agreements,
• Contracts,
• Service level agreements, or
• Published statements. (Like say, on your company website).

As the other part of your PSCRs, you should also clearly outline the in-scope system’s/services’ requirements you’ve communicated to your customers. These are the particulars about how the system should perform to meet those various commitments communicated to your customers.

Once you identify your PSCRs, those commitments and requirements should be the driving force that guides your risk assessment. Crucially, you must ensure they also align with the scope of your SOC 2.

For example, if your SOC 2 only includes the Security category, focus on those promises that your organization has made specific to the security of your service. Accommodate objectives for the other categories as well as you add them.

During your SOC 2 examination, your assessor will examine these PSCRs to understand what you evaluated in the risk assessment process as relevant to these defined objectives.

2. Identify In-Scope Systems

After identifying the PSCRs, your next step in your SOC 2 risk assessment process is to understand and identify what are the “in-scope” systems you will evaluate in the assessment, as well as what risks currently exist that threaten these systems.

To clear up any confusion, this is different than the in-scope service we mentioned in Step 1—the distinction between “service” and “system” is important here.

Because while we previously were referring to the entire service you provide customers as a whole, now we’re talking about the individual, “in-scope” elements that support that service.

You need to identify those critical components (or systems) that facilitate providing your service. That means specifying:

• Infrastructure and software;
• People;
• Procedures;
• Data; and
• Where the boundaries are encompassing the above.

Sometimes, depending on your scope, you’ll also need to identify any relevant subservice organizations as well.

For both steps 1 & 2, management is best suited for determining what are the objectives and system requirements for delivering the services.

If your PSCRs should guide your risk assessment, these systems are the ones you should include for actual evaluation. Hence why this is a critical step ahead of your risk assessment—you must understand this baseline of systems so you know exactly what to include (or omit).

3. Perform Risk Analysis

After determining the “in-scope” systems, now you’re ready to evaluate the risks those systems face. Your risk analysis process should follow a qualitative, quantitative, or hybrid approach.

You should consider a variety of factors when planning out your risk assessment, including:

• The personnel and experience of those performing the assessment;
• The timing; and
• The available resources.

During your risk assessment, ask these questions:

• What risk factors exist that should be included as part of the analysis?
• Are there internal or external threats, legislation, laws, or regulatory changes, fraud considerations, natural disasters, or changes in customer requirements that could impact the delivery of your services?

The goal of the risk assessment should be to identify:

• What risks exist that threaten the achievement of your objectives (recall Step 1); and
• What processes are (or are not) in place to respond to the identified risks.

This analysis process defines the basis for understanding how you should manage risks—you’ll also document this based upon risk severity or criticality levels.

For example, if a PSCR for your service is 99.9999% availability, you will need to assess the risk of not achieving that benchmark. Perhaps you assess the risk as low because you host the service in multiple availability zones and regions, utilize redundant architectures in both regions, and aggressively monitor system performance. The assessed risk could be higher or much higher if you do not utilize some or any of those strategies.

One risk that is sometimes overlooked within these assessments is the potential for fraud regarding the achievement of objectives. For SOC 2 risk assessments, you should include fraud analysis and evaluate that risk.

Remember too, that fraud does not have to be financially related. Other fraud risks include:

• Data theft fraud
• Fraud performed by an employee using the system
• Fraud that occurs as it relates to cybersecurity-related threats

Regarding Vendors in Your Risk Assessment

As the outsourcing trend continues, more and more organizations rely increasingly upon vendors and their services. If that sounds like you, you must have your vendors analyzed at least once per year.

For SOC 2 risk assessments, you must include services are necessary to achieve your PSCRs—that includes those provided by key vendors or business partners.

As you do with your internal systems, you must also analyze what risks exist with using those services as they relate to your stated system requirements.

During your analysis, consider:

• Do your key service providers have compliance reports that they issue annually?
• Are they being evaluated against your stated system requirements to determine if the service provider is meeting those?
• Are the vendors providing services or software? Far too often, vendor assessments focus only on the services provided by third parties and not the software, hardware and or technology devices. Make sure you request their SOC 1 or SOC 2.

These risk factors should be included as they could significantly impact your organization’s ability to meet your stated service objectives.

4. Document Risk Responses

With your risk assessment complete, you now need to determine the treatment plans in place for the analyzed risks. SOC 2 risk assessment requirements specify a need for the identification, selection, and development of risk mitigation activities for risks that arise from potential business disruptions.

Start with the results of your risk analysis and determine a combination of impact scores and likelihood scenarios. Then consider:

• Did the analysis result in risks that were accepted, mitigated, transferred, or avoided?
• Were there actions plans that required technology updated or purchased to mitigate the identified risk?
• Was there a control assessment performed to further understand the process to identify gaps?
• Do you have a what’s often known as a Business Continuity Plan or Disaster Recovery Plan in place that is tested at least once a year?
• Was cyber insurance purchased to help offset the monetary impact of a risk materializing?

Documentation of the risk treatment, action plan, remediation activity, or acceptance is critical. Not all risks can be eliminated, but your assessors will look for documentation regarding your level of comfort surrounding the stated process.

5. Stay Consistent

Remember that you should assess your risks on an ongoing process. Often, it’s the personnel intricately involved in the delivery of services that are the weakest link in information security. Consistent risk assessments will help keep you on top of any vulnerabilities among that element and others.

Overall, for SOC 2 examinations, a risk assessment should be performed at least once a year. If you’ve opted for a Type 2 report, you must assess your risk during the agreed-upon audit period.

Next Steps for Your SOC 2 Risk Assessment

If performed properly, a risk assessment can provide value to your organization beyond checking the box on the requirement for a SOC 2 examination.

You’ll not only understand the risks that threaten the achievement of the service commitments and requirements communicated to your customers, but you’ll also have identified, evaluated, and developed responses to the risks that threaten your critical systems overall.

Now that you have a basic game plan for the risk assessment, read our other SOC 2 content to ensure you’re as prepared as possible for your experience:

• What Does a SOC Audit Cost? 3 Big Factors That Will Affect Your Pricing
• How Long Will Your SOC Examination Take?
• Should You Get a SOC 3 or a SOC 2 Examination? Understand Your Options

About the Author

Drew Graham is a Senior Associate with Schellman & Company, LLC based in Tampa, Florida. Prior to joining Schellman and Company, LLC in 2016, Drew worked as a consultant for a big four company specializing in SOX IT audits. Drew leads and support various projects including SOC 1 and SOC 2 attestations. Drew has over four years of experience comprised of serving clients in various industries. Drew is now focused primarily on SOC reports for organizations across various industries.