Anonymous Feedback on SOC Reports

I put up a form yesterday for anyone who would like to provide their opinions about SOC reports, and the following are the results so far.  I will continue to update this page as the results come in.

If you have not spoken your mind yet, please take a few minutes and do so here:







Questions for Everyone:
1. What do you think about the launch of SOC reports? Who was responsible for the [SAS 70 has been replaced by SSAE 16] spin on the AICPA's announcement that [SAS 70 was replaced by SOC reports]?
·        New name, same old thing
·        The AICPA is responsible.
·        The industry itself. People were looking to create an easy explanation. CPAs explained to their clients that "next year, we'll be doing a SOC 1 instead of a SAS 70." The CPA may have had an engagement letter that lasted for SAS 70s until 2011, 2012, etc. and they explained to their clients what the difference was. But I think there is a direct linkage between the SAS 70 morphing into the SOC 1. Although I don't think there was enough promotion from the AICPA that mandated CPAs to more thoroughly examine and define ICFRs. Even allowing for CPAs to utilize judgment, an ICFR risk assessment may be a helpful tool that is required as part of audit documentation to demonstrate the reasons the auditors are concluding that a control is or is not an ICFR.
·        Good step in the right direction over SAS 70 reports ,but there still needs to be refinement.
·        This is more confusing for the non-compliance IT professionals than the SAS70s. Like it or not most senior IT executives I am familiar with expect there to be one report that covers everything. They understand it better if I say privacy controls are not covered instead of saying there is no SOC 2 report.
·        As a organization that previously completed a SAS 70 and now completes a SSAE 16, we received most of our information from our auditing firm (one of the big 4) and they did an excellent job of explaining the move and purpose.
2. What do you think the effect of this spin has been on the marketplace?
·         Confusion
·         Zero change, everyone is going out to get SOC 1, 2, and / or 3 attestations. Large accounting firms are gouging the market, again.
·         I am not aware of any "spin," per se. What I see is that people were expecting a SAS 70 last year and found out from their CPAs that SAS 70 is no longer a standard. I think from the get-go, SSAE 16 was seen as a replacement for SAS 70. I think the AICPA needs to take control of the use of these reports and clearly define their use/misuse in order to prevent market demand from dictating how they are used/misused.
·        Marketplace as a whole, not significant. Clients are starting to ask for either a SSAE 16 or a SOC 2 but in the end, 90% of all clients looking for these reports are just trying to check a box for their regulators. Until the regulators that are requiring organizations to check the box provide more guidance on what what the appropriate audit report should be things aren't going to change significantly.
3. How do you think the market missing the opportunity to adopt SOC2 for assurance regarding security and availability in the first year of SOC reports will affect it in the coming years?
·         Haven't seen our auditors talking much about it... nor our customer's auditors. And if they don't, our management doesn't care.
·         SOC2 is more prescriptive than SAS 70, so it is better overall. Not a lot of people jumped, but many organizations are demanding the SOC 2 from their service providers this year, therefore not much missed.
·         Unless there is a major change, the market momentum is in the direction of the SOC 1 being the report used/demanded. The SOC 1 is cheaper and less rigorous. If a company can hand over a SOC 1 and generate new business/close the deal, the SOC 1 is a document valuable for that use. The market will eventually demand those reports and if someone hands that same business lead a SOC 2, the lead may say "what is this? Where is the SOC 1?"
·         I think it will take the companies receiving the reports to pressure the vendors to include a SOC 2 report.
·         In the long run, I don't see the lack of adoption year 1, 2, or even 3 being significant. They are options available and it will take time for the market need to reach a point before organizations, particularly vendors, will take set aside the effort to adopt the correct report type(s). Unfortunately this is a catch-22 situation, vendors won't move unless clients ask/tell them to and clients won't know to do so until another force compels them to ask.
4. What are some of your personal experiences with regard to these reports?
·         We use Soc 1 and everyone is happy.
·         There are a lot of CPAs looking for IT / CISAs and similar to help interpret the SOC 2 and SOC 3, and even more IT firms looking to hire a CPA so they can sign off. I wish everyone would go NIST, HITRUST, etc. and leave the financial side to SOC1.
·         They are being rampantly misused and misunderstood.
·         I think about 25% to 50% user control considerations make no sense and you wonder if they are reviewed by anyone before the report is produced.
·         Coming from an organization that has historically done SAS 70s and being moved over to SSAE 16 last year, we are now just starting to assess what report type we really should be on based off the services we offer. The problem is, most of our clients don't even know truly why they need a report (i.e., checkbox compliance) so asking them what they want they can't decide. I think the two things that need to happen to get people onto the right reports is, 1) the audit firms having a frank conversation with their clients and making it know the report type they currently have isn't best suited for their needs. 2) the regulatory bodies that be, that require organizations to collect "audit reports" need to provide better guidance on what the appropriate type of audit report is based off services in-scope.

Questions for User Entities:
1. Why do you think service organizations that used SAS 70 to provide assurance regarding security and availability gravitated to SSAE 16 instead of SOC2?
·         Because that's what people were asking for
·         Most of our clients didn't feel they had another choice. Also, SOC2 is more specific. SAS 70 was nebulous. Many companies that had breaches and financial compliance issues had passed a SAS 70 with flying colors.
·         Because under SAS 70 they were allowed to include whatever controls they wanted. This is partiality the fault of the auditing firms for allowing organizations to include non-ICFRs under SAS70 and then also allow those same clients with those controls to automatically roll into a SSAE16. Further, since they were allowed to include controls such as security and availability that are non-ICFRs and allowed to roll into a SSAE16 there was no need to undertake the effort to convert over to a SOC2 that likely would result in them needing to test against more controls due to the defined criteria which didn't exist under SAS 70/SSAE 16.
2. Do you think SOC2 reports provide sufficient assurance regarding security and availability? If not, how do you supplement the report?
·         We use SOC1
·         No. It is still too high level. I would use NIST, HITECH, ISO2007, etc.
·         Not sure.

·        All depends on the audience receiving the report. if they are an organization that is small or has a loosely governed Information Security Program themselves then it is likely fine (i.e., they use checkbox compliance). Any organization that is significant in size, typically requiring they have a stricter, more defined Information Security Program themselves will be more critical of what controls they feel are needed because in the end, SOC 2 or not, organizations need to ensure their vendors have controls implemented that are equal to the controls they have implemented themselves.


3. What advice would you give other user entities?
·         Do what your customers are asking for and not a bit more. Deal with security as a secondary function to compliance.
·         Use common sense for your industry, size, and purpose. Do the right think to make sure you are secure and defensible in your actions. Don't take the easy way out by doing the minimum necessary, no matter the control paradigm.
·         Try to get a copy of the report and review the control gaps and UCCs with senior management before the contract is signed.
·         Make it clear to your vendors if  the service they offer you impacts your financial statements and if so, why.  If they don't have an impact to your financial statements (or at least not a direct one), do not ask for or accept a SOC1 from your vendor. Instead, push them on providing a report that speaks more directly to the controls you feel are relevant to the service they are offering you (security, availability, process integrity, etc.).
Questions for Service Organizations:
1. Why do you think customers that requested SAS 70 to provide assurance regarding security and availability requested SSAE 16 instead of SOC2?
·         Because that was what their upstream auditors were asking for (our customers are banks)
·         They either thought they had no choice or their clients/customers required them to do so.
·         Because they either don't know the difference or they know the difference but the SSAE 16s they are providing include all the controls they feel are reliant to their service, even if those controls aren't ICFRs.

2. What do you think about SOC2? Do you think that the Trust Services Principles and Criteria are adequate to provide assurance regarding security and availability?
·         I think it's okay but haven't actually been through one yet.
·         No.
·       Yes/No. It is better than nothing, but in the end, the adequacy of it is all dependent on the implementation by the service provider. Service providers get to craft their own controls and determine the scope as it pertains to those controls so you are always going to run into reports that although they are exception free, do not truly represent their environment.
3. What advice would you give other service organizations?
·         Investigate specifically what the customers want and do that.
·        Start having discussions with your clients to better understand why they are asking you for a report. From there, determine if the report you are providing them is best suited to address their needs.

3 comments: