Recently, we have dealt with our clients struggling with vendors in the vetting process. Particularly, tech vendors of any sort. There is a belief that SOC2 covers them for HIPAA. Many vendors have written off the HIPAA compliance requirements by simply saying “We are SOC2 compliant so you don’t have to worry about anything”. Often that is said by sales and management folks with a great deal of confidence. After spending some time at a recent HITRUST meeting I heard just how many people shouldn’t be so confident when making that statement. As with anything else the devil is in the details. What does SOC2 mean and how can you tell if that really means anything to you? Trust but verify is the key to answering that question for yourself.
SOC2 certification is not HIPAA compliance
In the meeting, I learned that the devil in both SOC2 and HITRUST certification has to do with the scope of the certification. Normally, one would assume that the scope would be the technology and policies of the organization itself. Interestingly, that is often not the case. Many comments were made in the meeting I attended relating to the importance of understanding the scope whenever anyone says they have SOC2 or HITRUST certification.
It turns out that more times than not, the scope is set perfectly narrow to allow for the certifications to be met. But, that doesn’t mean that the technology and policies of the organization were actually evaluated. At that moment, I vowed to more closely review the details of those SOC2 reports than I had in the past. Would you believe it! The very first one that came across my desk after that meeting was glaringly obvious that the scope really did make a difference. When a vendor defines the scope they get to pick and choose what parts of your company to include in this process plus what trust controls you think should apply to you.
First, this is a big problem with different vendors but often it comes from an arrogant IT firm. We have dealt with this type response many times. When asked to do a Business Associate Due Diligence Questionnaire (BADD), they sent their SOC2 report and the info on their generic HIPAA training from an HR/payroll vendor. Let’s take a quick moment to discuss that generic training that is so key to making them be completely HIPAA compliant. They had the required annual HIPAA training.
Then, we started to review the SOC2 report itself. My new commitment to review these reports in detail meant some time reading all those details.
First thing to note is the scope. This is a national company with smaller locations and partners around the country. SOC2 scope specifically says it only applies to activities that take place in their home office. Understandable, but my client isn’t in their home office area. They are in a whole different part of the country. What happens with people in other areas?
The big thing was a small statement that says since this tech company provides services to their customers they rely on the customers to meet certain “complementary user-entity controls” as mentioned in the scope. Here’s the rub, the assessment provided by the auditor clearly states that the organization’s controls in conjunction with those complementary user-entity controls is what makes them really SOC2 compliant:
the controls tested, which together with the complementary user-entity controls referred to in the scope paragraph of this report, if operating effectively, were those necessary to provide reasonable assurance that the applicable trust services criteria were met, operated effectively throughout the period
That would be fine and good if the user-entity actually knew they were responsible for making sure those controls were in place in order for the SOC2 to really mean anything. So what are those user controls that should be taking place?
BIG TECH COMPANY’s services are designed with the assumption that certain controls will be implemented by user entities. Such controls are called complementary user entity controls. It is not feasible for all of the Trust Services Principles related to BIG TECH COMPANY’s services to be solely achieved by BIG TECH COMPANY control procedures. Accordingly, user entities, in conjunction with the services, should establish their own internal controls or procedures to complement those of BIG TECH COMPANY.
The following complementary user entity controls should be implemented by user entities to provide additional assurance that the Trust Services Principles described within this report are met. As these items represent only a part of the control considerations that might be pertinent at the user entities’ locations, user entities’ auditors should exercise judgment in selecting and reviewing these complementary user entity controls.
1. User entities are responsible for ensuring that user IDs and passwords are assigned to only authorized individuals.
2. User entities are responsible for reviewing and approving initial client network configurations and communicate discrepancies to BIG TECH COMPANY in a timely manner.
3. User entities are responsible for reviewing network change email alerts for network changes and notifying BIG TECH COMPANY of inaccurate or unapproved alerts in a timely manner.
4. User entities are responsible for notifying BIG TECH COMPANY of network changes outside the scope of BIG TECH COMPANY’s maintenance.
5. User entities are responsible for communicating known, security, network, or service problems to BIG TECH COMPANY in a timely manner.
6. User entities are responsible for reviewing and approving the monthly and quarterly reports.
7. User entities are responsible for notifying BIG TECH COMPANY of additions, changes, or deletions to contact personnel.
8. User entities are responsible for providing BIG TECH COMPANY with client contacts authorized to act as escalation contacts and making decisions related to the client’s configuration items being hosted and/or managed by BIG TECH COMPANY.
9. User entities are responsible for physically securing network devices located at the client location.
10. User entities are responsible for assigning user functions creating end-user accounts and determining password settings for client-maintained applications and infrastructure devices.
11. User entities are responsible for developing their own disaster recovery and business continuity plans that address the inability to access or utilize BIG TECH COMPANY services.
Likely, all of this is buried in the SLA which is rarely seen by those responsible for these kinds of things in a customer environment. Plus, you know it wasn’t made a big deal or even mentioned when the contracts were being signed. I can assure you that my client had no idea they were supposed to meet this list of requirements to make their IT vendor be covered for their SOC2 certification.
The list itself isn’t so much the problem as the fact that it isn’t communicated in any direct and concise manner to the clients. They are just told you don’t have to worry about us in a very arrogant manner but they don’t understand clearly what their responsibilities are in the deal.
Here is the big issue. These tech folks think they have it covered and don’t have to really understand anything more about HIPAA compliance. Their clients, though, NEED them to understand it much more than this seems to show. If you don’t know that an investigation could ask for certain things that you must prove with documentation and provide it in 14 days how are they going to get it done for their clients.
There is much more to cover in the report. Little things here and there to notice such as how the auditor actually reviewed the information. The auditor activities are detailed here:
Auditor’s examination of the controls of BIG TECH COMPANY was limited to the Trust Services Principles and related criteria and control activities specified by the management of BIG TECH COMPANY and did not encompass all aspects of BIG TECH COMPANY’s operations or operations at user entities.
Our examination was performed in accordance with American Institute of Certified Public Accountants (AICPA) AT-C 105 and AT-C 205. Our examination of the control activities were performed using the following testing methods:
Inquiry – The service auditor made inquiries of service organization personnel. Inquiries were made to obtain information and representations from the client to determine that the client’s knowledge of the control and corroborate policy or procedure information.
Observation – The service auditor observed the application of the control activities by client personnel.
Inspection – The service auditor inspected among other items, source documents, reports, system configurations to determine the performance of the specified control activity and in some instances the timeliness of the performance of control activities.
Re-performance – The service auditor independently executed procedures or controls that were originally performed by the service organization as part of the entity’s internal control.
These reports, assessments, and certifications are supposed to make us feel safe working with our vendors. However, it is clear that trust but verify is becoming more important as vendors find ways to make you feel comfortable without necessarily doing the work you assume has been done.
What does SOC2 mean if you don’t review the report? Apparently, you can’t be sure. Clearly, getting into the details of any SOC2 or other ratings that should serve as a seal of approval will be a necessary evil to understanding the actual commitment your vendors are making when you are working with them. Trust but verify cannot be said enough.