Hi everyone, here are some SOC report related questions and answers that you may find interesting. These were asked during a Third Party Risk Management Bootcamp hosted by Venminder last week. The team thought it would be beneficial to share here. Chime in if you have further answers or comments to any of these. The event was three days, 6 sessions and 11 presentations long, covered by nine experts. If you're interested in viewing the recordings, you'll find the link on the Program Improvement library page.
Q: The SSAE18 is not something that should be asked as the third party sets the scope of the report and may not cover the services you are contemplating on purchasing. Do you agree?
A: Respectfully, I disagree – I believe that any level or source of information can be a resource into a further line of questioning. I can tell you many times that I have used an SSAE 18 or its predecessors of SSAE 16 or SAS 70 and uncovered a line of questions to ask that I would not have otherwise previously contemplated.
Q: You mentioned reduce workload. Is that possible with a template in mind for IT/InfoSec?
A: Venminder does not have an available SOC review template, but we do perform SOC analyses where we pull out key information and provide it in a consistent way. (Contact Venminder to learn more)
Q: When discussing SOC reports, the presenter said the testing period should be no more than how many months after the last reporting period?
A: Testing periods will meet with no gap typically for organizations that choose to do 12-month audit periods. Some organizations choose 3, 6- or 9-month testing periods and those could have any size of gap in between, but typically 3- or 6-month periods mean the organization is doing more frequent, short-term audits and there usually isn't a gap between audit periods for the following audit. For 9-month periods, we see many organizations just leave the remaining 3 months out of audits. There isn't anything "wrong" about this, but you should insist on obtaining a bridge/gap letter for the 3-month gap between periods. A bridge/gap letter should also be obtained if the 3- or 6-month reports have a gap between periods. A SOC report, especially for longer term audits, may take up to 3 months to be released externally.
Q: For companies in the EU, they typically only provide the ISO 27001 1-page certificate. Given that the SOC 2 is sometimes designed around the ISO 27001 framework, is the ISO 27001 sufficient enough to accept as a third party audit?
A: An ISO 27001 certificate is a great start, but not where you should stop. You'll want to ensure the certificate is still valid, the certificate will have an expiration date and you'll also want to pay close attention to the scope stated on the certificate. Make sure that the systems you care about at the vendor are in scope. As you know, where the SOC 2 shines versus the ISO 27001 is that you get to see the actual testing performed by the auditors, the results of those findings and managements response to any findings. All of this is giving you insight into how the control environment works within your vendor.
Still try to gather other due diligence documents when possible such as information security, physical security, resiliency and BC/DR documentation.
Q: Should we be asking for the SOC for Cybersecurity report from our core processor (Fiserv)? I know that we should continue to ask for the SOC 2.
A: Vendors will likely not have the SOC for Cybersecurity audit performed unless enough of their clients ask that they do. We look at many Fiserv SOC reports and have not seen a SOC for Cybersecurity from them, which isn't surprising as I mentioned during the webinar that we have not seen any yet and auditors have informed me that they have not performed any or heard of their peers performing any yet. I would not say that you "should" ask, but I would encourage that you enquire about whether they have one or are looking to have one performed. If you do find out, I would be interested in their answer.
Q: How do you determine when a vendor should have a SOC report available for review? Is there an official list of the types of vendors that undergo these reviews?
A: This is a question we see a lot. SOC reports are not required to be performed for any organization. It typically comes down to three things:
- Cost justification; not only the cost of the audit itself, but the preparation and continual management of the control environment
- Control environment maturity
- Are they losing sales because they do not have a SOC audit?
A SOC 1 audit is commonly used to satisfy a SOX 404 requirement for financial control environment audits, so those organizations are most likely to ensure they have a SOC 1 audit performed annually as their clients (hopefully) contractually require it.
Q: What type of credentials are necessary to conduct a SOC for Cybersecurity report?
A: As these are issued by the AICPA, these stick to the same requirements as SOC 1, 2 and 3. Only CPAs can issue a SOC for Cybersecurity. I would have liked to have seen a CISA/CISSP combination as a more qualified auditor, but that is not the case.
Q: How important is it to have evidence that your vendor accepts complementary user controls of their third parties such as data hosts?
A: This comes down to your fourth party due diligence requirements. How important it is to you depends on your risk appetite and regulatory environment. We've seen a couple vendors actually include notes or control references to their subservice's SOC report, which hopefully will catch on. We always recommend looking at critical fourth parties as many times they are the data center or cloud service provider who are of course responsible for much of the operational resiliency in many cases.
Q: Are you starting to see more HiTrust reports? How do they compare to SOC reports?
A: We have only seen a few SOC 2+'s with HiTRUST out of the 1000+ unique we see each year, so we did not see an uptick for the 2018 reports. It will be interesting to see how the 2019 reports go.
Q: We don't accept SOC reports as the vendor dictates the controls being tested. How do you recommend addressing this gap?
A: SOC reports are still better than a questionnaire or documentation covering the same controls as they are tested by an external audit firm. Venminder touches on this issue in an upcoming blog post; as how I like to phrase it, not all SOC reports are created equally. Some vendors do include very detailed controls while others choose to take a more relaxed approach with their controls, leaving room for interpretation for the auditors and introducing uncertainty to user entities. Most organizations aren't going to have PCI-DSS or ISO 27001 certificates, and with those, you don't get the insight into the control environment that a SOC report provides.
Q: Is a SIG Lite or SIG Full a satisfactory replacement for a SOC report?
A: A SIG is a good resource to gather information about whether a vendor states they have certain controls in place. A SOC report not only states that the controls are in place, but an external auditor has also performed testing against those controls to verify that they're in place and operating effectively, for Type II reports. Every vendor will tell you in a SIG that they remove access upon termination. A SOC will tell you whether they really are, as the auditors will compare HR and logical access records usually also looking at the length of time it took to remove the access as well. This is the most common exception on SOC reports.
Q: What are the opinions for SOC reports?
A: Here are the four types of opinions for SOC reports
- Unqualified – Although this sounds bad, it's the best news you can hear when discussing SOC report opinions. It means that the auditors did not need to state that a control objective was not implemented or operating effectively. There still can be a number of exceptions or findings within unqualified reports.
- Qualified – This is where the vendor had at least one control objective not implemented or operating effectively.
- Disclaimer – These are used when there isn't any evidence to prove or disprove that a control wasn't being performed or was in place. This happens often on controls that surround hopefully rare occurrences, such as communicating incidents to clients.
- Adverse – These are bad. This means that the vendor held back or modified information needed to verify controls were either in place or operating effectively.
Q: I find that SOC reports often contain controls that are outdated, don't meet today's best practices – especially for information security – or are too generic. Are these reports even useful?
A: This is a great point. The cause of these issues is due to the vendor's ability to create/design their own control activities. Here is an excerpt from an upcoming Venminder blog post. The value is decided by you, as you'll see in control examples below, one control would be more valuable than the other, yet cover the same trust services criteria. As I hint on below, some reports will be more valuable than others:
One aspect that many users of SOC reports don't know is that it's the organization being audited, your vendor, that writes and designs the controls, not the auditor. There are guidelines and the auditors will assist as needed, but the depth and scope for how the question is written is done by the vendor. For example, a password control could be simply written:
- "Administrative access to the company's LAN is authenticated via user account and password."
or be as complex as:
- "Administrative access to the company's LAN is controlled by Windows Active Directory, requiring unique user IDs and passwords. Complexity settings require passwords to be at least 12 characters long. Password history is set to 24. Passwords must be Changed every 30 days and users are locked out after five failed login attempts."
Have this in mind the next time you're looking through control activities. Due to this flexibility I've had to say this a lot over the years, "SOC reports are not created equally." This is one reason why having SOC's reviewed by an information security or third-party vendor expert can be extremely valuable.
Third Party ThinkTank