If you’ve ever skied before, you might know that anything can happen on a mountain. It might be your first time on the slopes or you might have traversed a certain run hundreds of times, but all it takes is a little loose powder, a wayward stick, or even another skier in your way to have you eating snow and nursing bruises.
The same goes for a SOC 2 examination—having been a mainstay in compliance for decades now, it’s become almost a requisite for doing business. As such, many organizations think they know what they’re getting into, they think they’ve prepared, but something happens to derail their compliance hopes.
As SOC service providers for over 20 years now, we’ve seen it happen, which is why we’ve put together some insight to help you out. In this article, we’ll discuss four common challenges that often come up during SOC 2 examinations that can be avoided ahead of the start of your assessment.
With that understanding, plus our included tips for how to avoid these pitfalls, you’ll be in better shape to “ski” on down this SOC 2 mountain cleanly.
4 Problems with SOC Assessments and How to Avoid Them
Of course, every organization is different, and you may have some unique challenges pop up during your examination. But in our experience, these are the most common hurdles that foil companies seeking SOC 2 compliance.
1. Incomplete Understanding of the Scope
At its core, a SOC 2 examination is intended to provide assurance that your organization’s commitments to its customers have been achieved—that you keep your promises. This understanding—that it’s not just about system boundaries and software but your commitments—is critical to properly scoping your audit.
Whatever your organization promises related to your services is the point of the SOC 2 audit and so should be considered when determining the proper scope. So central is this point that it’s what your auditor opine will on—not on your security or your operations, but on whether or not your promises have been kept.
So, if you get this part wrong and focus only on controls, you put yourself on course for the very slippery slope that is scope contraction or scope creep, which is neither exciting or efficient. To avoid this, work with your auditor to understand the inventory of service commitments and system requirements your organization makes related to the service you deliver.
This need not be every promise or contract term ever made, only the “principal” or primary commitments made to your broad base of customers using the service—i.e., the greatest common denominator of service commitments. Once you do that, your auditor can then help you select the best categories to get started with—speaking of which, read on.
2. Wrong Report Type and/or Criteria Set
When you elect to perform a SOC 2, there’s a series of decisions you need to make in shaping the kind of examination you want, two of which are:
But in fact, many organizations don’t take the right tact with these, which can cause either delays or exceptions noted in their report.
Choosing Your SOC 2 Report Type
Knowing the difference in report types is important because which you choose will largely determine both the kind of assurance you’ll be able to provide and the level of effort involved from your internal team.
A more thorough Type 2 report is likely what your customers want to see, but it’s not wise to jump into that endeavor if you’re not sure you’re ready to be evaluated for control operation. A Type 1 (or a readiness report) is a great way to instead ease into SOC 2 compliance and figure out where your areas of concern are—that way, you’ll be able to shore them up before proceeding with your Type 2 examination.
Choosing Your SOC 2 Trust Service Categories (TSCs)
TSCs are the backbone of every SOC 2, but each organization selects which ones they want to be tested against, and sometimes they don’t make the right call.
Let’s get one thing out of the way—the Security category, or Common Criteria, is typically included in every SOC 2 (with few exceptions). But that’s because you’ve likely made a service commitment to securing data, and your other service commitments should similarly inform which of the other 4 categories to include.
Here are some questions to ask yourself in determining your other TSCs:
Did you agree to make your scoped system available/accessible to customers?
Did you agree to ensure the integrity of, say, transactions, your scoped system is making, or any other data stream processes it is involved with?
Is that data that is stored or moving through your scoped system designated as confidential or private?
(Regarding the last category of privacy, things grow even more complicated so read our more in-depth article for guidance there.)
The kicker is, even if you have made commitments in these areas, you aren’t required by the standard to include the related categories. It may benefit you to only include Security (and Availability, at most) to get your feet wet—in fact, it’s what we see happen a lot. Your included TSCs should be driven by your customer commitments, but if it’s your first SOC 2, then you have more flexibility to start slow, increasing your chances of no exceptions found.
3. Lack of Knowledge Regarding SOC Examination Expectations
When you prepare for any audit—no matter the type—it’s important to get your team into the right mindset so that they can gel well with the external team and expedite the process.
But more than that, you need to set expectations with your personnel as to what’s going to happen and what they’re going to need to provide as part of the assessment. Again, this could be made easier with a readiness assessment that would give your folks an idea of how it all works, but alternatively, you could also provide or seek out training in this regard.
Just don’t send in your staff virtually blind to an audit—that can create hang-ups that could delay your process.
4. All Necessary and Suitable Evidence Not In Place
Being prepared for a SOC 2 audit is about ensuring that you have policies and processes in place to meet the control requirements. But it’s not enough to have them in place—you must create and provide supporting documentation as well.
During the course of business, it’s common to focus on simply deploying useful new technology, which usually results in a process that meets your organizational needs but remains incomplete for audit purposes. In fact, documentation is a huge part of reducing risk, yet somehow it’s also often an afterthought—not just for SOC 2 examinations, but across the board for organizations seeking compliance against a number of standards.
Ahead of the arrival of your auditors, you’ll need to ensure your systems are well-documented—that includes things like solution architectures and network designs—and not only that, to remain in compliance, you’ll need to maintain and update those documents as necessary with the passage of time and introduction of change.
In not having all that ready to go for your external assessor, you risk non-compliance or—at the very least—exceptions in your report.
Achieving Complete Success in Your SOC 2 Examination
No one wants to be that skier everyone watches tumble down the mountain—it’s embarrassing, you risk injury setbacks, and it’s not the experience or memory you paid for when you shelled out for those lift tickets. SOC 2 reports are similar—you want to get through them successfully so your investment in compliance pays off and not have to return to your customers without the assurance they want.
Now that you know of 4 common challenges to avoid ahead of the start of your SOC 2 audit, reaching your goal of compliance and success is that much more likely.
To further simplify your SOC 2 journey, make sure you check out our other content that can deconstruct some of the complexities within this standard:
- Should You Get a SOC 3 or a SOC 2 Examination? Understand Your Options
- Vendors vs. Subservice Organizations: What’s the Difference?
- How to Perform a Risk Assessment Ahead of a SOC 2: 5 Steps
About the AuthorMore Content by Jordan Hicks