SOC Compliance Requirements: A Complete Guide to the Trust Services Criteria

SOC compliance requirements are the control criteria that a service organisation must satisfy to obtain a SOC 2 attestation report. They are defined by the American Institute of Certified Public Accountants (AICPA) through the Trust Services Criteria (TSC) — a framework that specifies what outcomes your controls must achieve across five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Unlike prescriptive frameworks such as PCI DSS, the Trust Services Criteria do not dictate which specific controls you must implement. They define what your controls must accomplish — how you get there is your organisation’s decision, documented in your system description and evidenced through your audit. This guide covers what each criterion requires, how to select the right criteria for your scope, and what auditors examine during fieldwork.

What SOC Compliance Requirements Are — and What They Are Not

SOC 2 is an attestation framework for a service organization, not a certification standard. SOC compliance frameworks dictate how service organizations should handle data assets and internal operations. There is no checklist of required controls that every organisation must implement identically. The Trust Services Criteria define principles and points of focus — the outcomes your control environment must achieve — and each organisation selects the controls that satisfy those outcomes given its specific systems, services, and risk profile.

This flexibility is genuine but it comes with a responsibility: you must be able to explain and evidence every control decision your auditor examines. An auditor testing the Security criterion will assess whether your controls achieve the required outcomes, not whether you followed a prescribed implementation. Organisations that treat SOC 2 as a checklist exercise — implementing controls because they appear on a template rather than because they address a specific criterion — typically produce weaker evidence and more audit findings than organisations that design controls from the criteria outward.

The Trust Services Criteria are published in the AICPA’s 2017 TSC document, with subsequent guidance updates. They apply to all SOC 2 engagements regardless of the Type (Type 1 or Type 2) or the auditor conducting the engagement.

Differentiating between type I and type II audits

Before diving into controls, you need to choose your audit flavor. Type I focuses on design—think of it as a snapshot showing that your controls are well drawn, if not yet battle-tested. 

Type II examines both design and operating effectiveness over a period (typically three to twelve months), including tests like penetration attempts and continuous monitoring exercises.

PRO TIP

Align your audit selection with release cycles—if you deploy quarterly, opt for Type II so auditors see controls tested across multiple iterations rather than a single snapshot.

Diving into the trust services criteria pillars

At the heart of every SOC 2 report lies the Trust Services Criteria (TSC)—five pillars that define what “secure and The Five Trust Services Criteria Categories

Security (Common Criteria) — Mandatory

The Security criterion — also called the Common Criteria — is mandatory in every SOC 2 report. It is the foundation on which the other four criteria build. The Common Criteria are organised into nine control categories, CC1 through CC9.

CC1 — Control Environment: The organisation demonstrates a commitment to integrity and ethical values, with governance structures that support accountability for information security objectives and internal governance over security objectives. Board or management oversight of security is a specific focus area.

CC2 — Communication and Information: The organisation obtains, generates, uses, and communicates relevant information to support the functioning of its security controls. This includes communicating control responsibilities to internal and external parties.

CC3 — Risk Assessment: The organisation specifies security objectives, identifies risks to the achievement of those objectives, and assesses those risks as a basis for determining how the risks should be managed. A formal, documented process covering risk assessments is required, and organisations should maintain policies, procedures, and related records to evidence compliance.

CC4 — Monitoring Activities: The organisation selects, develops, and performs ongoing and separate evaluations to determine whether controls are operating effectively. Separate evaluations — such as internal audits and penetration tests — satisfy the requirement for independent assessment.

CC5 — Control Activities: The organisation selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives. This criterion governs the selection, design, and implementation of the controls themselves.

CC6 — Logical and Physical Access Controls: The organisation implements logical access security measures to protect against threats from sources outside its system boundaries, registers and authorises new internal and external users, and removes access when no longer required. This is the most operationally demanding criterion area: it requires strong authentication mechanisms, including multi factor authentication and single sign-on, along with formal access provisioning and de-provisioning processes, role based access controls, periodic access reviews, and privileged access management.

CC7 — System Operations: The organisation detects and monitors security events, evaluates those events to determine whether they constitute security incidents, and responds to identified incidents. Logging and alerting, vulnerability management — including automated scans and routine penetration testing to identify weaknesses and protect network security — and incident response procedures are all assessed here.

CC8 — Change Management: The organisation authorises, designs, develops, configures, tests, and approves infrastructure and software changes before implementing them in the production environment. A formal change management process with documented approvals and test outcomes is required.

CC9 — Risk Mitigation: The organisation identifies, selects, and develops risk mitigation activities arising from potential business disruptions and selects vendors and business partners that meet its security requirements as part of vendor management. Vendor risk management and business continuity planning fall under this criterion.

Availability — Optional

The Availability criterion applies when the organisation has made commitments to customers about system uptime or when service unavailability would cause customers direct business harm. It assesses whether systems are available for operation and use as committed or agreed, including system availability commitments defined in service level agreements. Across the Trust Services Criteria, security protects against unauthorized access, availability ensures systems are operational as agreed, confidentiality protects sensitive data from unauthorized disclosure, processing integrity ensures data processing is accurate and timely, and privacy safeguards personal information in line with relevant laws.

The key requirements under Availability are: documented availability commitments and system performance metrics, monitoring of system capacity and performance against those commitments, business continuity and disaster recovery planning with tested recovery procedures, and processes for handling availability incidents with defined recovery time objectives (RTOs) and recovery point objectives (RPOs), including responding to outages and recovery events in a timely manner.

For financial institutions providing technology services with contractual uptime SLAs, or for payment processors where downtime has direct financial consequences, Availability is almost always in scope where the customer commitment includes ongoing access to the service.

Processing Integrity — Optional

Processing Integrity applies when the accuracy, completeness, timeliness, and validity of system processing is a customer commitment. It is most relevant for payroll processors, financial calculation engines, transaction settlement platforms, and any service where processing errors would directly affect the customer’s financial records or operations.

The requirements focus on: controls to ensure that processing inputs are complete and valid before processing begins, controls to detect and correct processing errors, and monitoring of processing outputs against expected results, with controls that support accurate data processing and timely correction of errors.

Confidentiality — Optional

The Confidentiality criterion applies when the organisation handles information that has been designated as confidential — intellectual property, financial data, strategic plans, customer data, or other sensitive data that the organisation has contractually committed to protect from disclosure.

The key requirements are: identification and classification of confidential information, controls restricting access to confidential data on a need-to-know basis, encryption of confidential data in transit using TLS/HTTPS and at rest using strong algorithms such as AES-256, and procedures for the secure disposal of confidential information when retention obligations end.

For financial institutions handling commercially sensitive client data, M&A information, or credit analysis, Confidentiality is typically in scope alongside Security, helping mitigate risks tied to security, availability, processing integrity, confidentiality, and privacy while reducing the likelihood or impact of data breaches.

Privacy — Optional

The Privacy criterion applies when the organisation collects, uses, retains, discloses, or disposes of personal information in connection with its services, including how the organization collects that data in the first place. It addresses how the organisation manages the full lifecycle of personal data against the AICPA’s Privacy Management Framework, with data minimization as a core part of that lifecycle.

The requirements cover: notice to individuals about data collection and use, consent mechanisms where required, access rights for individuals to their personal data, data quality and accuracy controls, data retention and disposal procedures, and the organisation’s privacy monitoring and enforcement processes. These privacy controls are designed to protect sensitive information, including protected health information where relevant, and help ensure controls comply with applicable expectations.

For EU-based organisations, the Privacy criterion overlaps significantly with GDPR Article 5 principles. A well-implemented Privacy criterion under SOC 2 will satisfy the majority of GDPR’s accountability requirements for the in-scope processing activities, though GDPR’s lawful basis documentation and individual rights infrastructure extend beyond what SOC 2 Privacy requires, and privacy controls must comply with applicable regulatory compliance obligations.

PRO TIP

For each enabled pillar, tag one owner in your GRC or project tool (e.g., “Alice owns Confidentiality”). Clear ownership speeds evidence gathering when auditors ask for specific controls.

How to Select the Right Criteria for Your Scope

The criteria you include define the scope of your audit and, therefore, the depth of evidence you need to produce. Adding criteria increases audit scope and cost. Excluding criteria that are relevant to your customer commitments creates credibility gaps — customers who rely on your uptime guarantees will notice that Availability is absent from your report.

SOC 1 and SOC 2 reports focus on different assurance needs: SOC 1 addresses controls relevant to financial reporting, while SOC 2 covers security, availability, processing integrity, confidentiality, and privacy. The intended audience also differs, with SOC 1 aimed at user entities and their financial auditors, while SOC 2 is used more broadly by management and other stakeholders seeking controls assurance.

The selection decision should be driven by three questions:

What have you committed to customers? Review your service agreements and customer contracts. If you have committed to uptime levels, processing accuracy, or confidentiality of specific data categories, the corresponding criterion should be in scope.

What do your customers require? Enterprise buyers increasingly specify which criteria they expect to see in the SOC 2 report as part of procurement requirements, and a strong SOC report can build trust and support procurement. If your target market consistently requests Security plus Availability plus Confidentiality, exclude Availability at your own commercial risk.

What does your service actually touch? A service that processes personal data but excludes Privacy from the SOC 2 report will face questions from privacy-conscious buyers. A service that handles financial transactions but excludes Processing Integrity invites scrutiny of the omission.

The most common scope combinations are: Security only (minimum viable SOC 2, typical for early-stage companies); Security plus Availability (most common for SaaS companies with uptime commitments); Security plus Availability plus Confidentiality (common for B2B services handling sensitive business data); and all five criteria (relevant for B2C services handling personal data with strong privacy commitments). A type ii report often helps expedite vendor reviews and strengthen competitive positioning.

What Auditors Test Under Each Criterion

Understanding what auditors actually examine during fieldwork helps organisations prepare evidence correctly rather than assembling it retrospectively, as they test the organization’s controls and related evidence as part of the audit process.

For Security (CC6 — access controls): Auditors will request evidence of: MFA enforcement across in-scope systems (screenshots, configuration exports, or vendor-provided reports); a complete list of users with access to in-scope systems as of a specified date; evidence of at least one access review during the observation period, including a timestamped record of the review and any access changes made as a result; documentation of the joiner-mover-leaver process; and records of privileged access provisioning and de-provisioning. Auditors will also review existing controls over access systems, including the periodic access evidence already mentioned.

For Security (CC7 — system operations): Auditors will request: evidence that logging is enabled on all in-scope systems; a sample of security alerts and evidence of how they were investigated; the vulnerability management report covering the observation period, including remediation timelines; and the incident response procedure alongside records of any incidents that occurred during the period.

For Security (CC8 — change management): Auditors will select a sample of changes made during the observation period and request the corresponding change tickets, showing the change was approved before implementation, tested before deployment, and deployed by someone other than the developer where segregation of duties is applicable.

For Availability: Auditors will request: the documented uptime SLA or availability commitment; monitoring reports covering the observation period showing availability metrics against the commitment; evidence of at least one backup and recovery test; and the business continuity plan.

For Confidentiality and Privacy: Auditors will request: the data classification policy; evidence that confidential or personal data is encrypted at rest and in transit; the data retention and disposal schedule and evidence of disposal activities during the period; and records of any privacy or confidentiality-related requests or incidents, and may review how data centers and physical access controls protect hosted systems where relevant.

Over a Type II review, auditors collect evidence throughout the period to assess whether controls operated consistently. A Type I report evaluates controls at a specific point in time, while a Type II report examines operational effectiveness over the audit period.

SOC Compliance Requirements and ISO 27001

For organisations pursuing both SOC 2 and ISO 27001 simultaneously, the control overlap is substantial. The Security Common Criteria map closely to ISO 27001 Annex A controls — CC6 maps to A.5.15–A.5.18 (access controls), CC7 maps to A.8.15–A.8.16 (logging and monitoring) and A.5.26 (incident response), CC8 maps to A.8.32 (change management), and CC9 maps to A.5.19–A.5.23 (supplier relationships) and A.5.30 (ICT business continuity).

Organisations running an integrated programme — building controls against ISO 27001 Annex A and mapping them to the Trust Services Criteria — avoid duplicating the policy and evidence work, which can simplify compliance across overlapping frameworks. The same access review log satisfies CC6 and ISO 27001 A.5.18. The same change ticket satisfies CC8 and A.8.32. The same incident record satisfies CC7 and A.5.26. For financial institutions also subject to DORA, many of the same controls satisfy DORA’s ICT risk management requirements as well.

Common control domains and points of focus

To satisfy the TSC, you’ll layer specific controls under broader domains—each backed by points of focus that auditors reference when mapping controls to criteria.

PRO TIP

Create a searchable shared library (e.g., Confluence page) mapping each control domain to your actual artifacts—MFA logs, change-control tickets, BCP test reports—so evidence is one click away.

Breaking down the SOC 2 report contents

After your audit concludes, the SOC 2 report arrives like a detailed film of your controls in action. Here’s what you’ll find inside:

PRO TIP

After your initial audit, store the signed report and management assertion in a version-controlled repository with access logs. This shows auditors you’ve preserved evidence integrity over time.

Preparing for the audit and maintaining compliance year-round

Your SOC 2 journey begins with a readiness assessment—a practice audit to uncover gaps before the official engagement. You’ll address deficiencies, gather evidence (logs, policies, screenshots), and train your team. But compliance isn’t a finish line; it’s a habit built through continuous monitoring, regular risk reviews, and periodic control updates. Think of it as brushing your teeth: a daily routine that keeps cavities (and auditors’ red flags) at bay.

Streamline your SOC 2 compliance with Copla

SOC 2 compliance demands airtight controls, clear evidence, and proof that your security measures truly work under scrutiny. Copla offers predefined, customizable workflows aligned with Trust Services Criteria that automate tasks like background checks, access reviews, and incident logging. Real-time Slack and Teams prompts guide your team through every step, slashing manual effort by up to 80% and ensuring no control gets overlooked.

All compliance evidence—from vulnerability scans to MFA logs—is centralized in an audit-ready repository, making it easy to satisfy both ongoing monitoring and “separate evaluation” requirements under CC 4.1 and CC 7.1. Built-in risk assessments, pen-testing integrations, and continuous monitoring shore up your defenses, while our fractional CISO service provides expert guidance and strategic leadership. 

With Copla, you’ll not only meet today’s SOC 2 standards but build a scalable, future-proof compliance program—so audits become confirmation, not chaos.

Building a trust muscle that outlasts the audit

SOC 2 compliance isn’t a one-time checklist—it’s a shift toward continuous improvement. By mastering the core requirements—from the mandatory security pillar to the optional trust services criteria—you’re not just passing an audit; you’re signaling to customers that their data is in capable hands. Ready to lace up your compliance boots and lead the charge? Your fortress awaits.