SOC 2 – which stands for System and Organization Control 2 – is a cybersecurity compliance framework that specifies how third-party service providers should store and process organizational and client data.
SOC 2 is part of the American Institute of Certified Public Accountants’ (AICPA) SOC reporting framework and utilizes the AICPA Statement on Standards for Attestation Engagements No. 18 (SSAE 18) standard. It is part of a “family” of reports that include SOC 1 and SOC 3, both of which we’ll discuss later in this article. AICPA designed the SOC 2 to address the needs of Cloud Service Providers (CSPs), including SaaS, IaaS, PaaS and XaaS developers, that store or process customer data in the cloud.
Despite the ubiquity of SOC 2 reports in the IT world, misconceptions and confusion abound regarding what SOC 2 reports are and are not, who should undergo SOC 2 audits and how to interpret SOC 2 audit reports.
The Five SOC 2 Principles
The SOC 2 framework centers around AICPA’s 5 Trust Service Principles:
Security – The CSP protects information and systems against unauthorized access, information disclosure and damage.
Availability – The CSP’s customers can rely on the CSP’s platform being available when they need to access it.
Processing Integrity – The CSP’s customers can rely on the CSP’s platform to process their data accurately.
Confidentiality – The CSP ensures that customer data stored and processed in the cloud cannot be accessed by unauthorized parties.
Security is the only Trust Service Principle that must be included in a SOC 2 audit. The other four criteria are optional, and in fact, it is rare for an organization to include all five. Instead, organizations limit their SOC 2 audits to the Trust Service Principles that are most relevant to the services they provide. A CSP’s SOC 2 auditor can advise as to which Trust Services Principles they should attest to.
SOC 1 vs SOC 2 vs SOC 3
The SOC 1 and SOC 3 reports are part of the same “family” as the SOC 2. IT and compliance professionals often talk about SOC “certification,” however in strict accounting parlance, all three types are “attestation reports.” This is because an organization’s management attests that certain internal controls are in place, and an independent CPA firm is brought in to audit the controls, verify management’s claims and issue a report that either agrees or disagrees.
The final result of a SOC audit is not a certification, but an attestation or, in plain language, an audit report.
With that out of the way, let’s look at the similarities and differences between SOC 1, SOC 2 and SOC 3 reports.
A SOC 1 report examines an organization’s internal financial controls. It is designed for organizations that provide financial services, such as accounting, payroll, collections or payment processing, that could impact their customers’ financial reporting. Unlike companies that undergo SOC 2 audits, these organizations may or may not offer cloud-based software as part of their services. SOC 1 reports assure customers that the organization is handling their financial information securely. Because SOC 1 reports contain detailed descriptions of the organization’s internal financial controls, they are highly confidential and shared only with business partners, investors and customers under a Non-Disclosure Agreement (NDA).
Conversely, a SOC 2 report is utilized specifically by cloud service providers and examines their internal cloud and data security controls. SOC 2 reports assure customers that the CSP has comprehensive cyber security controls in place to protect their systems and their clients’ data. A SOC 2 report contains detailed descriptions of the auditor’s control tests, test procedures, and test results, as well as the auditor’s opinion, management assertion and system description. Like SOC 1, a SOC 2 report contains highly confidential information and is shared only with business partners, investors and customers under an NDA.
A SOC 3 report can be thought of as a scaled-down version of the SOC 2. It examines the same Trust Services Principles, but it is far less comprehensive. A SOC 3 report contains the auditor’s opinion, management assertion and system description – but not detailed descriptions of the auditor’s control tests, test procedures or test results. Unlike SOC 2, SOC 3 is considered public information and can be handed out freely. Organizations commonly put their SOC 3 reports on their websites to showcase their commitment to AICPA Trust Services Principles.
Here’s a table for quick reference:
|Public or Private?
|What It Contains
|Who Gets One
|Highly confidential - shared only under NDA
|Detailed description of internal financial controls that could impact customers’ financial reporting
|Companies that provide financial services, such as payroll, collections agencies and accounting firms
|Highly confidential - shared only under NDA
|Detailed description of internal security and/or availability, integrity, confidentiality and privacy controls related to customer data stored in the cloud
|Cloud service providers, such as SaaS, IaaS, PaaS and XaaS platforms, data hosting or processing and cloud storage
|Public information - can be shared freely
|Scaled-down version of a SOC 2 report; does not contain detailed descriptions of internal controls or other sensitive information about the company
|Cloud service providers that want a compliance report they can place on their website or otherwise share publicly
SOC 2 Type 1 vs SOC Type 2
Organizations can choose between two types of SOC 2 audits, Type 1 and Type 2. Both audits use the same Trust Services Criteria and involve the same rigorous examination of an organization’s attested controls by a CPA. Both audit reports contain highly confidential information about the company’s systems and are shared only under NDA.
However, a SOC 2 Type 1 audit provides a snapshot of an organization’s controls at a single point in time, while a Type 2 audit examines how well they operate over a period of time, usually six to 12 months.
For this reason, SOC 2 Type 1 audits are most appropriate for organizations that haven’t had formal security controls in place for very long, such as young startups launching new products. Essentially, a Type 1 report demonstrates that the organization has controls in place but has not yet tested how they work over the long term. Type 2 demonstrates that the organization has tested their controls over a period of time and proven that they work.
Do SOC 2 Reports Expire?
No, SOC 2 reports don’t expire, but most organizations consider them stale after 12 months.
How to interpret SOC 2 report dates – especially for Type 2 audits – is a source of much confusion among IT professionals. This confusion stems from the difference between the SOC 2 Type 2 “coverage period,” displayed on the report’s cover page, and the report issue date, found at the end of the report’s first section.
As discussed in the previous section, SOC 2 Type 2 reports are far more complex than Type 1 reports, because Type 2 reports are only generated after long-term audits; the average SOC 2 Type 2 audit takes six months to complete. Further, the auditors can’t begin their work until the coverage period has ended. For these reasons, the end of the coverage period can be anywhere from several weeks to several months prior to the date the audit report is issued. As an example, a SOC 2 Type 2 report with a coverage period of December 1, 2022, through November 30, 2023, may not be issued until the spring of 2024.
Therefore, the “date” on which the 12-month clock starts ticking is the audit report’s issue date, not the end of the coverage period.
Understanding SOC 2 Report Results
The auditor’s opinion, or the “result” of the SOC 2 audit, is another source of confusion among IT professionals, primarily because the CPAs who perform SOC 2 audits use accounting parlance to describe their findings.
There are two possible finding types:
Unqualified Opinion – While it may seem counterintuitive, in the SOC world, an “unqualified” opinion is a good thing! It means that the auditor found that the audited controls were designed and operating effectively overall. In other words, the organization “passed” the audit. The overwhelming majority of SOC 2 Type 2 reports are Unqualified.
Qualified Opinion – In the SOC world, this is very bad. A qualified opinion means the auditor found a material description misstatement or material deficiency in the design or operation of the organization’s controls. In plain English, the organization “failed” the audit.
Note that while an auditor will always specifically point out if the result was a Qualified Opinion, they won’t always specifically use the term “Unqualified Opinion.” Instead, they’ll state something to the effect of “all controls were designed and operating effectively.”
Therefore, when examining a vendor’s SOC 2 Type 2 report, ensure it does not include the phrase “Qualified Opinion.” As long as that phrase is absent, all is good – although the auditor may have found some small discrepancies, which will be outlined within the report.
Why SOC 2 Is Important
Third-party vendor breaches – where threat actors target a service provider to compromise data belonging to one of their customers – are a top concern for organizations. In addition to damaging the organization’s reputation and opening them up to liability from their customers and business partners, regulations such as the GDPR can also hold organizations accountable if their vendors suffer a data breach. Requiring CSPs to provide SOC 2 Type 2 reports helps organizations prove that they exercised due diligence when selecting those vendors.
SOC 2 Type 2 audits also benefit the cloud service provider directly:
- By complying with AICPA Trust Services Principles, organizations can improve their information security processes, close gaps and prevent data breaches.
- Regular SOC 2 audits provide CSPs with a competitive advantage. While SOC 2 reports are not mandated by any law, in today’s marketplace, organizations expect their cloud service providers to undergo SOC 2 Type 2 audits at least yearly.
How To Comply With SOC 2
The AICPA Trust Services Principles don’t give organizations step-by-step instructions on how to secure their systems and data, nor do they recommend specific software solutions. Instead, they provide cloud service providers with a list of end goals, and CSPs are free to choose the appropriate technologies and/or processes to achieve those goals. For this reason, SOC 2 “compliance” looks different in every organization.
In general, complying with SOC 2 Security Principles involves ensuring that robust procedures and controls are in place for systems access, change management, systems operations and risk management, including proactive controls to protect customer data. These may include controls such as the following:
Least-privilege access controls: Employees are only given access to the systems they need to perform their jobs and no more.
Role-Based Access Controls (RBAC): Employees are granted systems access according to their roles within the organization. For example, a marketing manager doesn’t need access to the company’s security systems.
- Ensuring that employee systems access is turned off as soon as possible when employees leave the company.
- Encryption of customer data both at rest and in transit, preferably using a zero-knowledge encryption architecture, which ensures that the cloud service provider cannot access plaintext customer data.
- Comprehensive password security controls, including requiring that employees use complex, unique passwords on every account and store them in a password manager, and that they enable Multi-Factor Authentication (MFA) on all accounts that support it.
The Bottom Line
While SOC 2 audits are voluntary, most organizations that want to buy cloud services consider a SOC 2 Type 2 report to be a minimum requirement for potential CSPs. Further, most organizations require their CSPs to produce fresh SOC 2 Type 2 reports at least annually, especially if the CSP is providing a critical service.
Keeper® was the first enterprise password manager to undergo a SOC 2 Type 2 audit, and we have undergone SOC 2 audits at least yearly since. Additionally, Keeper’s platforms can help other organizations meet SOC 2 requirements related to password security, Identity and Access Management (IAM) and Privileged Access Management (PAM).