Since its start in the '90s with SAS 70, the SOC 2 report has become a global standard for examining and determining the suitability of organizational controls. SOC 2 provides a framework for organizations to measure and attest to the effectiveness of controls critical for protecting the security, privacy, processing integrity, and availability of PII and critical data systems.
Building a SOC 2 program ensures management focuses on the security, privacy, processing integrity, and availability of information systems. Completing a SOC 2 audit goes a long way to building trust with your customers and partners.
Timeline:
1992 – The Statement on Auditing Standards No. 70 (SAS 70) emerged from the American Institute of CPAs (AICPA). The standard focuses on controls necessary to maintain security, availability, processing integrity, and privacy. SAS 70 quickly became the universally accepted standard for auditing IT service organizations.
2010 – The Statement on Standards for Attestation Engagements no.16 (SSAE 16) is issued, replacing SAS 70.
June 2011 – SSAE 16 becomes effective. Organizations that relied on SAS 70 move over to SSAE 16. Like ISO 27001, SSAE 16 implemented for services organizations specifies an auditing method versus a specific set of technical controls. The standard allows organizations to choose customized control solutions while relying on auditor analysis and interpretation expertise.
2017 – AICPA introduces the term System and Organization Controls (SOC). SSAE 16, superseded by SSAE 18 for reports after May 2017, divided the standard into three separate reports SOC 1, SOC 2, and SOC 3, providing better options across industries.
How did SOC 2 come to be so well regarded in the industry?
Dating back to 1887, the AICPA, with 431,000+ members in 130 countries, is the world's largest CPA member organization representing the accounting profession in many business areas, including IT services companies.
SOC 2 is a report that a CPA must issue. The standard is not a set of specific rules. It is a framework providing the auditor a methodical approach to evaluating security and privacy controls based on the organization's stated scope and business objectives.
SOC 1, specifically designed for financial institutions, evaluates controls for financial reporting. SOC 1 reporting can help service organizations comply with Sarbanes–Oxley's controls over financial reports.
SOC 2 uses the Trust Services Criteria to evaluate the security and privacy controls of services organizations. SOC 2 audits build on the five trust principles of the TSC. SOC 2 audits generally include the security principle by default plus one or more of the other trust principles. During the Truvantis workshop, an organization decides which criteria are essential based on its business objectives. As of 2017, all SOC 2 reports are based on the SSAE 18 standards.
SOC 3 is considered a general use report. It is like a redacted SOC 2 report and gives enough information to attest to a level of compliance without including all the proprietary details contained in a SOC 2 report. Companies needing a publicly available attestation report can post SOC 3 reports on their website, for instance.
Type 1 reports represent the evaluation of controls at a specific date and time. It does not include any testing or controls or monitoring effectiveness.
Type 2 reports include validation of controls over a stated period. In addition, type 2 reports include the auditors' descriptions of effectiveness testing and results.
In the inclusive method, the subservice organization's controls are in scope and evaluated same and the primary organization. This method includes full descriptions of subservice controls and their management assertion as to control applicability.
More common is the carve-out method, where the subservice organization leverages its own SOC 2 or equivalent reporting. The carve-out method includes a description of the services provided, the required CSOCs, and the description of the organization's processes under audit to monitor the subservice organization.
The SOC 2 or 'SOC for Service Organizations' report evaluates controls relevant to maintaining the data management system's security, privacy, confidentiality, availability, and processing integrity. It is intended for use in response to governance, risk and compliance inquiries, executive management oversight, and demonstrative due diligence. There is considerable flexibility for customization in the SOC 2 framework, and report formats vary across auditors and organizations. The report is typically segmented into five sections, each with its distinct responsibilities.
The independent auditor's report is the summary opinion of the CPA performing the audit. This section describes the scope of the auditor's examination, the auditor's responsibilities, a description of the system under review, the relevant Trust Services Criteria, and the auditor's overall opinion as to the effectiveness of the controls given the business objectives. If the report is a type 2 audit, the auditor will also describe the period, testing methodology, and summary results.
The auditor may also describe things not tested. For example, the scope of the audit may not include an examination of the multi-factor authentication solution. In this case, the auditor will state their assumption that the MFA solution is sufficient to satisfy the TSC or the user entity controls requirements.
This section contains the facts and assertions made by management regarding the suitability of the information management system controls. The management's assertion section summarizes the system under audit, TSCs used subservice organizations, CSOCs and CUECs, and the exam period. Management confirms why based on their best knowledge, the controls in place are suitable to meet the business's service commitments and system requirements.
The system description section renders details of the system, including scope, boundaries, controls, and related contractual and statutory commitments. In addition, it includes the services the organization provides and its primary obligations and requirements.
This section may also contain management philosophy of relevant aspects of the control environment, including security policies and management, personnel and physical security, change management, monitoring, disaster recovery, and risk assessment.
System Elements:
Infrastructure describes the hardware platform infrastructure. For example, infrastructure could talk about the number and types of servers running and their physical location, networked, and employee access points such as VPN gateways.
This subsection talks about the chain of software used by the information management system from the OS to off-the-shelf and proprietary software and user interfaces such as web apps, APIs, and communication stacks.
This section describes all the organization's employees, their job functions, and how they interact with the information management system. The people section also describes any utilized system monitoring and metrics, documentation, and training programs.
This section describes critical procedures related to managing the information system. The procedures section can include detailed methods for data classification, system monitoring, maintenance, and incident response.
Data the data section includes customer data, transaction data, reports, system files, and error logs.
This subsection details any cyber-attacks or other system incidents suffered during the examination period. In addition, it includes details of the incident(s), the organization's response, and mitigating control changes put into operation.
In the introduction of this section, the auditor details TSCs relevant to the report and defines their meaning concerning the information system at hand. The body of this document section is typically a four-column table summarizing:
Auditor's Test of Controls Example Entry:
Trust Services Criteria for the Security Category | Description of Service Organization Controls | Auditor's Test of Controls | Result of Tests |
CC6.5 The entity discontinues the protection of physical storage devices only after destroying the ability to retrieve data from those devices. |
Formal device disposal procedures are in place. |
Inspected device disposal procedures to determine they were in place. |
No exceptions noted. |
Before removal from the facility, all storage devices are degaussed and sanitized. |
I examined a sample of destroyed media to determine that sanitization measures are applied. |
No exceptions noted. |
'No exceptions noted' is the best grade you can get on SOC 2 reports. One or more exceptions do not necessarily degrade the overall opinion of the report. Instead, the auditor will root cause the exception and consider whether the system continued to meet its service commitments and requirements.
No exceptions noted' is the best grade you can get on SOC 2 reports. One or more exceptions do not necessarily degrade the overall opinion of the report. Instead, the auditor will root cause the exception and consider whether the system continued to meet its service commitments and requirements.
Section five is open for any additional relevant information management wants to add to the report. Typical use is for management response to exceptions.
Complementary subservice organization controls (CSOCs). These are controls that must be in place by a subservice provider for the organization under audit to meet its TSC objectives. For example, an organization that uses a data center colocation service may require that the service provider provide physical security with restricted access controls and environmental monitoring with fire suppression capability.
Complementary user entity controls (CUECs) are necessary controls combined with the service organization's controls to meet the stated control objectives. For example, requiring employees to use smart cards for physical access and strong authentication to log in are CUECs.
SOC 2 certification involves a rigorous auditing process of an organization's controls based on the principles of security, privacy, availability, and processing integrity. SOC 2 certification assures partners and customers that a service provider can satisfy their security and privacy requirements as a world-recognized standard.
The AICPA has recognized that many organizations are under pressure to communicate and report on their ability to prevent and detect data breaches. In response to the market, in April 2017, the AICPA introduced a framework establishing a common language for cybersecurity risk management description and control criteria. The SOC for Cybersecurity Framework provides a way for companies of all sizes to take a dynamic, proactive, and agile approach to cybersecurity risk management and communicate those activities to their customers and stakeholders.
The framework is made up of three components, description criteria, control criteria, and CPA attestation guidance. The description criteria help management explain its cybersecurity program in a clear, consistent manner. The control criteria give CPAs a common way to attest to the effectiveness of cybersecurity controls. The framework is flexible to accommodate and support compatibility with other industry security frameworks that the organization may use, such as NIST, ISO/IEC 27001/27002, or SEC cybersecurity guidelines. Finally, the attestation guide assists CPAs in examining and reporting on an organization's cybersecurity risk management program.
While both the standard SOC 2 report and the SOC for cybersecurity can provide insight into an organization's cybersecurity controls, some key differences exist. A SOC 2 report is meant for a qualified set of users based on a need-to-know. The SOC for Cybersecurity examination report is designed to meet the needs of a broad range of users.
SOC for Cybersecurity | SOC 2 | |
Purpose |
Provide general users with an understanding of an organization's cybersecurity risk management program in order to make informed decisions. |
Provide specified users with information about controls related to the security, availability, processing integrity, confidentiality, or privacy of a service organization's ability to meet service level assurance. |
Intended Users |
Management and a broad set of general users, including analysts and investors whose decisions may be impacted by the health of the organization's cybersecurity program. |
Management and specified parties who have a sufficient understanding of the service organization and related information systems. |
Cloud service providers have requirements for higher levels of attestation and must complete multiple certifications in parallel. Companies face the challenge of managing compliance costs and avoiding the painful disruption of conducting multiple rounds of security audits. Businesses need a single program and a single report capable of covering overlapping security standards.
Examples of industry groups with overlapping cybersecurity criteria:
A few years ago, the AICPA expanded the flexibility and utility of SOC 2 by introducing what they term "additional subject matters and additional criteria" dubbed SOC 2+. In addition, SOC 2+ includes additional criteria that align SOC 2 with valuable cloud service IT security requirements. As a result, a SOC 2 + program increases the utility of your report and helps manage compliance costs and efforts.
Subject Matter | Critical | Example Audit Function |
Description of the physical characteristics of a facility |
Completeness Accuracy Third-party criteria |
Report on the completeness and accuracy of physical descriptions. Report on organizational controls relevant to facility security and trust services criteria for security. |
Historical information related to system availability |
Completeness Accuracy |
Report on historical data relevant to SLAs in addition to trust services criteria on availability. |
Compliance with privacy policies |
Statement of privacy practices |
Report on the organization's compliance with privacy policies in addition to trust services criteria on privacy. |
Compliance with HIPAA security requirements. |
HIPAA security requirements Title 45, Sections 164.308-316 |
Report on compliance with HIPAA security regulations and organizational controls suitability and effectiveness based on the criteria.
|
How an organization addresses the CSA Cloud Controls Matrix. |
Cloud controls related to security at a cloud service provider. |
Report on the suitability of controls based on the Cloud Controls Matrix and the trust services criteria for security. |
Examples of additional criteria business cases:
The AICPA, in collaboration with the Cloud Security Alliance, developed the STAR program based on the CSA's Cloud Controls Matrix. STAR assists CPAs in reporting on the suitability and effectiveness of controls, maintaining security and availability of data in the cloud.
The Payment Card Industry Data Security Standard (PCI-DSS) affects any entity that stores, processes, or transmits data for any of the cardholder brands that are part of the Payment Card Industry Security Standards Council (PCI-SSC). Each cardholder brand (e.g., Visa, Mastercard, American Express, Discover, and JCB) defines guidelines on what is required to achieve compliance validation. Each cardholder brand defines merchant tiers that directly map how an entity must validate adherence to the PCI-DSS standard. To deliver validation consistency across brands, the PCI-SSC has introduced multiple programs including standardized self-assessment questionnaires (SAQ), report on compliance (ROC), and attestation on compliance (AOC). The payment card brands determine what process each affected entity must follow to validate that PCI requirements are met. Also, the PCI-DSS has introduced programs to approve qualified third-party security companies to assist affected entities meet their PCI-DSS requirements. Two helpful resources in this are qualified security assessors (QSA) and approved scan vendors (ASV). Although the task of meeting PCI-DSS may seem burdensome, it is necessary to combat today’s threat of data breach of cardholder data. When trying to navigate the landscape of PCI-DSS compliance, especially for entities that process large transaction volumes, it is important to develop a strong relationship with a qualified security assessor (QSA).
Acronyms
CPA – Certified Public Accountant
MFA – Multi-factor Authentication
SAS – Statement on Auditing Standards
SSAE – Statement on Standards for Attestation Engagements
SOC – Service and Organization Controls
TSC – Trust Services Criteria