We all know that cybersecurity has become a critical part of vendor risk management. In theory, a SOC 2 audit (which assesses a vendor’s security controls) is the way to assess those cybersecurity threats.

But in practice, that’s easier said than done. Yes, SOC 2 audits can address many different things, but cybersecurity risk evolves constantly. New data protection regulations keep coming. The roles vendors play in your business processes change all the time. And the consequences of a cybersecurity failure are only increasing.

That means the ability to scope a SOC 2 audit correctly has become essential for risk management teams.

So, how does that scoping get done, with such a slippery threat?

Begin with the principles behind SOC 2 audits

Let’s remember how SOC 2 audits came to be. They are based on five “Trust Services Principles” originally developed by the Association of International Certified Professional Accountants:

• Security
• Privacy
• Process integrity
• Confidentiality
• Availability.

So, when scoping a SOC 2 audit, the first question is: which principles apply to this vendor?

That question might seem self-evident, but consider what’s at stake. If you include too few principles (or the wrong ones), your enterprise is in a state of under-assurance—not enough controls for the security risks your vendors pose. Conversely, if you include too many principles, the enterprise is in a state of over-assurance—too much mitigation (and wasted resources), for risks you don’t actually have.

For example, let’s look at assessing a cloud-based data storage vendor. If you won’t be storing any personally identifiable information with that vendor, you have no privacy risks. That means you can keep that principle out of scope. On the other hand, if you’ll be storing confidential product plans, your security risks are high.

So, the foundation of any SOC 2 audit is to understand: what are we actually doing with this vendor?

Find your scoping partners

Another crucial step is to know who else in your enterprise should be involved in scoping a SOC 2 audit. Compiling that list is becoming more complicated, because vendors are increasingly providing more mission-critical services.

First, you’ll need to consult with the business process owners in the first or second lines of defense who will actually use that vendor. What service will the vendor provide? What company information will it touch? How do the employees want that relationship to work?

You’ll also need to consult with the IT security function because they are the subject-matter experts. They have insights about methods of attack, controls to test, and assurances that should be included in any final SOC 2 report.

Don’t forget the compliance function, either. They can tell you the consequences of getting cybersecurity or privacy wrong—the regulatory fines, litigation liability, or regulatory measures. They’re also the experts on security and privacy obligations.

For example, if you use a vendor to analyze consumers’ purchasing habits, and some of your customers are European citizens, then the EU General Data Protection Rule (GDPR) applies. In that case, the GDPR principles of availability (to see all data upon request) and process integrity (to be sure “delete all” does delete everything) become crucial parts of your SOC 2 audit. (IT security and business operations leaders might not know such GDPR nuances.) Read more about managing your GDPR compliance.

Build a durable process from there

So far we’ve talked about how to scope one SOC 2 audit. In the real world, risk management teams have two other tasks: you need to know what to do with a SOC 2 audit, and you need to build that into your vendor risk management at scale.

A SOC 2 report completed by an independent audit firm will give you a clear picture of the cybersecurity risk your vendor poses. It will call out the vendor’s security weaknesses, and the potential damage from a cybersecurity failure. From there, you can start to reverse-engineer the remediation steps needed to bring that vendor risk down to acceptable levels.

Now things might be familiar. Those SOC 2 audits, with their lists of weaknesses and remediation steps, can feed into a larger system of vendor risk management. That system should be one central repository of information, where security, audit, compliance, and risk functions can track progress on each vendor. Senior executives can use this to see a complete picture of your vendor risk management posture at any moment.

Those steps aren’t much different than what audit and risk teams have already been doing for financial audits and similar exercises. It’s about creating a single, trusted source of data; involving the right people to implement remediation; and reporting progress to senior executives.

What’s new is the need to sweep cybersecurity risk into your larger vendor risk management effort—and it begins with a clearly, thoughtfully scoped SOC 2 audit.

Cybersecurity risk isn’t going away, and vendor support will only increase. So, the more your internal audit function can build a sturdy, versatile capability to assess vendors’ cybersecurity risk, the better positioned you’ll be.