Cookie-Einstellungen
schließen
SOC 2
Framework

Fundamentals of
SOC 2 Compliance and Audit Readiness

Start your SOC 2 attestation journey here

What is SOC 2?

SOC 2—System and Organization Controls 2—establishes criteria to help your organization manage and protect sensitive customer data. The American Institute of CPAs (AICPA) developed SOC 2 criteria for reporting and auditing processes, which are based on five trust service criteria (TSC):

  • Security
  • Availability
  • Processing integrity
  • Confidentiality
  • Privacy

Unlike more stringent frameworks such as the Cybersecurity Maturity Model Certification (CMMC) or PCI DSS, SOC 2 is not a regulatory requirement. However, demonstrating your organization meets SOC 2 criteria is a great way to show your customers, partners, and key stakeholders that your company values and applies SOC 2 standards for product or service delivery. And many organizations submit themselves to SOC 2 audits to provide attestations of compliance to their customers.

In this SOC 2 fundamentals page, we’ll take a closer look at the five criteria, formerly known as principles, and help you get a better understanding of each, explain how to become SOC 2 certified, and offer tips to help you streamline your SOC 2 audits.

Understanding SOC 2 Compliance

System and Organization Controls (SOC) 2 attestation, similar to certification, is a great way to demonstrate your organization takes data protection and privacy seriously and that you have controls in place that support those standards.

While some common cybersecurity frameworks and requirements, for example, the General Data Protection Regulation (GDPR), set rigorous standards your organization must meet for compliance, you can use SOC 2 criteria to create controls specific for your organization’s unique needs, as long as they align with the one of the five SOC 2 Trust Services Criteria (TSC):

  • Security
  • availability
  • Processing integrity
  • Confidentiality
  • privacy

SOC 2’s origins are rooted in the Statement of Auditing Standards No. 70, also known as SAS 70, from 1992. Certified public accountants (CPAs) originally used SAS 70 standards to conduct audits to determine how well service organizations manage information security controls and similar processes. For the purposes of SOC criteria, a service organization is any third party that provides services to your organization as a part of your organization’s information systems.

In 2010, the American Institute of CPAs (AICPA), replaced SAS 70 auditing with the Statement on Standards for Attestation Engagements No. 16 (SSAE 16). From SSAE, two new auditing reports emerged—SOC 1 Type 1 and SOC 1 Type 2. Type 1 reports focus on your organization’s capabilities on a specific date, whereas Type 2 reports focus on your controls on an ongoing basis.

SOC 1 focuses primarily on controls related to your financial reporting—Internal Controls Over Financial Reporting (ICFR).

SOC 2 focuses on the protection of data, evaluating your controls for those five TSCs we mentioned earlier. SOC 2 also includes a description of your service auditor’s tests of your controls and related results. Those reports are generally not made public.

There is also a SOC 3, which is similar to SOC 2, but it doesn’t include a description of a service auditor’s tests of controls and results, like SOC 2 does, so you can share it with the public, for example, on your website or social media.

Want to learn more about the evolution of SOC 2 from SAS 70 to the present? Check out, Explaining SOC: Easy as 1-2-3.

Building a Successful SOC 2 Engagement Strategy

Does My Organization Need to be SOC 1 Compliant?

Successfully obtaining a SOC 2 attestation shows your customers, vendors, and key stakeholders that your organization takes data security seriously and that you’re committed to protecting your customers’ sensitive and protected data.

You can use SOC 2’s five core Trust Services Criteria (TSCs)—security, availability, processing integrity, privacy, and confidentiality—as a starting point to develop a basic cybersecurity program for your organization that you can mature over time. You can even use SOC 2 criteria to develop specific TSC-related controls that are unique for your internal processes.

In this SOC 2 Compliance Guide, you can learn more about:

  • The history of SOC 2
  • Why your organization needs a SOC 2 attestation
  • Insight into the Trust Services Criteria
  • Areas of focus of SOC 2
Framework

Manage Your SOC 2 Compliance
and Audit Readiness with Apptega

Apptega’s cybersecurity management platform can help you build your SOC 2 program simply and easily based on industry best practices and the SOC 2 framework. It’s a great resource to help you as you develop and mature your program over time, giving you comprehensive visibility not only into how well you’re meeting your SOC 2 criteria but if your organization uses other frameworks to manage cybersecurity, you can get instant insight into your performance with those too. You can even map multiple frameworks together in the Apptega solution.

Apptega will support you along your SOC 2 compliance journey before, during, and after your audit processes.

Apptega can help you with your SOC 2 needs, including:

Questionnaire-based assessments

Automated and customizable reports

Automated alerts and notifications

Framework crosswalking with Apptega Harmony

Granular roles and permissions settings

Who Needs SOC 2?

Although no industry requires a SOC 2 certification, successfully completing a SOC 2 attestation reassures your clients and regulatory agencies that your organization has controls in place that guide security, availability, processing integrity, confidentiality, and privacy.

But it’s more than just a one-time effort to check the boxes and show that you have these controls set up. A SOC 2 attestation demonstrates your controls are effective and working. You can even assess and report on that effectiveness on a continual basis.

So how do you know if a SOC 2 certification is right for you? Generally, if you’re a service organization, and your store, process, or transmit sensitive or customer data, then a SOC 2 attestation is a good idea. Think of it as a less stringent (or starting point for an) ISO 27001 certification. And, if you outsource any of your work and share customer data with contractors or subcontractors, they should be SOC 2 compliant as well.

There are a number of benefits of adopting a SOC 2 approach for your security processes. From competitive advantage to potential cost-savings, these controls can give you more organizational insight, help you more efficiently manage your vendors and cybersecurity programs, guide internal governance and practices, help with risk management, and even guide regulatory oversight.

And, since SOC 1 deals with financial reporting, you’ll still need SOC 2 to evaluate your internal controls for information security related to the five Trust Services Criteria.

If you’re just beginning to develop your organization’s cybersecurity standards, SOC 2 is a great place to start.

Understanding SOC 2 Trust Services Criteria

The SOC 2 core is built on Trust Services Criteria (TSC). You can use TSCs to determine the effectiveness of your organization’s controls related to security, availability process integrity, privacy, and confidentiality. These controls are for information processed by your systems, not just at your primary location, but also if you have divisions or other operating units that conduct or support functions within your organization.

While TSCs focus on controls, effective SOC 2 practices also require sound judgment, facilitated by points of focus, which we’ll go into more detail in the next section (or if you’d like to go ahead and learn more, check out the Points of Focus section below).

TSCs are also aligned to 17 principles from the Committee of Sponsoring Organizations of the Treadway Commission (COSO) framework. Those 17 principles are categorized in a series of classifications (check out the Common Criteria Section below).

There are no regulatory requirements for SOC 2, so you can choose to meet one, some, or all of the TSCs. You can even begin with one or two and then build your controls out to meet more TSCs over time as you mature your program. While these are not in a specific required order, it’s a good idea to begin with the Security TSC.

Security

The Security TSC is the most common criteria used by most organizations. It guides protection of information as your organization collects, uses, processes, transmits and stores it, as well controls for the systems that access, transmit, and store that data. Your security controls should ensure that information is protected from unauthorized access, unauthorized disclosure, and system damage that could put sensitive data at risk.

Privacy

The Privacy TSC guides how your organization handles personally identifiable information (PII) such as names, addresses, phone numbers, etc. Consider the Privacy TSC as a tool to help you align your practices with your privacy notice. There are specific privacy criteria that include: notice and communication of objectives, choice and consent, collection, use, retention, and disposal, access, disclosure and notification, quality, monitoring and enforcement.

Availability

The Availability TSC focuses on ensuring information and systems are available for use and meet your objectives. It guides controls to support system access for operations, monitoring and maintenance.

Processing Integrity

The Processing Integrity TSC focuses on ensuring that your system processes are complete, accurate, timely, and valid.

confidentiality

The Confidentiality TSC applies to a gamut of sensitive data and guides how your organization protects that information from the time it’s collected or created all the way through to when and how your organization disposes of it or removes it from your organizational control.

Understanding SOC 2 Common Criteria for Audits

TSC Sub-Criteria

All TSCs include sub-criteria that align to the 17 COSO principles. There are also additional criteria not directly COSO-related. These common criteria are at the core of a SOC 2 audit. In total, all 9 common criteria classifications span the range of information security controls.

Pro tip: Considering doing your first internal audit by focusing on these criteria to see how well you’re doing and identify SOC 2 gaps before you complete a formal assessment.

In addition to these COSO-focused principles, each TSC has additional criteria you can use to strengthen and mature your SOC processes. To see the full list, check out AICPA’s Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy Guide.

  • CC1: Control Environment

The control environment criteria has 5 related principles:

1.1 - The entity demonstrates a commitment to integrity and ethical values.

1.2 - The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.

1.3 - Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.

1.4 -  The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.

  • CC2: Communication and Information

The communication and information criteria has 3 related principles:

2.1 - The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.

2.2 - The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.

2.3 - The entity communicates with external parties regarding matters affecting the functioning of internal control.

  • CC3: Risk Assessment

The risk assessment criteria has 4 related principles:

3.1 - The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.

3.2 - The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.

3.3 - The entity considers the potential for fraud in assessing risks to the achievement of objectives.

3.4 - The entity identifies and assesses changes that could significantly impact the system of internal control.

  • CC4: Monitoring Activities

The monitoring criteria has 2 related principles:

4.1 - The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.

4.2 - The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.

  • CC5: Control Activities

The control activities criteria has 3 related principles:

5.1 - The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.

5.2 - The entity also selects and develops general control activities over technology to support the achievement of objectives.

5.3 - The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action.

  • CC6: Logical and Physical Access

The logical and physical access criteria has 8 related principles:

6.1 - The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.

6.2 - Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.

6.3 - The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.

6.4 - The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives.

6.5 - The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives.

6.6 - The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

6.7 - The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives.

6.8 - The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.

  • CC7: System Operations

The systems operations criteria has 5 related principles:

7.1 - To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

7.2 - The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

7.3  - The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.

7.4 - The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate.

7.5 - The entity identifies, develops, and implements activities to recover from identified security incidents.

  • CC8: Change Management

The change management criteria has 1 related principle:

8.1 - The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

  • CC9: Risk Mitigation

The risk mitigation criteria has 2 related principles:

9.1 - The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.

9.2 - The entity assesses and manages risks associated with vendors and business partners.

Understanding Points of Focus for SOC 2

When we introduced the Trust Services Criteria, we mentioned how each criterion also has points of focus. The purpose of these points of focus is to help you identify the important characteristics of each TSC. These points of focus can help you design your controls as well as guide the development and maturity of your security practices. You can further use points of focus as guide points to evaluate how well your existing controls work and identify where you may need to make changes or improvements.

It’s important to note that not every point of focus outlined in SOC TCSs are relevant to every organization. You can use the points of focus to help customize your controls based on your organization’s needs.

While the extensive list of points of focus for each of the TSCs and related common criteria is too lengthy to outline here, let’s take a quick look at an example:

Common Characteristic: Control Environment

CC 1.1 Principle: The entity demonstrates a commitment to integrity and ethical values.

COSO-Related Points of Focus:

  • Sets the Tone at the Top
    The board of directors and management, at all levels, demonstrate through their directives, actions, and behavior the importance of integrity and ethical values to support the functioning of the system of internal control.
  • Establishes Standards of Conduct
    The expectations of the board of directors and senior management concerning integrity and ethical values are defined in the entity’s standards of conduct and understood at all levels of the entity and by outsourced service providers and business partners.
  • Evaluates Adherence to Standards of Conduct
    Processes are in place to evaluate the performance of individuals and teams against the entity’s expected standards of conduct.
  • Addresses Deviations in a Timely Manner
    Deviations from the entity’s expected standards of conduct are identified and remedied in a timely and consistent manner.

Additional Points of Focus:

  • Considers Contractors and Vendor Employees in Demonstrating Its Commitment
    Management and the board of directors consider the use of contractors and vendor employees in its processes for establishing standards of conduct, evaluating adherence to those standards, and addressing deviations in a timely manner.

To see a full list of SOC 2 Points of Focus, check out AICPA’s Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy Guide.

Preparing for Your SOC 2 Compliance Audit

After you’ve established your SOC controls, you’ll need to hire a certified public accountant to conduct your SOC 2 audit.

Here are a few tips to help you prepare:

  • Designate an executive sponsor who will lead your SOC 2 initiatives
  • Select a senior-level manager to help keep your SOC 2 momentum going
  • Bring on leaders from your IT and Security teams to help with implementation and planning
  • Determine project scope, including which criteria and principles to include and related systems and components
  • Do an internal audit or self-assessment
    (streamlined by Apptega)
  • Identify gaps or deficiencies and make plans to remediate (streamlined by Apptega)
  • Prepare to support your auditor with additional evidence or supporting information as requested (streamlined by Apptega)
  • Review results and plan to fix any noted deficiencies and plan for follow-up engagements (streamlined by Apptega)
  • SELECT a CPA for your audit
  • Wait for audit results

SOC 2 FAQs

What is SOC 2?

SOC 2 stands for System and Organization Controls (SOC) 2. SOC 2 outlines criteria your service organization can use to manage and protect customer data. SOC 2 is one of the auditing reporting processes developed by the American Institute of CPAs (AICP) to help guide information security. SOC 2 focuses on five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.

Who oversees SOC criteria?

The American Institute of CPAs oversees SOC criteria. SOC audits are conducted by certified public accountants (CPAs).

What is SOC 1 and how is it different from SOC 2?

SOC 1 focuses primarily on financial reporting controls, whereas SOC 2 evaluates all internal controls related to information security and protecting customer data.

How are SOC 2 and ISO 27001 different?

SOC 2 and ISO 27001 are different, but they both help you demonstrate to your clients, partners, vendors, and key stakeholders that you have sufficient controls in place to protect data. SOC 2 is not mandatory and you do not get a SOC 2 certification after your audit. Instead, your auditor will issue an attestation report about your security practices. A successful ISO 27001 audit, on the other hand, results in a certification that deems your organization ISO 27001 compliant.

What is SOC 2 Type I report?

A SOC 2 Type 1 report evaluates your security controls for a specific point in time. Many organizations use the SOC 2 Type 1 report for their first SOC 2 audit and then use the SOC 2 Type II report for subsequent reviews.

What is SOC 2 Type II report?

A SOC 2 Type 2 report is similar to a SOC 2 Type 1 report, but instead of evaluating controls for a specific date, it attests to your control standards on an ongoing basis.

How do I know if I need to be SOC 1, SOC 2, or SOC 3 compliant?

According to AICPA, here are three simple questions you can ask to determine if you need to be SOC 1, SOC 2, or SOC 3 compliant: 1. Will your customers and their auditors use your report to plan and perform an audit of your financial statements? If yes, then you need SOC 1. 2. Will your customers or stakeholders use the report to get confidence and place trust in your systems and data protection measures? If yes, you need SOC 2 or SOC 3. Do your customers need to (and can they) understand the details of the processing and controls at your organization, the tests the auditor performs, and the results? If yes, then you need SOC 2.

What do I need to do to be SOC 2 compliant?

To be SOC 2 compliant, your organization should demonstrate its ability to meet basic information security processes and procedures. Unlike other compliance frameworks, you don’t have to meet all SOC 2 compliance standards. Instead, you can use SOC 2 Trust Services Criteria to develop controls that are specific to your organization and then use additional SOC 2 criteria as you build and mature your cybersecurity program over time.

Still have a question?

Get in touch with us and we would be happy to help.

Ready to get started?

Request a no-risk 14-day free trial to see how you can create a sticky compliance-as-a-service offering with Apptega.