What is SOC 2 Type 1
If you are new to compliance, it’s easy to confuse SOC 2 Type 1 and SOC 2 Type 2. SOC 2 Type 1 is different from Type 2 in that a Type 1 report assesses the design of security processes at a specific point in time, while a Type 2 report (also commonly written as “Type ii”) assesses how effective those controls are over time by observing operations for six months. If that weren’t confusing enough, SOC 2 is different than SOC 1, which focuses on an organization’s financial statements and financial reporting. It’s also different than SOC 3, which reports on the same information as SOC 2, but in a format intended for a more general audience. This blog post will focus specifically on SOC 2 Type 1. You will also need to determine which report types best fit the needs of your company and customers.
For some background, both SOC 1 and SOC 2 stand for Service Organization Control and were created by the AICPA (American Institute of Certified Public Accountants). The SOC 2 standards come to us from the SAS 70 (Statement on Auditing Standards 70), which was an auditing standard for service providers. With SAS 70, a CPA firm reported on how effective an organization’s internal controls were. Eventually, organizations started using SAS 70 to attest that a third party vendor was secure, which was not the original intent. So in 2011, the Statement on Standards for Attestation Engagements no. 16 (SSAE 16) replaced SAS 70, and then SOC 2 became the standard to measure the effectiveness of an organization's security controls.
The first step in achieving SOC2 Type 1 is team formation. You will need an executive sponsor who will lead the project and help navigate the office political landscape, a senior person to help drive the project and IT/security leaders to ensure project adoption. You will also want an HR and legal resource to consult on designing and implementing policies.
It is important to note that pursuing SOC 2 is voluntary and not necessarily motivated by compliance or other regulations, such as HIPAA or PCI-DSS. Many SaaS and cloud computing organizations, such as IT managed service providers, want to demonstrate that they are properly protecting data within their data center and information systems. It is also common for customers (known as user entities in SOC terminology) to reach out to partners and request results from an auditor’s tests.
Once your team is formed, you will want to define scope. SOC 2 reports are based in the trust Service Principles (renamed to Trust Services Criteria in 2018) defined by the AICPA, and report on controls at a service organization relevant to security, availability, processing integrity, confidentiality and privacy. You will use these principles to guide and limit the scope of your audit. If your organization specializes in one particular service, perhaps only a small number of the Trust Services Principles will apply, and therefore your scope will be small. If your organization offers a variety of services, it makes sense to narrow the scope as much as possible. Work with your team to identify areas where the principles don’t seem applicable. It is common for service organizations to have separate SOC reports for the various services they offer.
Once scope is fully defined, you will write and refine policies. This is a large effort and needs to be led by someone senior on your team. The policies are intended to complement each other and create a system of checks and balances. You can avoid a lot of unnecessary technical work by rewording policies up front. We've created an open source template of SOC 2 policies and written about why.
At this point, you are ready for the implementation phase, which will identify many gaps you need to address with tools and procedures. Your goal during implementation shouldn’t be perfection. Don’t spend a lot of time arguing over policy details, but limit scope where you can and continue moving forward even if you have existing gaps. This phase shouldn’t take more than two months. You will also select a firm to conduct the audit, and when you have a good idea of when the implementation phase will be complete, you can get your audit on the auditing firm’s calendar. In the meantime, test the new procedures you’ve created and validate that tickets are being created and resolved appropriately. Additionally, ensure your new HR onboarding and offboarding procedures are being followed and documented.
When the specified date of the audit arrives, the audit team will commence testing, which typically includes interviews with staff, walkthroughs of your physical space and a thorough review of your documentation before the audit report is created. Then, the results of the testing will be compiled, and the auditor will work with you to clarify any necessary exceptions. Finally, the SOC 1 report will be generated.
In conclusion, SOC 2 Type 1 is a snapshot of an organization’s controls, and is a good starting point when working towards a SOC 2 Type 2, in which an auditor will assess the operating effectiveness of those controls over time.