Misconceptions in SOC 2

#SOC2 gets a lot of attention these days.? With that, there tend to be some common misconceptions out there that I will address in this article. I’m going to try to keep this as a “living” document, where it can be updated, added to, etc., so if you know any more, feel free to add some comments!??

Let the fun begin (in no particular order):

1. “Compliance” or “Certification” - SOC 2 is a reporting framework and NOT a compliance framework. This means that there are no set MINIMUM “standards” or “requirements” for SOC 2. Without getting into all the details, SOC 2 has criteria that need to be met. The client explains how they meet that criteria, the auditor validates if what the client says is suitable and operates effectively to meet the criteria.?For example, SOC 2 will have a criteria for mechanisms to protect against unauthorized access. A client may say they have 6 character passwords in place. Great practice? Not in my opinion, but can be validated by the audit. Thus, SOC 2 is satisfied because it’s “reporting” on what’s there. Other frameworks will require minimum standards (maybe 12 character passwords with complex characters required).?This all means that saying things like “SOC 2 compliant” or “SOC 2 certified” are not technically correct.?
2. “Trust Service Principles” and “Service Organization Control” - this is old terminology. Trust Service Principles was replaced with Trust Service Categories years ago.? Similarly, Service Organization Control was replaced with System and Organization Control. If someone (especially a CPA firm/auditor) is using old terminology, are they up to date with the current standards?
3. “Points of focus are requirements” - the points of focus are included in the same document as the AICPA Trust Services Criteria, which SOC 2 is measured against. As a result, people will often think the points of focus are the minimum standards or requirements for SOC 2 (hint - see #1 above). To simplify, the purpose of the points of focus are basically guidance on how a client MAY meet the criteria of SOC 2. They serve great purpose as examples, when a client is first setting up their control environment, or if an auditor is doing a SOC 2 gap analysis. But they are not requirements.?
4. “Vulnerability scanning & pen testing are required” - this relates to #3 above.? Vulnerability scanning and pen testing are mentioned in the points of focus as a means to monitor the control environment, but there are other ways to do that (and meet the related SOC 2 criteria).? So, like the points of focus, these are good practices, but NOT requirements.
5. “2 weeks for SOC 2” - a marketing line often used by technology firms that want you to buy their product. Their technology may be able to speed up the SOC 2 process, but 2 weeks (while technically not impossible), is unrealistic for almost all SOC 2 engagements. Auditors have a set of requirements to conduct these engagements, which requires planning, conducting testing (even if a tool is used - it just changes the type of testing being done), and reporting (including a quality control process). It’s these elements that differentiate CPAs as some of the highest-quality individuals for reporting out there, and it takes time.
6. “The? AICPA is in charge of everything SOC related” - not true. It’s easy to want the “bad guy” to blame when problems arise. While the AICPA has a lot of involvement in SOC (for example, developing the trust services criteria), they are NOT the ultimate legal authority. Reality is SOC engagements are attestations, and those engagements are covered by whatever State Board of Accountancy that the work is being performed in. The State Boards also oversee CPA and CPA firm licensing, and also ultimately control the peer review process. The AICPA can?be involved in the peer review process via their peer review program, which facilitates the process between CPA firm, peer reviewer, and State Board. The AICPA can also investigate ethical violations, via their hotline.
7. “AICPA-accredited auditors” - see #6 above. The AICPA is a membership-based organization. While the AICPA has certificate programs, the CPA’s license itself is provided by the relevant State Board of Accountancy.?
8. “The AICPA collects money for SOC engagements” - false. The AICPA is a membership.? CPAs are not required to be members to have a public practice (which includes SOC engagements). If the AICPA collects money, it would be for membership dues, and (voluntary) participation in its peer review program to help facilitate peer review.
9. “My IaaS provider has SOC 2, therefore I don’t need it” - that’s great if you’re a SaaS and you are using an IaaS hosting provider that has SOC 2?for your application. But you only inherit certain controls from them that help you meet the trust services criteria (for example, physical and environmental controls).? It’s still up to you to meet the rest of the trust services criteria for your own SOC report.
10. “SOC 2 is bullsh*t” or “SOC 2 creates a false sense of security”- Poor quality SOC 2’s have led to this, but SOC 2 is one of those things where you will get out what you put into it (or garbage in garbage out as well). If you have a high-quality security program and a good CPA firm performing the engagement, the quality of that SOC 2 report is going to be very good and very useful for readers. If you see a poor quality SOC 2, do something about it! Push back on the organization that provided it. Maybe they will enhance their program or find a better auditor to help produce better quality reporting. If you see something so egregiously bad, report it to the AICPA hotline.
11. “SOC 2 meets data security standards that reduces the risk of data breaches & cyber attacks” - see #1 above (there are no prescribed data security standards for SOC 2). I don’t disagree that a good, quality SOC 2 can help reduce risks (by striving for a good program/report), it’s not a guarantee that a cyber attack won’t work. Newsflash - nothing can guarantee that.
12. “Microsoft is no longer accepting SOC 2 reports (which indicates reduced confidence in SOC 2 reports)” - this is related to Microsoft’s SSPA section J of the DPR (specifically relating to personal data - privacy) and that it is based on an international standard, where ISO certifications were a better fit. Reality is probably closer to something like this: it was easier for Microsoft’s security team to review 1 page standardized ISO certificates than to comb a bit more through every SOC 2 report making sure it hit the right privacy criteria for their DPR (as well as the results of the report - opinion, exceptions, etc.).?