Moving Beyond Checkbox Diligence with SOC Reports

Transcript

Damon Silver
Principal, New York City

Welcome to the We Get Privacy podcast. I'm Damon Silver, and I'm joined by my co-host, Joe Lazzarotti. Joe and I co-lead the Privacy, AI, and Cybersecurity group at Jackson Lewis. In that role, we receive a variety of questions every day from our clients, all of which boil down to one core question: how we handle our data safely. In other words, how do we leverage all the great things data can do for our organizations without running headfirst into a wall of legal risk, and how can we manage that risk without unnecessarily hindering our business operations?

Joe Lazzarotti
Principal, Tampa

In each episode of the podcast, Damon and I are going to talk through the common questions we're getting from our clients. We're going to talk it through the same way we would with our clients, with a focus on the practical. What are the legal risks? What options are available to manage those risks, and what should we be mindful of from an execution perspective? 

Today, we're joined by Eric Ratcliffe. Eric is a partner and Director of Compliance Strategy at 360 Advanced, based here in Florida. We brought Eric to the program to discuss something companies are struggling with: understanding their systems and organizational controls, and the reports that outline the system and organizational control framework in their organizations or in their vendors' organizations. We're going to get into some basic issues to understand what a SOC report is, and we're grateful that Eric is here to help us do that. 

Eric, thanks so much for joining us today. We really appreciate it.

Eric Ratcliffe
Director of Compliance Strategy at 360 Advanced, Inc.

Thank you, Damon and Joe. Looking forward to talking a bit about SOC 2 and its history, and to answering any questions that come up from your clients and prospects.

Lazzarotti

I know 360 Advanced does a ton of SOC audits of various types. That expertise will be really helpful for us today. To start off with, help us understand what is a SOC report? What are we talking about when we say SOC and SOC type one and type two? Give us a sense of that.

Ratcliffe

What's interesting about it is that it seems to be a relatively new thing. It's grown so fast over the last 3 to 4 years, but it really started almost 30 years ago. The AICPA, which really governs reporting, built this again 30 years ago. Back then, it was called SAS 70. About 15 years ago, it was revamped and renamed SOC (service organization controls). Really, the purpose is to produce a report that helps organizations define the systems and controls in place to protect customer data and meet industry best practices.

A lot of times, I'm asked, well, who needs it? Even us as a CPA firm, we do one on an annual basis. We're actually hiring a competitor to audit us, because at the end of the day, it's really for any vendor handling customer data. That's where it really draws the line – it's typically B2B interactions, not necessarily a B2C environment.

Silver

Eric, what's prompting you, and what's prompting the customers you work with, to go through this process? Is it just a matter of them trying to be really proactive and get out ahead of managing risk, or are they receiving requests specifically for their SOC type two report, for example, in connection with an engagement they're trying to get? What's the impetus for doing this?

Ratcliffe

It's kind of all the above. I've probably had 3,000 conversations with organizations over my 15 to 17 years at 360 Advanced. I've seen many of them; they know it's a go-to-market requirement. We even have some small SaaS startups that know that, say they're selling into the financial services industry, many of them will have to do PCI. They'll have to do a SOC report before they put any customer data in there. In that situation, it's just a must for a go-to-market strategy.

In the majority of cases I'm speaking with, it's a contractual requirement. Before they transact any information in their systems, their customers will require a SOC 2 in place before that data starts flowing.

Lazzarotti

When you think about those different use cases for SOC, one of the things that I'm curious if you're seeing this as well, one of the things that happens in our world, for example, recently that, and we may have talked about this Eric offline, but the DOL put out some guidance saying that any fiduciary to an ERISA covered plan has to assess the cybersecurity of their vendors, the service providers that provide services to those employee benefit plans. It’s the same type of vendor assessment that you would do even outside of an ERISA plan context. The idea is that the company now has this mandate as a fiduciary for their plans, and they go out, and maybe one thing they get from their vendor as part of that assessment process is a SOC. If you're not in the space like you are, that really understands what it is that they're getting. Help us understand if you're sitting in that position as a fiduciary, how might you want to look at that? How do you look at that SOC and say, what are three things I should look at to say, is this valuable to me and what I'm trying to accomplish by assessing the cybersecurity of this particular vendor looking at the SOC that they give you? What are those things that they should be asking about?

Ratcliffe

It's a fantastic question because what we find is that, unfortunately, these reports get passed out, and basically, it's a check we received. I'd say larger organizations with a more savvy vendor due diligence and security team are going through that report. Some of the things I think everyone should, at a minimum, review are to ensure the scope matches the services you are purchasing from that organization. You think of some large organizations that may do several different types of services. Let's just look at a data center, for example. Some data centers may offer just cooling, AC and security, but they also offer managed services where they put their hands on the keyboard or the equipment. What happens is that some of those SOC reports only cover the co-location piece. If you are there using them for managed services, that's where you want to make sure the scope is not just co-location; it extends out into the managed services side. That's one of the big ones. Make sure the scope matches the service.

Then, also look at the trust services criteria. I know we haven't gotten into what the components of that SOC report are, but there are what are called trust services criteria that used to be called categories. Those are security, availability, confidentiality, processing, integrity, and privacy. At a minimum, an organization must include security. Then why add the others? Again, it's about the data and the type of service. If you're passing a PII through that system, you should probably expect or ask for them to include privacy. If not, security may just meet the needs of the services.

That's part of understanding the scope and the boundaries are covering what you care about. In addition, I would say to look at the testing procedures. It should not just be an inquiry. There should be some type of test that's going on. Ensure the test is appropriate for your risk appetite. Then, if there are any gaps, are the remediation plans noted in the report? The report should really give a good description of that organization's security posture at the end of the day.

Silver

Eric, quick follow-up on that. Does the report make note of items that were flagged for remediation the prior year, and what steps have been taken to actually act on those? Is that something that's covered?

Ratcliffe

No, not typically. In most cases, you think about these reports, and Joe asked about the difference between a type one and a type two report. The type one is a point-in-time snapshot. That's what most organizations will start with. When they go to type two, that's when it covers a period of time.

Damon, really, the way to answer that is, it depends. If that control had raised exceptions or failures during that period, there could be a section outlining what happened, why the exception occurred and the remediation steps taken to implement corrective actions for that failed control or exception. The answer depends on when that remediation took place. If it was within that audit period, then yes, they would have an opportunity to explain how and when the exception was remediated.

Lazzarotti

Is it fair to say, Eric, are you seeing this, suppose a company receives a SOC from a vendor and the report is dated six or eight months, maybe 12 months prior to the date that they receive it, and that during that time, there might have been some pretty significant changes in the governance, the leadership, the technology that that particular vendor's using. Do you see recipients of these reports who are evaluating a vendor go back and say, okay, we need you to update this. In your business, do you do updates or some type of way to fill that gap in the report between when it was done and when you looked at it, which may even be before the date of the report and the date that the company is getting that representation of the stock of that organization?

Ratcliffe

The AICPA has also created a deliverable, the AUP, for agreed-upon procedures. It was a few years ago, and one of our clients had an incident, and their largest customer asked us to come in and retest the controls that had failed and caused the incident. In that case, we followed AICPA guidelines and retested the areas that the exceptions could have, let's say, occurred or caused the incident. Then, we were able to report on that as a point in time to show that, hey, the controls are now operating as intended.

Silver

You made an interesting point earlier, Eric, about ensuring the SOC report's scope matches the services the customer is receiving. Would it typically be the case that all services offered by a vendor are covered in a single SOC report, or might there be multiple reports aligned with different lines of business and the services the vendor offers?

Ratcliffe

We do, at times, give recommendations to separate reports. Again, thinking of very large organizations, I have one organization that we actually issue 32 different SOC 2 reports. It's a very large organization, but the reports' readers are, in most cases, different. In this situation, it's in the education space, where they have reports, say, on teacher certifications. Then, they may have another one that's a certification for professional services. They may have a report for healthcare certifications. The person who's reading the healthcare doesn't care about the education. At that point, again, it's lining up the scope, understanding the boundaries of the systems. If the systems are really segmented like that, it often makes sense to run separate reports. What happens is that when you start putting many services, and many different ones, we call them business units, in one report, it muddies the report. It makes it hard to follow and hard to understand what, actually, those boundaries are that the services are providing you. It can also create some risk for the organization that has completed the SOC report, because an exception from one business unit could negatively impact the entire report. That's a really good observation. 

Again, I always say it depends on who the reader of the report is. If they're totally separate readers, you may want to consider doing separate reports.

Lazzarotti

Eric, this has been really helpful for our listeners and for us. A good place to wrap up is that this is obviously a changing environment. I know you mentioned that some older standards have been replaced by the SOC process. Maybe there are some things coming up that we should know about. 

Can you give us some trends you're seeing in SOC utilization, and maybe how we're thinking about this from an AI perspective? Is there SOC development for AI? Can you talk a little bit about that, what we're going to see going forward?

Ratcliffe

This is the first time I've been on a call that's lasted this long without dropping the word' AI'. It’s obviously the hot topic right now. What we are seeing and preparing for is how to address that risk. We're hearing Rumblings that AI CPA is working on something, and nothing has been published or issued at this moment.

With that, the ISO, the International Standards Organization, now most people are familiar with ISO 27001, but that really wasn't addressing AI risk. What we're seeing now is that there is ISO 42001, or 42001, which is really geared toward AI, whether you're a user or a creator of AI. That is what we have been doing, really a lot of discovery calls, getting started on some new projects around ISO 4201. 

Then, NIST has also created its own RMF. That is another product that helps address AI risk. 4201 seems to be the predominant one we're seeing.

Lazzarotti

It seems like there'll be a lot more to come from the standpoint of these reports and how companies are using them. This has been really helpful to give our listeners some insights into that.

Eric, thank you very much for joining us today. We really appreciate it.

Ratcliffe

Absolutely. It's been a pleasure and happy to help any of your clients.

Silver

As always, for our listeners, if you have any feedback or suggestions for future episodes, you can email us at privacy@JacksonLewis.com.