The Fine Art of Scoping a SOC 2 Audit

Once upon a time, performing a SOC 2 audit was a rite of passage for service companies: “Wow, we’re so successful now that big clients want us to do important things, and we need a SOC 2 audit to prove our street cred!”

Times have changed. In today’s cybersecurity world, the SOC 2 audit is more like a fact of life: “Yikes, if we can’t pass a SOC 2 audit to document our security controls, nobody will give us the time of day.”

That’s no easy task for a small firm, and setting the scope of your SOC 2 audit correctly is crucial. Define the scope too narrowly, and you might not give the assurance your customers will want—prompting more SOC 2 audits in the future. Define it too broadly, and you waste money while disrupting daily operations to perform the audit.

So how do you strike that balance? And what role does the compliance or audit executive play in that task?

Start by remembering the logic behind SOC audits: for a service organization, they offer assurance about the strength of your security controls. (We had a long primer on SOC audits last month: the kinds that exist, how to prepare for them, how they unfold when the auditors arrive.) A Type I SOC audit confirms that your service organization controls are designed correctly at a certain point in time; a Type II audit verifies that the controls actually work for a set period of time.

OK, but “designed correctly” and “actually work” to do what?

Enter the Trust Services Principles—your first decision when scoping a SOC 2 audit.

 Finding Your TSPs

The AICPA established five core principles that a SOC 2 audit should consider when seeking assurance over a vendor’s security controls and financial reporting. They are:

  • Security. The system is protected against unauthorized access, use, or modification.
  • Availability. The system is available for operation and use to meet the firm’s commitments and system requirements.
  • Processing integrity. System processing is complete, valid, accurate, timely, and authorized.
  • Confidentiality. Information designated as confidential is protected per the firm’s commitments and system requirements.
  • Privacy. Personal information is collected, used, retained, disclosed and disposed to meet the entity’s commitments and system requirements.

Not every SOC 2 audit must consider all five principles. After all, these audits only go to specific clients (or prospective clients) your firm has, presumably with specific needs they want your firm to address. So deciding which “TSPs” satisfy your client’s concerns about security—that’s the key to determining the scope of your SOC 2 audit. Include only those TSPs that are necessary, and no more.

For example, if provide user entities data storage in a data center, and clients do all processing on their own systems; then you need to include the Security and Availability principles in your SOC 2 audit, but not Processing Integrity. If you store personal data about individuals, the Privacy principle is in scope. If you only store product design plans, the Confidentiality principle is in scope but the Privacy principle may not be.

Why Principles Matter

Identifying the relevant TSPs is so important because your next step is to determine which systems, policies, and procedures support those principles and organize your internal controls to match these needs. They will be what your SOC 2 audit examines. On a practical basis, that means SOC 2 audits covering multiple TSPs can sweep lots of your firm’s systems and controls into scope.

One starter question to ask is: “If we can’t guarantee this principle, does that harm our relationship with the customer?” If the answer is yes, then the principle is probably in scope.

Another important task at this juncture is to work with senior executives to define the firm’s products, services, and strategy as clearly as possible. Who are the target customers? What do they need? What service does your firm provide? What else will you provide in the future? The answers will define the TSPs your firm needs to provide to customers. That, in turn, will drive the scope of your SOC 2 audit.

Compliance and audit executives don’t need to answer those questions yourselves. You do, however, need to put them to senior management and insist: “We need to answer these.”

Scoping questions become more granular and company-specific from there. For example, you may want to start with a Type I audit before a more intrusive Type II audit. You might begin with “easier” principles such as Availability, before more complex ones like Processing Integrity. SOC 2 advisory firms (there are plenty of them) are more than happy to perform readiness assessments before a true audit gets underway.

The crucial questions are always: Are we clear on what our firm offers? And what do our systems have to provide for security and integrity, to uphold our end of that relationship?

These days, if you want to do any business at all, you’d better have good answers.