Skip to content

What is SOC 2 Compliance?

Introduction

If you consider how rapidly organizations are increasing their cloud footprint, ensuring compliance with the different compliance and cloud security standards can get challenging very quickly. A SOC 2 audit is applicable to organizations that hold, store, or process customer data. In today's digital environment, any company storing customer data must meet SOC 2 requirements in order to minimize risk and exposure to that data. 

What is SOC 2 and why do we need it?

SOC 2 is an auditing procedure and report that is part of the SSAE (Statement on Standards for Attestation Engagements) maintained by the AICPA.  It is one of the more common compliance requirements that companies should meet today to be competitive in the market.  SOC 2 report ensures that a company's information security measures are in line with the unique parameters of today's cloud requirements. 

The SOC 2 audit is the auditor's opinion on how your organization's security controls/safeguards fit SOC 2 requirements and that's because the auditor's reputation is very important to SOC 2 audit and reporting. 

SOC2-certificationv2-crop

Only the security criteria is relevant for organizations in the public cloud.

The Different SOC Reports

The chart below explains the differences between SOC 1, SOC 2 and SOC 3 Reports. Soc 1 report is specifically for internal controls over financial reporting. This auditing standard replaces the now-deprecated SSAE no. 16 auditing standard which used to only apply to SOC 1 reports.  

What's the difference between SOC 1 and SOC 2?  The SOC 2 standards focus on the non-financial reporting on the internal controls and systems that you can implement to protect the confidentiality and privacy of data that are stored in cloud environments.  SOC 1 report is a report generated by auditors for other auditors, but a SOC 2 report usually has more confidential internal information which is not to be shared with others outside the company. SOC 2 report provides details about the nature of those internal controls. Both SOC 1 and SOC2 have two report types. 

SOC 3 reports are intended for users that do not need the full details of a SOC 2 report. SOC reports can help users assess and address the risks associated with an outsourced service. If an organization is applying for compliance, a SOC 2 report attests to whether the organization complied with regulatory requirements. 

SOC-Report-2

Security Criteria for Public Cloud

Each of the five SOC 2 trust criteria are comprised of nine specific sub-categories. Within the Security Criteria, these are the trust principles that are relevant for security and compliance teams responsible for public cloud infrastructure.

CC2.0: Communication and Information

CC5.0: Control Activities

CC6.0: Logical and Physical Access Controls

CC7.0: System Operations

CC8.0: Change Management

security-compliance-2

Security Criteria for Public Cloud

The different trust principles are discussed in more detail below.

CC 2.0: Communication and Information

The communications and information criteria of SOC 2 address how organizations handle internal and external communication and information flows.

CC2.1 states that “the entity obtains or generates and uses relevant, quality information to support the functioning of internal control.”

CC 5.0: Control Activities

The control activities criteria of SOC 2 deals with how organization control activities account for risk management and technology.

CC5.2 states that “the entity also selects and develops general control activities over technology to support the achievement of objectives.” This includes that management develops control activities to restrict technology access rights to authorized users commensurate with their job responsibilities and to protect the entity’s assets from external threats.

CC 6.0: Logical and Physical Access Controls

The logical and physical access controls criteria of SOC 2 concern how organization controls implement logical access to IT systems/credentials, physical access to facilities, and security measures to detect and prevent unauthorized access.

For example, CC6.1 states that “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.” Organizations should identify and authenticate users, consider network segmentation, manage credentials for infrastructure and software, use encryption to protect data, and protect encryption keys.

CC 7.0: System Operations

The system operations criteria of SOC 2 address how organization controls monitor systems for potential anomalies, events, and configuration changes that may carry security risks, and define incident response protocols to contain, remediate, and communicate security incidents.

CC7.1 elaborates that service organizations should monitor infrastructure and software, implement change-detection mechanisms, and detect unknown or unauthorized components. Fugue promotes compliance with CC7.1 by detecting when CloudWatch and CloudTrail are not enabled and configured correctly. For example, Fugue checks to ensure that a CloudWatch metric filter and alarm is enabled to catch changes made to IAM policies. Monitoring changes to IAM policies helps ensure authentication and authorized controls remain intact.

CC 8.0: Change Management

The change management criteria of SOC 2 deal with how organizations evaluate and determine necessary changes in infrastructure, data, software, and procedures, which gives them the ability to securely make changes and prevent unauthorized changes.

For example, CC8.1 addresses protecting confidential information - “The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.” The criterion further elaborates that service organizations should create baseline configurations of IT technology and protect confidential information.