How to conduct SOC 2 Audit: Guide for Enterprises

It can strike fear into the hearts of business leaders and stakeholders alike – compliance audits. But, while they can seem scary and can invoke worry and anxiety about the outcome, organizations that use compliance frameworks to help align their business with cybersecurity best practices will significantly benefit. For example, if your business uses the System and Organization Controls (SOC) compliance standard, the SOC 2 audit may seem daunting and scary. In this SOC 2 compliance overview, we will take a look at the principles of SOC 2 compliance, audits, and criteria that auditors use to gauge compliance and perform audits.

SOC 2 – Who must comply?

The System and Organization Controls (SOC) compliance framework developed by the American Institute of Certified Public Accountants helps establish standards defining a secure operating environment for business-critical and sensitive data stored in the cloud. 

SOC 2 compliance standards apply to any technology-based organizations storing customer information in the cloud or cloud services. By default, this includes any who provides Software-as-a-Service (SaaS) solutions or other cloud services to clients. However, any cloud-based technologies existing in cloud IaaS, PaaS, or SaaS are within the scope of SOC 2 compliance.  

Why undergo a SOC 2 audit?

First of all, what is the purpose of the SOC 2 audit? The Trust Service Principles established by the AICPA allow evaluation and reporting on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems. The scope can be for the entire organization, a subsidiary, department, or organizational unit. 

Undergoing a SOC 2 audit can help understand where risks exist in the environment and areas where remediation and compensating controls need to be introduced. In addition, it helps an organization know how well controls in place are aligning the business with the SOC 2 framework.

The SOC 2 audit is also used by companies that outsource services that access customer data. The SOC 2 principles were designed to ensure the security and privacy of customer data

What are SOC 2 Trust Service Criteria and other requirements

SOC 2 Compliance and resulting audits are based on Trust Service criteria. With SOC 2, organizations can design their own controls to meet the trust principles defined by SOC 2. There are five trust service criteria:

• Security – Prevent unauthorized access to systems and data
• Availability – Ensure critical systems and data are available at all times
• Processing integrity – Systems and data flow must be able to process data in a way that is acceptable to all business stakeholders
• Confidentiality – Ensure sensitive data is protected at all costs
• Privacy – This criteria only applies to personal information. It outlines the processes to protect personally identifiable information (PII) during its use, processing, collection, disclosure, or disposal.

In addition, the Privacy criteria are organized as follows:

• Notice and communication of objectives
• Choice and consent
• Collection
• Use, retention, and disposal
• Access
• Disclosure and notification
• Quality
• Monitoring and enforcement

There are additional criteria as defined that help organizations meet the requirements outlined by the trust services, including the following:

• Logical and physical access controls – The restriction of logical and physical access to prevent unauthorized access
• System operations – It defines how organizations manage the logical and physical security deviations that may creep into an environment and how systems are operated
• Change management – How changes are managed in the environment in a controlled way that prevents unauthorized changes
• Risk mitigation – These criteria define how an organization identifies, selects, and develops risk mitigation activities

How are the trust service criteria used for evaluation?

As defined by SOC 2, the trust criteria provide flexibility in applying them, allowing them to be used in various ways and in different types of organizations. The practitioner is the term used to define the CPA who examines the controls within an entity’s organization relevant to the security, availability, processing integrity, confidentiality, or privacy. The practitioner uses these trust services criteria to gauge how well the business aligns with SOC2 core principles.

Many trust services criteria include the phrase to meet the entity’s objectives. Depending on the specific entity, their business requirements, environment, technology systems, and other factors, interpretation of that phrase depends on the needs and circumstances of each individual entity. When using the trust services criteria, SOC 2 practitioners consider each entity’s objectives as defined. 

It is essential to understand that some focus points may not be suitable or relevant to the entity or the audit. In these cases, management may customize a particular focus point and consider specific characteristics and criteria related to their organization. Using the trust services criteria does not require that every point of focus for each trust services criteria is addressed. 

Risks to achieving objectives based on trust services criteria

The AICPA defines certain risks that can challenge the achievement of the principles outlined by the trust services criteria. What are these?

• The operational environment of an entity
• The operation environment
• The different types of information generated, used, processed, stored, or otherwise
• Commitments and partnerships between customers, third parties, or others
• The different technology types
• The various responsibilities involved in operating and maintaining systems and processes
• The use of third parties and their services
• Changes to operations, the volume of data, management personnel, legal and regulatory requirements
• New products, services, or technologies

These risks and others can be dealt with using suitably designed controls that provide reasonable assurance of achieving the criteria as defined in the trust services.

Trust Services Criteria and the related points of focus 

As documented by AICPA, the following objectives are the trust services criteria and related points of focus. The Committee of Sponsoring Organizations of the Treadway Commission (COSO) states that focus points represent essential characteristics of the Trust Services Criteria. There are 17 principles defined in the COSO framework along with supplemental criteria. These focus points help management design and implement security, availability, processing integrity, confidentiality, and privacy controls. These also help to understand whether the controls are adequately designed and operating effectively to achieve the outlined security objectives. 

• Control Environment – CC1.1
  • COSO Principle 1: The entity demonstrates a commitment to integrity and ethical values.
  • COSO Principle 2: The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
  • COSO Principle 3: Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
  • COSO Principle 4: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
  • COSO Principle 5: The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
• Communication and Information – CC2.1
  • COSO Principle 13: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
  • COSO Principle 14: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
  • COSO Principle 15: The entity communicates with external parties regarding matters affecting the functioning of internal control. 
• Risk Assessment CC3.1
  • COSO Principle 6: The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives
  • COSO Principle 7: 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
  • COSO Principle 8: The entity considers the potential for fraud in assessing risks to the achievement of objectives.
  • COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control.
• Monitoring Activities – CC4.1
  • COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
  • COSO Principle 17: 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.
• Control Activities – CC5.1
  • COSO Principle 10: The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
  • COSO Principle 11: The entity also selects and develops general control activities over technology to support the achievement of objectives.
  • COSO Principle 12: The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action.
• Logical and Physical Access Controls – CC6.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.
• System Operations – CC7.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.
• Change Management – CC8.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.
• Risk Mitigation – CC9.1
  • The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions

SOC 2 certification for business partners

The SOC 2 compliance framework provides many benefits for businesses that use it to bolster their cybersecurity posture. It is also a certification you want to look for with any third-party cloud solutions you partner with to house resources and data. 

You want to ensure your cloud SaaS partners are SOC 2 compliant and certified with the designation. In addition, it helps you have confidence in cloud partners who house your business-critical services and data. If you fall under other compliance frameworks, most require any third parties you use for outsourced services to fall under specific security standards. When those partners have the SOC 2 designation, it makes your own internal security audits easier. 

SpinOne is an all-in-one platform that protects your SaaS data across multiple environments, including Google Workspace, Microsoft Office 365, and Salesforce. It integrates with the most popular business apps to deliver seamless work for SecOps aiming to save their time and budget. On top of the features and capabilities offered by SpinOne for organizations looking to protect and secure their data, it aligns with security best practices and regulatory requirements.

On top of being SOC 2 certified, note the following:

• SpinOne uses secure cloud partners, including Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP)
• Customers can choose which geographic region houses their data which allows aligning with data sovereignty and geolocation challenges with ease

SpinOne allows customers to choose their cloud provider and region for storing their data

• It uses TLS 1.3 for transmitting data and AES-256 for storing data
• Physical access is provided by the best-in-class data centers maintained by cloud service provider partners (AWS, Azure, and GCP)
• It supports customer regulatory, legal, and contractual requirements and conducts frequent assessments to ensure Spin complies with the following:
  • The General Data Protection Regulation (GDPR)
  • The Health Insurance Portability and Accountability Act (HIPAA)
  • The California Consumer Privacy Act (CPPA)
  • The Payment Card Industry Data Security Standard (PCI-DSS)
• SOC 2 Type II – Spin annually undergoes a SOC 2 Type II audit

Learn more about SpinOne compliance and data security standards and book a demo for either Google Workspace or Microsoft 365 here: Spin Technology