SOC 2 reports are steadily gaining widespread significance in today's world of third-party assurance reporting, effectively breaking the mold of a one-size fits all standard that started with SAS 70 and continued with SSAE 16. SOC 2 audits, though initially overshadowed by SOC 1 SSAE 16 reporting, are becoming a viable "go to" reporting option for today's complex, growing, and ever-changing service organizations. As such, companies seeking SOC 2 compliance should take note of the following important points regarding the AICPA Service Organization Control (SOC) 2 reporting framework, provided by NDNB Accountants & Consultants, a nationally recognized boutique CPA firm providing high-quality, competitive fees for SOC 1, SOC 2, and SOC 3 compliance.
1. SOC 2 is about technology, not financial controls: A main reason for the advent of the AICPA SOC framework was to provide a need for reporting on the ever-growing technology oriented service organizations, such as data centers, managed services providers, ISPS, Software as a Service (SaaS) entities, and many others. While SSAE 16 is technically reserved for service organizations having a clear nexus with the ICFR concept – "Internal Control Over Financial Reporting" – SOC 2 is heavily geared towards technology companies. Learn more about NDNB's complimentary SOC 1 Policy Packets and SOC 2 Policy Packets. They truly make a big difference in helping service organizations save thousands of dollars on SOC compliance.
2. There are five (5) Principles. The SOC 2 reporting framework allows service organizations to use any one – or all – of the following five (5) Trust Services Principles for purposes of audit scope:
• Processing Integrity
From an audit scope perspective, it's important to discuss with your clients what their needs and expectations are, thus service organizations may only have to comply with one or two of the TSP's or possibly all five. Customers and prospects are becoming better versed on SOC 2, so expect a healthy and intelligent conversation on such matters.
3. SOC 2 is highly dependent on policies and procedures. That's right – take a look at the Trust Services Principles (TSP) and you'll quickly notice the requirement for what seems to be an almost never-ending list of operational, business specific, and information security policies, procedures, and more. Be prepared to develop such documentation if your organization is seeking SOC 2 compliance. Additionally, the same can be said of SOC 1 and SOC 3 compliance. In fact, it's fair to say that policies and procedures are a big – and getting bigger – part of regulatory compliance.
4. Two (2) Types of SOC 2. Technically, a service organization can opt for a SOC 2 Type 1 report or a SOC 2 Type 2 report. A Type 1 report is merely a snapshot or point time, such as a specific day, while a Type 2 covers an "assessment period", generally six (6) months.
5. SOC 1 vs. SOC 2. Much like a heavyweight slugfest, it seems as if these two (2) reporting options are going toe-to-toe, yet in all honesty, they each have their own place in third-party assurance reporting. If its technology related, SOC 2 is a safe bet, and if it's financially drive, then SOC 1 is the go-to reporting option.