What is SOC 3 Compliance?

Before we begin, let’s establish a few key terms to help readers fully understand SOC 3 compliance:

• Service Organization: Any third-party vendor who provides services to another organization. As far as SOC 3 audits and reports are concerned, these service organizations are typically software as a service (SaaS) providers.
• User Entity: Any company that outsources services to a third-party. So, for example, if you were to use an email hosting service, your company would be considered the user entity, and your email hosting provider would be the service organization.
• Internal Controls: The policies, procedures and processes established by a service organization to ensure adherence to industry best practices, the integrity of information, and compliance with applicable laws and regulations.
  Service Auditor: A certified public accountant (CPA) who conducts a SOC 3 audit on behalf of a service organization.
• User Auditor: A CPA who conducts a SOC 3 audit on behalf of a user entity.
• Assertion: Also known as “management’s assertion” or a “service organization’s assertion,” this refers to a service organization’s declaration as to whether its internal controls meet the requisite criteria.
• Management’s Description: Written description of the service that a service organization provides to its user entities. This description may include information about the period to which it applies, specified control objectives, who was responsible for specifying control objectives and details about controls.
• Attestation: The final results of a SOC 3 audit; also known as an “attestation report” or “SOC 3 report.”

Service Organization Control 3 (SOC 3) is an auditing procedure developed by the American Institute of Certified Public Accountants (AICPA) to demonstrate the strength of a service organization’s internal controls over cloud and data center security.

The SOC 3 framework is based on five Trust Services Criteria (TSC), which the AICPA defines as follows:

• Security — Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity’s ability to meet its objectives.
• Availability — Information and systems are available for operation and use to meet the entity’s objectives.
• Processing Integrity — System processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives.
• Confidentiality — Information designated as confidential is protected to meet the entity’s objectives.
• Privacy — Personal information is collected, used, retained, disclosed, and disposed to meet the entity’s objectives.

With a SOC 3 audit, service organizations are responsible for determining which of these five TSC are relevant to the service they offer to their customers. CPAs can perform an audit based on just one of these TSC, all five or some combination of the five. Additional performance and reporting requirements, as well as application guidance, can be found in AT-C Section 105 and AT-C Section 205 of Statements on Standards for 18 Attestation Engagements (SSAE 18).

From an auditing perspective, SOC 3 and SOC 2 are the same. Both SOC 3 and SOC 2 audits are designed to evaluate a service organization’s internal controls over cloud and data center security and utilize the AICPA’s TSC reporting framework. Where they differ, though, is in the final attestation report.

SOC 2 reports are restricted use reports, meaning they can only be shared with the management of a service organization, its current and prospective user entities, and user entities’ business partners and user auditors. By comparison, a SOC 3 report is a general report that can be made available to the public and freely distributed. For this reason, SOC 3 reports are often used for marketing purposes. This also means that SOC 2 reports tend to be far more detailed than SOC 3 reports, since they are intended for a professional audience.

The final distinction between SOC 3 vs. SOC 2 is that there are two types of SOC 2 reports, and only one type of SOC 3 report. A SOC 2 Type 1 report covers a service organization’s controls at a specific point in time, whereas a SOC 2 Type 2 report covers a service organization’s controls over a period of time. All SOC 3 reports are Type 2 reports by default.

As a final note, there is a third type of SOC audit and report. Known as SOC 1, this auditing procedure addresses a service organization’s internal controls over financial reporting based on the performance and reporting requirements found in AT-C Section 320 of SSAE 18. For more information on the difference between SOC 1 and SOC 2 reports, we recommend reading our in-depth blog post on the subject.

SOC 3 broadly applies to any service provider that stores customer data in the cloud, including SaaS, platform as a service (PaaS) and infrastructure as a service (IaaS) providers.

Although it is not mandated, service organizations and user entities alike can still benefit from SOC 3 compliance.

Certain user entities are subject to industry regulations, many of which include strict data security, integrity, processing and availability requirements. In order to ensure regulatory compliance, these user entities can only partner with service organizations that have demonstrated strong internal controls related to data security through a SOC 2 audit. To that end, successfully completing a SOC 3 audit can help a service organization appeal to a wider audience and attract new customers.

SOC 3 compliance can also help boost service organizations’ and user entities’ public reputations.

Research from the Pew Research Center shows that 79% of Americans are not confident that companies will take responsibility for compromised personal information, and 70% said that they believe their personal data is less secure than it was five years ago. In this climate, it’s imperative that companies demonstrate that they are good stewards of the data they collect. For a service organization, completing a SOC 3 engagement — or, from a user entity’s perspective, working only with service organizations that are SOC 3 compliant — is an effective way to do that.

Finally, SOC 3 can help service organizations, in particular, reduce costs associated with data breaches, gain valuable insights into the strength of their company’s security posture and provide a comprehensive view of security incidents.

Given that SOC 3 is essentially a version of SOC 2, the auditing procedure is much the same between the two.

At a high level, a service auditor will evaluate the effectiveness of controls within a service organization’s cybersecurity risk management program based on the selected TSC. The process itself can include anything from employee interviews and systems testing to records requests and filling out paperwork.

Generally speaking, service auditors are looking for the following controls and policies:

• Access controls
• Disaster recovery
• Encryption
• Intrusion detection
• Network and application firewalls
• Performance monitoring
• Processing monitoring
• Quality assurance
• Security incident handling
• Two-factor authentication

Once the audit is complete, the service auditor will generate an attestation report based on their findings. As noted, a SOC 3 report will be far less detailed than a SOC 2 report, sharing only information that is pertinent to the public. Once the audit is complete, a service organization may freely share its results for marketing purposes.

In order to pass a SOC 3 audit with flying colors, service organizations are advised to:

Carefully select which controls they would like to have audited. All SOC 3 audits cover data security at a minimum, but service organizations can choose to audit other internal controls according to their TSC of choice, as well. Before selecting which controls to audit and which TSC to use, service organizations should take care to ensure that their policies, procedures and systems are up to date and fully secured to increase their chances of achieving SOC 3 compliance.

Conduct a readiness assessment. A readiness assessment can help a service organization identify any gaps within its existing controls that might leave it at risk of failing a SOC 3 audit. With the results of its readiness report in hand, a service organization can make the necessary changes to strengthen its security posture and undergo its SOC 3 audit with confidence.

Figure out what “normal” looks like. By setting a baseline for normal activity within its cloud environment, a service organization can more easily identify anomalous (and potentially malicious) activity. Service organizations should then use this information to set up automated anomaly alerts, including a process for weeding out false alerts.

Determine next steps for incident alerting. In addition to establishing a security incident alerting procedure, a service organization should also leverage actionable forensics to identify everything from the root cause of the attack to the context in which it took place and carefully record these details. Similar to undergoing a readiness assessment, creating detailed audit trails can help service organizations uncover potential vulnerabilities within their security posture.

Find a qualified service auditor to conduct the examination. When vetting prospective service auditors, service organizations will want to look for one who is affiliated with the AICPA, has prior experience conducting SOC audits (especially with service organizations of the same size or in the same industry) and has recently been peer reviewed.

Obtaining a SOC 3 report is a great way for both service organizations and user entities to support compliance initiatives; investing in a comprehensive archiving platform is another.

Intradyn specializes in providing email, text message, social media and all-in-one archiving solutions with advanced security features to help businesses support regulatory compliance, eDiscovery requests and more. Contact us today to learn more about our offerings.