SOC 2 Trust Principles: Picking the Right Attestation Criteria for Your Business
As Mike Wright, CIO of McKinsey and Company, opines, “For many organizations, IT is a black box, which can lead to a lot of questions about what you are doing and why.”
Where customer data is involved, these questions embody doubts, which, when left unresolved, erode trust. One way to build customer trust is by adhering to relevant SOC 2 trust principles.
So, what are SOC 2 trust service principles?
In this article, we’ll delve into the nuances of the five trust service principles. We’ll also discuss what each principle entails, who it applies to, and the criteria tested as part of each principle. The goal is to help you determine which trust principles apply to your organization and how you can meet their specified standards.
What are SOC 2 trust services principles?
The trust principles you select inform your attestation criteria. Your trust service criteria must also be suitable and available to report users.
The American Institute of Certified Public Accountants (AICPA) defines the attributes of suitable criteria as follows:
- Relevance. The criteria should be admissible to the subject matter.
- Objectivity. It should also be free from bias
- Measurability. It should allow consistent measurements — quantitative or qualitative — of subject matter.
- Completeness. Criteria shouldn’t disregard relevant factors that could influence the decision-making process of intended users
Trust service principles are categories in SOC 2 compliance control criteria used to evaluate relevant controls for information and systems.
The AICPA specifies five main principles, namely:
- Processing integrity
Are all Trust Principles Requisite for SOC 2 Audit?
Your organization isn’t required to audit and certify every trust service principle in the SOC audit report.
Security is the only principle that is required to become SOC 2 compliant. The others are optional.
That said, you should select principles that are relevant to the services you provide or the demands of the users you serve.
For example, if you store data for clients but don't process it, then availability would be a key principle. Something like processing integrity wouldn't be applicable.
What if a client asks you to include all criteria?
The rule of thumb is that you don't need to include every trust service principle. If a client is asking for all of the TSP, chances are they don’t understand what they need.
In this case, you have to explain to the customer what each principle means and when it's applicable. The goal is to help them understand what they need and, more importantly, what they don’t need for their business.
Having in-depth knowledge of the trust principles comes in handy for this.
Trust Service Principles: Nailing SOC 2 Attestation Requirements
SOC 2 requirements revolve around the five Trust Services Principles.
Your attestation criteria is as simple or complex as the trust principles you choose. The simplest you can get is testing for the security alone, which is mandatory.
However, based on factors such as the services you provide, user entity demands, contractual obligations, or legal requirements, you may have to add one or all of the other four.
As a result, a complete set of SOC 2 criteria consists of:
- The common criteria (security trust service criteria) and/or
- Additional specific criteria for processing integrity, availability, confidentiality, and privacy.
Trust service category
Additional category-specific criteria
- Processing integrity
Let’s discuss the fine details of each Trust Service Principle, starting with security.
The Microsoft data breach in 2019, which exposed over 250 million user records, was a wake-up call to technology-based organizations. It served as evidence that no organization is immune from data breaches.
As a SaaS provider, all you can do is implement useful data security systems and internal controls to repel these threats.
Your customers want to see evidence of proper security systems before they will ink any deal with you. This is where the security TSP comes in handy.
Security refers to the protection of data during its creation, gathering, processing, storage, use, and transmission. It provides criteria you can use to audit and evaluate how effective your security system is for protecting user data.
The criteria tested as part of the security TSP are defined as the common criteria (CC-series).
The common criteria guides you when developing, implementing, and operating controls over security. It provides the specific criteria sections suitable for auditing and evaluating security control to achieve systems objectives.
Common criteria lays out the 17 internal control principles of the Committee of Sponsoring Organization of the Treadway Commission (COSO) framework.
It provides the criteria for addressing:
- CC1 — Control environment: It covers the first five principles of the 2013 COSO framework. This entails the service entity’s commitment to ethical values and integrity, board of directors’ independence, structures and reporting lines, and accountability of individuals responsible for internal controls.
- CC2 — Communication and information: Addresses COSO principles 13-15, including sections like generation of quality information, internal communication of information, and communication with external parties about matters affecting how internal controls work.
- CC3 — Risk assessment: Addresses COSO principles six through nine, including identification and assessment of risk, analysis of internal and external risk factors, and assessment of the type of fraud. Beyond that, it covers the assessment of changes in the business model and external environment that could impact internal security control.
- CC4 — Monitoring controls: Addresses 2013 COSO framework principles 16-17, including an evaluation to determine whether internal controls are present and functioning. It also checks whether the evaluation and communication of internal controls deficiencies is done on time.
- CC5 — Control activities: The last category covers principles 10-12. It tests whether the relevant internal controls responsible for the mitigation of risk are present. It also seeks to discover whether these controls are checked on an ongoing basis.
As Mark Russinovich, Chief Technology Officer at Microsoft Azure, states, “Service incidents like outages, are an unfortunate inevitability of the technology industry.” In other words, you cannot guarantee 100% system uptime.
However, your clients want data and system resources to be available for operation. This is especially true for cloud service providers who provide cloud computing or cloud data storage services.
If you offer a continuous delivery and/or continuous deployment (CI/CD) platform, an outage prevents clients from building or deploying changes to their services. Your clients will require you to add the availability in a SOC 2 report as an assurance of minimal service disruption.
Availability TSP refers to the accessibility of resources and data your systems use, as well as services and products you provide to clients. It gives clients assurance that you’ll reach the performance levels required to meet their needs.
This TSP doesn’t define the minimum acceptable performance levels. Instead, it leaves room for service providers and user entities to set and agree upon the required levels. However, it also requires your systems have the proper controls to facilitate accessibility for monitoring, operations, and maintenance.
To help you prepare for SOC 2 attestation, AICPA states three additional criteria for availability (A-series).
- A1.1: Monitor, evaluate and maintain current processing capacity and apply system components to uphold capacity demand. You should also enable the deployment of extra capacity where need be to meet Service Level Agreements (SLAs).
- A1.2: Design, develop, approve, implement, acquire, operate, monitor, and maintain software, recovery infrastructure, and data backup services to meet your availability objectives.
- A1.3: Test the recovery procedure’s anchoring system recovery to meet your availability goal.
If you provide financial reporting services or ecommerce, you should strive to maintain internal quality assurance.
For example, if you provide a financial application, you should make sure system processing is correct, timely, complete, valid, and authorized to meet the laid out standards. These are the hallmarks of processing integrity.
Processing integrity is an indispensable trust principle in an era laden with financial fraud, such as authorized push payment (APP) fraud. Your Clients will want to see this TSP in your SOC 2 report to ensure that your transaction processing is accurate.
Processing integrity helps evaluate systems to determine whether they perform the intended functions in a way that is free from delay, error, omission, and accidental manipulation.
The AICPA states five additional criteria for processing integrity, known as the PI series.
- PI1.1: Generate, use, and share quality information about your processing objectives to support the use of services and products.
- PI1.2: Implement procedures and systems over system inputs. This includes controls over the accuracy and completeness of system processing.
- PI1.3: Implement procedures and policies over system processing. Define processing specifications and activities, record system processing activities, pinpoint and rectify production errors, and process inputs.
- PI1.4: Implement procedures and policies for an accurate, complete, and timely delivery of outputs.
- PI1.5: Implement procedures and policies to protect stored resources, record system storage activities, store data accurately, and archive system records.
The confidentiality TSP applies to service organizations that hold confidential information.
Confidential information includes various types of sensitive data like financial reports, passwords, lists of prospective customers, business strategies, customer databases, and other intellectual property.
The confidentiality principle refers to an organization's ability to safeguard confidential information through every phase of its processing. This ranges from collection to disposal.
If you handle such user data, you should limit its access, storage, and use. It’s also a good idea to restrict its disclosure to authorized parties only.
There are two confidentiality-specific criteria (C series):
- C1.1: Put procedures in place to identify confidential information and protect it from destruction.
- C1.2: Put procedures in place to pinpoint confidential information for destruction, and erase or otherwise destroy it.
Did you know that for every dollar spent on data privacy, your organization racks up $2.70 worth of improvements on data loss, agility, mitigation and customer loyalty?
Also, 82% of your potential customers see SOC 2 certification and ISO 27701 as a buying factor when selecting a vendor.
Privacy is an indispensable component in building trust with clients. When it comes to SOC 2 compliance, the privacy principle refers to how your organization gathers, stores, uses, preserves, reveals, and disposes of personal information.
Unlike confidentiality, which covers various forms of sensitive information, privacy deals only with personal information.
The privacy criteria is broken down into the following sections (P-series):
- P1 — Notice and communication of objectives: The entity notifies data subjects about its privacy objectives.
- P2 — Choice and consent: The entity explains the options available for collection, retention, use, disclosure, and disposal of personal information.
- P3 — Collection: The entity collects personal information based on its privacy objectives.
- P4 — Use, retention, and disposal: The entity uses, preserves, and disposes of personal information as per the stipulated privacy objectives.
- P5 — Access: The entity allows clients to access personal information for review and collection based on privacy objectives.
- P6 — Disclosure and notification: You should only reveal personal information to clients based on privacy objectives. Plus, deliver notifications of incidents and data breaches to affected clients to meet objectives related to privacy.
- P7 — Quality: You should gather and maintain up-to-date, accurate, relevant, and complete personal information as per privacy objectives.
- P8 — Monitoring and enforcement: You should check compliance to guarantee adherence to procedures to address privacy-related complaints, inquiries, and disputes.
What are SOC 2 supplemental criteria?
In addition to the 17 principles presented in the COSO framework, the trust service criteria include supplemental criteria.
The supplemental criteria cover additional principles supplementing COSO principle 12 (under the control activities in common criteria).
It addresses the objectives that apply to a trust service engagement and breaks down into:
- Logical and physical access controls: This criterion relates to how you restrict access (both physical and logical), grant or remove that access, and thwart unauthorized access.
- System operations: Addresses how you manage operations and uncover and mitigate processes that deviate from the norm.
- Change management: Covers how you handle changes, implement changes using a standard change management process and prevent unauthorized changes.
- Risk mitigation: Lastly, how do you discover, pick, and create risk mitigation activities emanating from potential business disruptions.
Let’s pick the perfect trust service criteria for you
As mentioned earlier, your trust service criteria should be relevant, objective, measurable, and complete. However, with so many trust principles and categories to consider, it can be difficult to pick criteria that fit the profile. This is where Secureframe comes into the picture.
We evaluate your service organization needs along with any contractual or legal obligation to pick the right Trust Service Principles for you. Request a Secureframe demo to learn how we can help you determine which trust principles apply to your business and how you can meet the criteria.