The History of SOC 2


Service organization control (SOC) reporting is an integral part of maintaining the trust and confidence of key business stakeholders. There are many different types of SOC report, but the overarching objective for each is to offer unbiased, third party insight into the competency of your existing service delivery processes and controls.
These reports must be administered by an independent certified public accountant (CPA) to be recognized and valid, but you can still work with non-CPA professionals during the preparation phase. Every SOC auditor in the US is regulated by the American Institute of Certified Public Accountants (AICPA) and must adhere to their strict operational standards to maintain compliance. These regulatory controls include planning of audits or reports, execution of assessments, and supervision of client employees during auditing procedures. Read on to learn more about the history of SOC 2 compliance.

SOC 2 Auditing Reports

A SOC 2 audit is designed to create a comprehensive overview report of a service organization’s controls, for reference by both internal and external stakeholders. With SOC 2 specifically, the auditor will assess the suitability and effectiveness of a service organization’s controls relating to security, availability, data processing, privacy, and proper handling of confidential information.
There are two types of SOC 2 report, each with slightly different reporting parameters:

  • Type 1 – This type focuses on a specific date in time, performing analysis on the capacity for meeting trust principles based on the current systems in place. These are less comprehensive than Type 2, but offer much faster realization of insight into the competency of service management and controls in a business.

Type 1 is better suited for communicating with end-users and smaller external stakeholders, as it goes into less detail about the specifics of your internal operations.

  • Type 2 – This type focuses on a much larger time period, with six months being the minimum. A Type 2 report evaluates how effectively you meet trust principles with your systems and procedures over time, painting a much more comprehensive picture for stakeholders to review.

These are more commonly used for critical business partners who have significant ties to your business. They risk collateral damage if you have lackluster controls in place, making a Type 2 report essential for instilling sufficient trust.

The Evolution of Auditing

Through a massive crackdown on data compliance regulation with the likes of GDPR, CCPA, and PCI-DSS, SOC auditing has become a necessity rather than just a desirable service. SOC is the current standard for attesting service organization controls for stakeholders, but it was borne from much older standards that modern technology eventually outgrew. The history of SOC 2 starts here.

SAS 70

Back in 1992, auditors wanted more understanding of the financial reporting controls their clients used. Without any regulatory guidelines, auditors were tasked with creating the majority of reporting criteria when assessing service organizations. This complicated the auditing process and posed a risk to auditors, who were liable for the competency of their guidelines in the event of client security mishaps. Auditors wanted a standardized set of reporting criteria to use to expedite the planning phase and reduce their liability.
The AICPA met the demands of auditing firms by issuing the ‘Statement on Auditing Standards 70’ (SAS 70) guidelines. This guidance enabled independent CPAs to plan their assessment procedures around a predefined framework, and simultaneously reduce their liability with the backing of an authoritative governing body. The SAS 70 guidelines were also beneficial for service organizations and stakeholders, as the standardized criteria in these reports meant it was easier to make comparisons between different vendors.

SSAE 16 and SOC 2

SAS 70 offered immense benefits at the time for vendors and auditors, but the pace of technological advancement quickly outgrew it. The standard was built to assess security and IT controls concerning business finance, but many auditors were now misusing it for other types of assessment. Noticing this, the AICPA began working on a new set of standards.
After almost 20 years of SAS 70 misuse, the AICPA released the service organization control reporting system (SOC). This set of reporting criteria was much more comprehensive, with specific reports for different aspects of a vendor’s operations.

  • Statement on Standards for Attestation Engagements (SSAE 16) – This is a rather wordy name, but SSAE 16 was simply a new and improved replacement for SAS 70. Also known as a SOC 1 report, this was dedicated solely to financial auditing assessments, offering a clear set of guidelines for auditors to follow.
  • SSAE 18 – The SSAE 18 guidelines were brought into effect on May 1st 2017, and further improved upon the existing guidance in the previous standard. SSAE 16 quickly became outdated due to a massive surge in managed service providers (MSPs) over the past decade, so SSAE 18 updated the guidelines to regulate the auditing of these services better.
  • AT-101 – The aptly named Attest Engagement 101, or AT-101, was the first iterative set of guidelines for SOC 2 reporting. These guidelines were released alongside SSAE 16/SOC 1 and catered to the growing popularity of cloud computing.

AT-101 offered a dedicated set of auditing criteria for CPAs to measure controls against security, data availability, data processing, privacy, and confidentiality. This meant auditors could stop misusing SAS 70 and improve the quality of their audit reports, benefiting vendors, and stakeholders.

  • AT-C 205 – Much like SSAE 18 was an evolution of SSAE 16, AT-C 205 further developed the existing AT-101 guidelines for SOC 2 reporting.

With this update came guidelines for Examination Engagements by auditors. Simply put, this reaffirmed the requirement for CPAs to be independent and unbiased in their auditing processes. If they had a relation to any key business stakeholders or where required by law to perform the audit, they would need to disclose that they were not operating independently.

Which brings the history of SOC 2 guidelines to the present day.

Be Prepared for All Things SOC With Blissfully

Here at Blissfully, we believe that all businesses should be able to access powerful tools that simplify regulatory compliance. That’s why we created the Blissfully platform, offering a cloud-native foundation to promote security and compliance adherence for your business.
Our platform is built to simplify both preparation and long term adherence for SOC audits, through comprehensive audit trails that track the end-to-end journey for data and workflows across your business.
There are no downsides to being prepared for all things compliance related, so consider trying a demo of the Blissfully platform today!