A Complete Introduction
What is SOC 2?
The American Institute of Certified Public Accountants (AICPA) developed its Service Organization Controls (including SOC 2) as an auditing procedure to assist service providers in managing data securely in the cloud to protect client privacy and their own organizational interests. SOC 2 compliance is a minimum security requirement for SaaS providers.
For SOC 2, five trust service principles provide the foundation for managing customers’ information: security, availability, processing integrity, confidentiality, and privacy, explained in detail below. Each Trust Services Criteria (TSC) is further divided into Points of Focus which may include a combination of security controls or links to such controls. AICPA lists all critical TSCs and their Points of Focus online.
Because SOC 2 was created to ensure secure data management in the cloud, it applies to almost every SaaS company, as well as any business that stores customer data in the cloud.
What is SOC 2 Compliance?
Only cloud vendors needed to meet SOC 1 compliance requirements until 2014. However, SOC 2 requirements today demand that any company storing customer data in the cloud minimizes risk and exposure to that data.
SOC 2 compliance is one component of the Service Organization Control reporting platform from the American Institute of Certified Public Accountants (AICPA). SOC 2 refers to both the technical audit process and the requirement that businesses create and follow comprehensive information security and SOC 2 security compliance policies.
Issued by outside auditors, SOC 2 certification is granted or not based on the relevant processes and systems a company has in place and the extent to which it complies with one or more of the five trust principles:
The security principle includes defending system resources from unauthorized access. Access controls help prevent improper disclosure or alteration of information, misuse of software, system abuse, and unauthorized removal or theft of data.
SOC 2 security tools such as two-factor authentication, network and web application firewalls (WAFs), and intrusion detection are useful in preventing unauthorized access of data and systems caused by security breaches.
The availability principle references system, service, or product accessibility as stipulated by service level agreement (SLA) or contract. Both parties necessarily set the minimum acceptable performance level for system availability by definition.
The availability principle does not address system usability and functionality but does involve criteria related to security that could impact availability. In this context, monitoring network availability and performance, security incident handling, and site failover are critical.
The principle of processing integrity touches on whether a system achieves its intended purpose or not. For example, for a system to deliver the right data in a timely way at the right cost, data processing must be accurate, authorized, complete, timely, and valid.
Notably, data integrity cannot always be inferred from processing integrity. Detecting errors in data that were present prior to being input into the system is not typically the processing entity’s responsibility. Quality assurance procedures and monitoring of data processing can help ensure processing integrity.
If access to and disclosure of data is restricted to a particular set of organizations or persons, that data is considered confidential. Data for use by company personnel only, internal price lists, business plans, intellectual property, and other varieties of sensitive financial information are confidential.
Safeguard confidential data during transmission, processing, and storage with encryption, network and application firewalls, and rigorous access controls.
The privacy principle references whether the system collects, uses, discloses, retains, and disposes of personal information in conformity with criteria set forth in the AICPA’s generally accepted privacy principles (GAPP) as well as the organization’s privacy notice.
Personally identifiable information (PII) refers to details such as name, Social Security number, or address that can distinguish an individual. Some personal data related to race, health, religion, and sexuality is also considered sensitive. This sensitive data generally demands an extra level of protection and must be guarded against unauthorized access, so controls must protect all PII.
To summarize the five trust principles:
- Security: data and systems must be protected against unauthorized access and anything that could compromise their availability, integrity, confidentiality, and privacy.
- Availability: systems must be available for operation and use.
- Processing integrity: system processing must be accurate, timely, and authorized.
- Confidentiality: confidential information must have appropriate protections.
- Privacy: any PII or similar personal data collected must be used, disclosed, retained, and disposed of appropriately.
What is a SOC 2 Audit?
SOC 2 is itself an auditing procedure that results in a detailed report and a set of requirements. The audit is an implied part of the SOC 2 process.
What is a SOC 2 Report?
In contrast to the outcomes produced by the rigid requirements of PCI DSS compliance, each organization’s SOC 2 reports are unique. Every organization designs its own controls to comply with one or more of the trust principles in line with specific business practices. These reports offer customers of service providers, business partners, regulators, vendors, suppliers, and others important details about how the service provider manages data.
There are two kinds of SOC 2 reports. SOC 2 Type I reports detail systems a vendor has in place and whether that design can meet relevant trust principles effectively. SOC 2 Type II reports describe those systems’ operational effectiveness.
Organizations that complete the compliance process receive seven-part reports that verify their efforts to minimize security risks. In brief:
- The Assertion Report describes how the six TSC and the organization’s security controls relate to each other.
- The Independent Auditor’s Report is the auditors’ evaluation of how effective the controls in place are.
- The System Overview Report describes how the company and service organizations interact.
- The Infrastructure Report summarizes all aspects of business operations, including personnel, security, and software procedures.
- The Relevant Aspects of Control Report is an analysis of the effectiveness of communication procedures, how the risk assessment was conducted, and the monitoring controls for tracking usage/security systems.
- The Complementary User-Entity Controls Report describes either the shared platform with a service organization or the security protocols protecting the user environment.
- The Test of Controls Report evaluates performance of controls after testing and offers auditor analysis of whether the controls were effective enough to meet the TSC.
Who Needs SOC 2 Compliance?
Among the most common compliance requirements for modern technology-focused businesses, SOC 2 applies to technology-based service organizations that store customer data in the cloud. In other words, SOC 2 applies to virtually every SaaS company, and any business that stores customer data in the cloud.
Industries needing SOC 2 compliance include:
- Accounting and auditing
- Cloud computing
- Customer relationship management (CRM)
- Customer support
- Data analysis
- Document and records management
- Financial processing
- Human resources
- Insurance claims processing
- IT security management
- Medical claims processing
- Sales support
- Software-as-a-Service (SaaS) vendors
- Technology consulting
- Workflow management
Organizations frequently designate a SOC 2 team to coordinate and oversee SOC 2 compliance efforts. These team members might include:
- Executive sponsor such as a Chief Information Officer (CIO), Chief Information Security Officer (CISO), Chief Security Officer (CSO), Chief Technology Officer (CTO), or Chief Risk Officer (CRO)
- Compliance officer/compliance manager
- Information security
- IT auditor
- Risk officer/risk manager
- SOC 2 project manager
Different people fill the role of SOC 2 manager from enterprise to enterprise.
What’s the Difference Between SOC 1 and SOC 2 Compliance?
A SOC 1 report offers the user entities of an organization assurance that their financial information is being handled securely and safely. Previously called the SAS 70 (Statement on Auditing Standards 70), the SOC 1 report was eventually replaced by the Statement on Standards for Attestation Engagements no. 16 (SSAE 16).
The SOC 2 reporting framework evolved to assist service organizations in demonstrating the effectiveness of their cloud and data center security controls. The SOC 2 was developed with a specific focus on security after organizations began measuring the effectiveness of security controls using the SAS 70.
A SOC 3 report exists. This public-facing document offers a high-level abstract-style overview of the SOC 2 report’s information. This is necessary due to the sensitive nature of much of the information contained in a typical SOC 2 audit report; the SOC 3 report is the front-facing version of the report, which summarizes the results as marketing materials might. However, the SOC 1 and SOC 2 reports are by far more important SOC compliance standards.
To break this down further, according to aicpa.org, SOC 1 reports are “important components of user entities’ evaluation of their internal controls over financial reporting for purposes of complying with laws and regulations.” In contrast, SOC 2 compliance reports “are intended to meet the needs of a broad range of users that need to understand internal control at a service organization as it relates to security, availability, processing integrity, confidentiality and privacy.”
Practically speaking, this means SOC 1 reports on financial controls, while SOC 2 reports on the security that supports them. In addition, auditors generate SOC 1 reports for other auditors, whereas SOC 2 reports are not shared outside the company, as they contain more sensitive information. Not surprisingly, then, SOC 1 reports use Standards for Attestation Engagements 16, while SOC 2 reports follow different standards—Attestation Standards 101.
An organization whose services impact customers’ financial reporting should pursue SOC 1. For instance, an organization that creates software for processing billing and collections data for customers affects its customers’ financial reporting and should pursue a SOC 1.
Organizations whose customers ask for a right to audit should also pursue SOC 1 rather than SOC 2. An audit may be time-consuming and costly for everyone involved without SOC 1, especially if multiple customers submit similar demands.
Finally, some organizations are required to comply with SOC 1. For example, as part of the Sarbanes-Oxley Act (SOX), publicly traded companies must pursue SOC 1.
This stands in contrast to SOC 2. There is no SOC 2 regulation; compliance is not required by PCI-DSS, HIPAA, or any other framework. However, data breaches being the tremendous ongoing issue they now are, SOC 2 compliance makes sense for any organization that hosts or processes data.
The individual situation of the organization determines the choice to pursue SOC 1 vs SOC 2. When making the choice, one critical deciding factor is whether your customer’s internal control over financial reporting could be affected by your organization’s controls. Another is what the reports are intended to achieve.For all of these reasons, when determining whether SOC 1, SOC 2, or both are the right fit for your organization, you may want to engage with a SOC 2 security audit firm. Another good source of information on SOC 2 is the American Institute of CPAs or www.ssae16.org.
SOC 2 Type 1 vs Type 2
Both Type 1 and Type 2 (or Type II) SOC 2 reports exist. The Type 1 report allows a company to demonstrate that its internal financial controls are properly designed to start with. A SOC 2 Type II report demonstrates over time—usually 12 months—that those controls operate effectively.
The SOC 2 Type 1 report is often an organization’s first SOC 2 report ever. It covers controls governing privacy and data security at the time of the audit. This “snapshot” offers just the starting point for security.
SOC 2 Type 2 reports demonstrate how effective the organization’s privacy and information security controls function between SOC 2 security audits. A SOC 2 Type 2 audit report explores how well the instituted controls functioned in practice.
Therefore, many organizations follow an audit procedure consisting of a SOC 2 Type 1 audit for the initial SOC 2 assessment, and a Type 2 for all SOC 2 audits thereafter.
What are the SOC 2 Compliance Requirements?
SOC 2 compliance requires that organizations develop and follow written security policies and procedures, including a written SOC 2 audit guide. Auditors can and will review them to ensure they encompass the five trust principles for data stored in the cloud: security, availability, processing integrity, confidentiality, and privacy.
To achieve SOC 2 compliance, it is essential to guarantee oversight across your organization by establishing a process and the correct monitoring practices, watching for any unauthorized, unusual, or suspicious activity. This often takes place at the user access and system configuration levels. Monitor for both known malicious activity (such as obviously inappropriate access or common phishing schemes) and unknown malicious activity (such as a new type of misuse or a zero-day threat).
The first step in detecting these unknowns is establishing a baseline of normal activity in your cloud environment with a continuous security monitoring service. This clarifies which activity is actually abnormal.
From a SOC 2 perspective, any incident that threatens the availability, confidentiality, privacy, processing integrity, and/or security of customer data in the cloud must be prevented. SOC 2 is intended to ensure consumers that service providers are monitoring for suspicious activity and can and will quickly take corrective action should an incident arise.
Why SOC 2 Compliance is Important
There are several key reasons why SOC 2 compliance is important:
Consumer Demand. Without a SOC 2 attestation you could lose business. Breaches are common, and protecting customer data is top-of-mind for prospects.
Cost Effectiveness. Just one data breach can cost millions. SOC 2 compliance costs are substantial, but they are far less than the expenses caused by a breach.
Competitive Advantage. A SOC 2 report enhances your organization’s reputation for trustworthiness and gives you the edge over competitors who cannot demonstrate compliance.
Peace of Mind. Passing a SOC 2 audit provides peace of mind that networks and systems are secure.
Regulatory Compliance. SOC 2 requirements quicken your organization’s overall path toward compliance as they dovetail with other frameworks including PCI DSS and HIPAA.
Value. SOC 2 audit report benefits extend beyond the framework itself, offering useful insights into your organization’s vendor management, security and risk posture, regulatory oversight, internal governance, and more.
How to Get SOC 2 Compliance
There are four areas of security practices that are essential to SOC 2 compliance.
Monitoring both Known and Unknown. An organization that has achieved SOC 2 compliance has sufficient levels of oversight across all of its levels. Specifically, it has developed and uses a process for monitoring authorized and unauthorized system configuration changes, unusual system activity, and user access levels. There is also a means for baselining normal activity in the cloud environment, usually via a continuous security monitoring practice.
Anomaly Alerts. Security incidents occur eventually, and when that happens, sufficient alerting procedures must be in place. Organizations must demonstrate the ability to respond quickly and take rapid, appropriate corrective action if any unauthorized access to customer data occurs. Unfortunately, noise from false positives and standards that are poorly defined for the unique environment complicate this.
Therefore, SOC 2 requires organizations to generate anomaly alerts based on any activities that result in unauthorized: file transfer activities; modification or exposure of controls, data, or configurations; or privileged account, filesystem, or login access. In other words, to ensure the anomaly alerts are compliant, organizations must determine what activities within their specific risk profile and cloud environment would be indicators of threats.
Detailed Audit Trails. The deep contextual insight offered by knowing the source of an attack is the most critical piece of response. Without it, there is no way to know where to start remediating the problem, especially during an active incident.
Detailed audit trails provide the required cloud security context, including insights into: addition, modification, or removal of key system components; point of source and breadth of attack impact; and unauthorized modifications of configurations and data.
Actionable Forensics. Actionable forensic information allows organizations to reduce both MTTD (Mean Time To Detect) and MTTR (Mean Time To Remediate). Host-based monitoring offers visibility into the origins of attacks; travel routes; which system parts were impacted; the nature of the impact; and probable next moves.
A very basic SOC 2 compliance checklist which is sufficient to satisfy an auditor must be detailed in the trust services criteria and should address several controls:
Logical and Physical Access Controls. Manage and restrict logical and physical access to prevent all unauthorized access.
System Operations. The specific ways system operations detect and mitigate deviations from set procedures.
Change Management. Prevent unauthorized changes by implementing a controlled change management process.
Risk Mitigation. Identifying and developing risk mitigation activities as part of a process when dealing with vendor services and business disruptions.
Most SOC 2 criteria are fairly policy-driven and broad, and although some are more technical, even those don’t specifically proscribe actions. SOC 2 criteria are therefore somewhat flexible and open to interpretation.
For example, there are multiple paths toward meeting the Logical and Physical Access Controls criteria. One organization may implement two-factor authentication, new onboarding processes, and systems to prevent downloading customer data during support operations, while another may conduct quarterly reviews of permissions, implement SOC 2 password compliance rules, restrict access to data centers, and strictly audit work completed on production systems. There is no single required combination—just a required final state described in the criteria.
Addressing security issues is the minimum SOC 2 compliance requirement. There are additional criteria in the other trust service principles as well.
SOC 2 compliance requirements in the Availability category include:
- Measure Current Usage. Evaluate the risk of impaired availability posed by constraints to capacity by establishing a baseline for capacity management.
- Identify Environmental Threats. Environmental threats that could affect system availability, such as fire, adverse weather, power cuts, or ECS failure, should all be assessed.
SOC 2 compliance requirements in the Processing Integrity category include:
- System Inputs. Creation and maintenance of record of system inputs. Keep accurate system input activity records.
- Define processing activities. Ensure services or products meet specifications in definitions.
SOC 2 confidentiality compliance requirements in this category include:
- Identification of confidential information. Identify confidential information via a standard procedure as soon as it is created or received, and determine how long to retain it.
- Destruction of confidential information. After information is identified for destruction, it should be subject to procedures for erasing confidential information.
SOC 2 compliance requirements in the Privacy category are based on generally accepted privacy principles (GAPP) from the AICPA and include:
- Clear language. Communicate in clear language in the company’s privacy notice, so there is no way to misinterpret it.
- Gather reliable information. Confirms that third-party data sources operate their data collection process legally and fairly and are reliable.
Traditionally, How Long Does it Take to Get SOC 2 Compliance?
The SOC 2 reporting process takes place in several stages and can last from 4 weeks to 18 months, with average processes taking 6 weeks to 3 months. The variation is caused by firm maturity, motivation to get the SOC 2 report, project complexity, the type of report (Type I vs. Type II), and variations at each stage of the reporting process.
Here is an overview of each stage of the process, including what to expect at each step with traditional tools and processes.
Planning and Strategy, 1 – 3 weeks. In this stage, the team establishes procedures for communication, and sets priorities and scope for the SOC 2 report. During this stage, the team decides which SOC 2 trust services criteria to include in the scope, the extent and nature of the system to be audited, what locations to audit, and the plan for tracking progress. This process should include enough time to achieve buy-in from all stakeholders.
SOC 2 Audit Gap Analysis and Readiness Assessment, 1 – 8 weeks. For organizations that elect to undergo a gap analysis before the formal audit, a firm assesses and compares the “as-is” environment to the SOC 2 requirements to create a list of remediation items for SOC 2 compliance.
Remediate Identified Issues, 0 – 12 months, usually 1 – 2 months on average. The gap analysis reveals issues that require remediation, and management must address them. Timing for this stage may vary greatly depending on the extent to which management is willing to retask resources to resolve gaps, the nature of the gaps, and how motivated management is to achieve SOC II compliance. Solid project management is critical to successful remediation, so identify milestones, set goals, and track every work-stream closely to final resolution.
Audit Fieldwork, 0 – 3 months, usually 2 – 4 weeks. Audit fieldwork can start when management feels certain they have completed remediation. At this point, the auditors will collect and examine audit evidence for the SOC 2 audit report, usually both remotely and on-site.
Audit Report, Conclusion, 1 – 5 weeks. After the conclusion of audit fieldwork, the audit firm will compose the final SOC 2 report and complete other administrative tasks needed to meet AICPA requirements.
Maintenance, ongoing. SOC 2 reports are required annually, so it is critical to maintain the program in between them. Many organizations co-source or build an internal audit function.
Traditionally, What Does the Average SOC 2 Certification Cost?
The total cost for SOC 2 Type 1 vs Type 2 audits is very different. SOC 2 compliance certification is typically far more expensive, although there is no single SOC 2 audit process or size that fits every business. Reports range from 25 pages to over 100 pages.
SOC 2 Type 1 audits traditionally start between $20,000 and $80,000. This does not account for additional expenses related to SOC 2 Type 1 compliance such as: any independent readiness assessments on the chances of passing SOC 2; paying dedicated consultants or in-house employees; legal fees for review of agreements; and the cost of any cultural changes, technical work, or training needed to implement appropriate SOC 2 controls.
SOC 2 Type 2 certifications traditionally start at $30,000 and can reach to over $100,000, and last six months to a year. Final cost and timing are influenced by the complexity of the infrastructure.
Several factors influence the cost of SOC 2 Type 2 certifications, including: the scope of services in the report; the number of in-scope processes and systems; the size of the organization; the selected trust services criteria (TSC).
Typically, auditing more processes and systems is more expensive. It is essential to audit every system that affects client data must be audited. There are various costs to consider when budgeting time and money for a SOC 2 audit:
Productivity Costs. The SOC 2 team will be taking time away from other work to focus on the audit, throughout the SOC 2 process and project. As described above, the team will involve key personnel who are familiar enough with technical systems to effectively manage time and resources, not more junior staff.
Staff SOC 2 Compliance Training. Staff training such as annual cybersecurity awareness training is a vital SOC 2 audit cost. Designed to embed data security into employee processes, this educational program may be delivered in-house or via a third party cybersecurity firm.
Build vs Buy. With a new or improved SOC 2 program, there is typically a demand for new tools that adds to SOC 2 audit price based on current security and infrastructure outlook. These types of tools: collect asset inventory; detect intrusions and threats; capture compliance tasks by generating tickets; manage security and compliance reporting; monitor file integrity; and manage vulnerabilities. The issue is whether to build or buy them based on in-house resources, development resources, firm size, and other factors.
Who Can Perform a SOC 2 Audit?
The AICPA regulates SOC 2 audits along with the rest of the SOC suite (SOC 1 and SOC 3 along with SOC 2 and SOC for Cybersecurity). AICPA specifically requires SOC 2 audits to be performed only by auditors at licensed CPA firms that specialize in information security.
In general, most SOC 2 audit service providers are either a Big 4 accountancy firm, a boutique or mid-tier accountancy firm, or a specific Cybersecurity CPA firm. Ideally, a SOC 2 audit firm understands not only accounting, but just as critically, IT and information security. The particular experience of cybersecurity firms is often excellent SOC 2 for startups, who are typically themselves heavily reliant on technology.
What Happens During a SOC 2 Audit?
The SOC 2 process works much like other audits. The CPA or firm can assist the organization in several ways:
Determine the scope of the audit, including: determining which trust service criteria are applicable to your business; and whether you need SOC Type 2 compliance or whether SOC 2 Type 1 certification would work better.
The auditor will examine the SOC 2 controls for each applicable SOC 2 category, collecting evidence and evaluating whether they are functioning optimally. The auditor may examine: asset inventories; change management processes; onboarding and off-boarding processes; and organizational charts.
Should the auditor detect gaps or problems, there is always a chance for remediation. However, because findings can drive up audit costs, it is essential to prepare thoroughly using a SOC 2 audit checklist.
How to Prepare for the SOC 2 Audit Process
Preparation is the key to SOC 2 readiness. Check off each item on the SOC 2 checklist and collect SOC 2 compliance documentation and other supporting evidence before the audit. More specifically:
Establish Goals. Determine the scope of the audit. Establish which of the five SOC 2 categories apply to your organization.
Organize Materials. Gather and organize the correspondence and documents proving the organization’s controls are effective in line with the applicable trust service categories and SOC 2 principles.
Self-audit. Conduct a self-audit so you can identify and remediate existing compliance issues. Proving you have done so to the professional conducting your SOC 2 audit is a huge step toward SOC 2 attestation.
Use Tools. SOC 2 accreditation is complex, and it’s not easy, or everyone would have it. SOC 2 is complex and dynamic—difficult to manage compliance even using AI and advanced technologies. For companies using paper or spreadsheets, managing compliance verges on the impossible.
How Does Shujinko Change the SOC 2 Audit Equation?
Shujinko automates audit preparation for compliance across clouds and hybrid environments. Shujinko makes audit preparation fast and easy, saving thousands of people hours and dollars, providing 360 degree visibility, and enabling organizations to do more with less. Shujinko works closely with audit firms, saving organizations additional time and money in total for SOC 2 Type I and Type II audits.
AuditX™ is purpose-built software for automated audit preparation, evidence collection, and readiness. AuditX simplifies and automates IT security and compliance audits across security frameworks and compliance standards running on public cloud and hybrid infrastructures. AuditX makes audit preparation 3x faster, simpler, and with 360 degree visibility, enabling customers to do more with less, freeing up valuable time for competing priorities, and working remotely as a team and with your audit firm.
AuditX+™ features our Automated Evidence Collection engine (AEC). AuditX+ builds on our flagship AuditX software platform that is purpose-built for audit preparation, evidence collection, and readiness. In AuditX+, with the push of a button, AEC crawls and collects evidence for security and compliance audits directly from your AWS and Microsoft Azure cloud infrastructure. AEC collectors include verification of encryption of all cloud data at rest used by cloud services. Other AEC collectors validate encryption key management, network segmentation, and configuration.
Shujinko is the pioneer in automated compliance preparation. The company’s breakthrough AuditX™ SaaS solution simplifies, automates and modernizes IT audit preparation, evidence collection and readiness for enterprises. Shujinko’s extensible platform is purpose-built for audit preparation and evidence collection across multiple compliance standards, multiple clouds and multiple audits. To learn how Shujinko makes audit preparation 3x faster, simpler and provides 360-degree visibility, please visit shujinko.io.
Automate Audit Preparation
Get ahead of your upcoming audit deadlines and compliance initiatives. Ditch the shared spreadsheets, back and forth email, and unclear evidence requests. Start working with Shujinko’s AuditX tool to simplify, automate, and modernize audit preparation for your cloud-first enterprise.