The Definitive SOC 2 Compliance Guide

Every day, service organizations handle sensitive customer information covered by data protection laws and subject to security compliance requirements. In the business-to-business world, customers require that their vendors provide validation and assurance over their privacy and security controls, typically asking for independent third-party attestations and reports.

As part of business operations, many organizations use the System and Organization Controls (SOC) audit process to provide assurance over their system-level controls. Developed by the American Institute of Certified Public Accountants (AICPA), the SOC framework evaluates and reports on controls that protect data security, availability, processing integrity, confidentiality, and privacy.

By understanding what a SOC 2 audit is and its evaluation requirements, organizations can accelerate audit readiness as they scale their business operations.

What is SOC 2?

SOC 2 is an attestation framework that requires an third-party independent audit to examine all data protection controls. Organizations can choose between two different SOC 2 report types:

• SOC 2 Type 1: Addresses whether the service organization’s controls are suitably designed at a specific point in time without addressing operating effectiveness.
• SOC 2 Type 2: Addresses both the suitability of design and the operating effectiveness of controls over a specified period, including a detailed description of tests performed and their results.

Most customers request a SOC 2 Type 2 report when engaging in due diligence because the requirements focus on control continuous effectiveness rather than simple design existence. The AICPA-CIMA defines the attestation standards, outlined in the Trust Services Criteria which are aligned to the 17 principles of the Committee of Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Integrated Framework.

What are the SOC 2 Trust Services Criteria (TSC)?

The Trust Services Criteria (TSC) are the benchmarks that auditors use when evaluating an organization’s controls. A SOC 2 audit includes, at minimum, review of the organization’s system objectives related to security. Over time, organizations often expand their audit scope to include the other four categories.

Security

The Security criteria address how well an organization protects information and systems from unauthorized access and data disclosure that could compromise data availability, integrity, confidentiality, or privacy.

Security controls include preventing or detecting:

• System failures.
• Unauthorized access.
• System resource theft or removal.
• Software misuse.
• Improper access to or alteration of data.

Availability

The Availability criteria address whether information and systems remain accessible for operations and use. Availability focuses on whether the organization implemented controls that support keeping information usable for systems, products, and services.

This category only addresses whether systems include controls to support accessibility for:

• Operation.
• Monitoring.
• Maintenance.

Processing integrity

Processing integrity addresses whether system processing is complete, valid, accurate, timely, and authorized to meet the entity’s objectives. Since organizations typically operate multiple systems, most typically scope this audit to the system or functional level.

Processing integrity focuses on controls for ensuring that systems achieve their intended purpose free from:

• Impairment
• Error, delay, omission.
• Unauthorized or inadvertent manipulation.

Confidentiality

Confidentiality addresses the organization’s ability to protect data designated as confidential. The audit reviews control across the information life cycle from collection or creation through final disposition and removal.

Confidential information is defined as:

• Custodians must limit access, use, and retention.
• Custodians must restrict disclosure to defined parties.

Unlike privacy, confidentiality applies to various types of sensitive information.

Privacy

Privacy only applies to personal information. The privacy criteria include:

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

What are the Common Criteria?

The Common Criteria (CC) defines the types of controls that organizations must implement and maintain across all TSC.

Control Environment (CC1)

Control environment criteria define how to create a cultural and organizations foundation that supports the rest of the control requirements:

• 1 – Commitment to Integrity and Ethical Values: Commitment to integrity and ethical values.
• 2 – Board Independence and Oversight: Board of director oversight related to the development and performance of internal controls.
• 3 – Organizational Structure and Authority: Management’s establishment of structures, reporting lines, and appropriate authorities and responsibilities.
• 4 – Commitment to Competence: Commitment to attracting, developing, and retaining competent personnel, contractors, and vendor employees.
• 5 – Accountability for Internal Control: Personnel accountability for internal control responsibilities.

Communication and Information (CC2)

Communication and information criteria focus on how well the organization shares information about control effectiveness with internal and external stakeholders. It includes the following:

• 1 – Quality Information: Relevant, quality information to support the functioning of internal control, including identifying information requirements, capturing data from internal and external sources, and maintaining quality throughout processing.
• 2 – Internal Communication: Internal communications that support the internal control’s functioning so people can carry out their responsibilities.
• 3 – External Communication: External communication about the internal control’s functioning of internal control, including communicating with customers, regulators, vendors, and business partners.

Risk Assessment (CC3)

The risk assessment criteria require the organization to identify, analyze, and address risks that could impact business objectives, including risks arising from risks arising from technology, fraud, and organizational change. This section includes the following:

• 1 – Objective Specification: Risk identification and assessment, including establishing sub-objectives related to security, availability, processing integrity, confidentiality, and privacy.
• 2 – Risk Identification and Analysis: Identifying information assets, threats and vulnerabilities while assessing criticality and considering vendor and business partner risks.
• 3 – Fraud Risk Assessment: Considering fraud when assessing risks to the achievement of objectives, including evaluating IT use and information access risks.
• 4 – Change Risk Assessment: Identifying and assessing how changes could impact the internal control, including changes to systems and technology and changes in vendor and business partner relationships.

Monitoring Activities (CC4)

The monitoring criteria focuses on how well the organization verifies that controls exist and function as intended, including whether it identifies and remediates issues. This section includes:

• 1 – Ongoing and Separate Evaluations: Selection, development, and performance of ongoing and separate evaluations to determine whether an internal control is present and functioning, including penetration testing, independent certifications, and internal audit assessments.
• 2 – Communication of Deficiencies: Evaluation and timely communication of internal control deficiencies to responsible parties, including senior management and the board of directors as appropriate, and monitors whether deficiencies are remedied on a timely basis.

Control Activities (CC5)

The control activities criteria address how the organization selects, develops, and deploys the specific controls that mitigate identified risks, including implementing policies and technologies. This section outlines:

• 1 – Risk-Mitigating Control Activities: Selecting and developing control activities that help mitigate to acceptable levels, including a range and variety of controls that balance manual and automated, preventive and detective approaches.
• 2 – Technology General Controls: Selecting and developing general technology control activities that support objectives, including controls over technology infrastructure, security management processes, and technology acquisition, development, and maintenance.
• 3 – Policy and Procedure Deployment: Establishing and periodically reviewing policies and procedures that assign responsibility and accountability.

Logical and Physical Access Controls (CC6)

The logical and physical access control criteria address how the organization restricts and monitors access to information assets. This section outlines:

• 1 – Logical Access Security: Logical access to software, infrastructure, and architecture over protected information assets, including identifying and managing information assets, restricting access, managing credentials, and using encryption to protect data at rest.
• 2 – User Registration and Deprovisioning: Registration and authorization to new internal and external users, and credential removal when access is no longer authorized.
• 3 – Role-Based Access and Least Privilege: Authorizing, modifying, or removing access to data, software, functions, and other protected information assets based on roles and responsibilities, considering the principle of least privilege and segregation of duties.
• 4 – Physical Access Restrictions: Restricting physical access to facilities and protected information assets to authorized personnel, with processes to create, remove, and periodically review physical access.
• 5 – Asset Disposal: Discontinuing protections over physical assets only after removing their ability to read or recover data and before disposal.
• 6 – External Threat Protection: Logical access security measures to protect against threats from sources outside system boundaries, including boundary protection systems such as firewalls, demilitarized zones, and intrusion detection systems.
• 7 – Transmission and Movement Controls: Restricting authorized internal and external user and process information transmission, movement, and removal of information, and protecting information during transmission through encryption or secured communication channels.
• 8 – Malicious Software Prevention: Implementing controls to prevent or detect and act upon the introduction of unauthorized or malicious software, including restricting software installation, using antivirus and anti-malware tools, and applying a defined change control process.

System Operations (CC7)

The system operations criteria address how the organization detects, evaluates, and responds to security events. These controls include:

• 1 – Vulnerability and Configuration Monitoring: Detection and monitoring procedures to identify configuration changes that can introduce new vulnerabilities and scanning for newly discovered vulnerabilities.
• 2 – Anomaly Detection: Monitoring system components and their operation for abnormal behavior that can indicate potential malicious activity, natural disasters, and errors, including using detection policies, procedures, and tools to identify various potential security events.
• 3 – Security Event Evaluation: Responding to and evaluating security events, including whether controls failure to meet objectives then preventing or addressing such failures.
• 4 – Incident Response: Identifying security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, including assigning roles, containing threats, restoring operations, and evaluating response effectiveness.
• 5 – Incident Recovery: Identifying, developing, and implementing activities to recover from identified security incidents, including restoring the affected environment, determining root cause, implementing changes to prevent recurrence, and conducting periodic incident-recovery plan testing.

Change Management (CC8 Series)

The change management criteria evaluate how the organization controls system and infrastructure changes. This section includes:

• 1 – System Change Management: Authorizing, designing, developing or acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures, including managing changes throughout the system lifecycle, establishing baseline configurations, and providing for changes necessary in emergency situations.

Risk Mitigation (CC9)

The risk mitigation criteria address how the organization prepares for and manages risks that fall outside its direct control. This section focuses on:

• 1 – Business Disruption Risk Mitigation: Identifying, selecting, and developing risk mitigation activities for risks arising from potential business disruptions, including developing planned policies, procedures, communications, and alternative processing solutions to respond to and recover from security events.
• 2 – Vendor and Business Partner Risk: Assessing and managing vendor and business partner risks by establishing requirements for engagements, assessing vendor risks on a periodic basis, assigning accountability for vendor management, and implementing procedures for addressing issues and terminating relationships when necessary.

Best Practices for Demonstrating and Maintaining SOC 2 Compliance

Meeting the Trust Services Criteria is an ongoing operational responsibility, not a point-in-time exercise. The following practices help organizations build audit-ready programs that align with how the criteria are structured.

Centralize Log Collection

Many of the CC6 and CC7 criteria require organizations to identify, monitor, and respond to activity across their entire environment. By centralizing all security relevant logs in a single location, organizations gain the necessary visibility to satisfy detection and monitoring requirements.

When selecting a technology solution to support this capability, organizations should consider:

• Scalable log ingestion that collects, parses, and normalizes data from diverse and distributed sources.
• Flexible deployment options across on-premises, cloud, and hybrid architectures to accommodate different system boundaries.
• Tamper-evident retention using encryption and audit trails that support evidence integrity for assessments.
• Data enrichment that applies context to raw log data, like user identity, asset classification, and geolocation.

Continuously Monitor for Anomalies

Criteria CC7.1 and CC7.2 require organizations to detect configuration changes that introduce vulnerabilities and to identify abnormal behavior that might indicate a security incident. By correlating data from various log sources, security teams can create high-fidelity alerts that reduce noise and provide insight into indicators of compromise or policy violations.

When evaluating monitoring capabilities, organizations should look for:

• Rule-based alerting and anomaly models that establish baseline behaviors and detect deviations from them.
• File integrity monitoring and change-detection mechanisms to identify unauthorized modifications to critical system files or configurations.
• Vulnerability scanning integrations to identify newly discovered weaknesses and track remediation status over time.
• Fast correlation across all log sources to support real-time risk determination.

Build an Auditable Incident Response Workflow

Criteria CC7.3 through CC7.5 outline specific requirements for evaluating security events, executing incident response, and recovering from incidents. An auditable cyber investigation workflow provides documentation that auditors can use to assess operating effectiveness.

When designing or selecting incident response capabilities, organizations should look for:

• Defined case management workflows that capture evidence, assign tasks, and track containment and remediation steps.
• Interactive investigation timelines that reconstruct attack sequences and support rapid triage.
• Communication and escalation records that document internal and external notifications in alignment with the incident-response program.
• Periodic testing and improvement cycles that update the incident-recovery plan based on lessons learned and simulated scenarios.

Enforce and Document Access Controls

Auditors will test whether the organization appropriately provisions and deprovisions access, including whether it maintains the principal of least privilege, restricts and reviews physical access, and applies encryption and data loss prevention controls for data in transit and at rest.

Supporting these requirements operationally requires:

• Identity and access management processes tie credential provisioning and deprovisioning to documented authorizations from asset owners.
• Role-based access control that enforces segregation of duties and restricts access to the minimum required for each function.
• Periodic access reviews that validate whether current access roles and permissions remain appropriate.
• Encryption controls for data at rest and in transit, with documented key management processes.

Build Dashboards for Continuous Compliance Visibility

SOC 2 Type 2 engagements require organizations to demonstrate that controls consistently operate as intended throughout the audit period. Dashboards that provide at-a-glance visibility into control status, security event trends, user activity, and system health make it easier for compliance and security teams to identify gaps and provide auditors with evidence.

Effective compliance dashboards should support:

• Pre-built views covering user activity, privileged account usage, authentication patterns, and network activity.
• Scheduled reporting that delivers compliance summaries to relevant stakeholders on a regular cadence.
• Filtered views that allow scoping by time range, asset group, or category to align with the audit period and scope.
• Threat coverage mapping to surface potential control gaps before they become audit findings.

Graylog: Enabling Continuous SOC 2 Compliance Monitoring

Graylog enables organizations to centralize, analyze, and act on security data at scale by providing the detection, investigation, and reporting capabilities that SOC 2 compliance requires. With centralized log management, real-time alerting, AI-assisted investigations, and purpose-built compliance dashboards, Graylog helps security and compliance teams demonstrate control effectiveness throughout the audit period and respond to incidents faster when they occur.

To learn more about how Graylog supports SOC 2 compliance and improves your overall security posture, contact us today for a demo.