SOC 2 Trust Principles and What Auditors Evaluate

Article Summary:    SOC 2 Trust Services Criteria define how auditors evaluate whether your controls protect data and support reliable operations.   Security is mandatory in every SOC 2 audit; Availability, Processing Integrity, Confidentiality, and Privacy are optional based on your scope.   Auditors use nine Common Criteria under Security to assess governance, access, monitoring, and risk management controls.   Availability demonstrates that your systems remain operational and meet stated uptime commitments.   Processing Integrity confirms data is processed completely, accurately, and on time.   Confidentiality ensures sensitive business information is properly identified and protected.   Privacy evaluates how personal data is handled in alignment with your policies and user rights.   Selecting the right criteria keeps your audit focused and aligned with contractual obligations and customer expectations.

Your ability to protect data is now as important as your product itself. 

When your customers, partners, or investors evaluate you as a service provider, they’re not just asking “Is your product good?”, they’re asking “Can we trust you with our data?”.

That question matters because the costs of failing to protect data keep rising. According to PwC’s 2024 Global Digital Trust Insights, the share of data breaches costing companies over $1 million jumped from 27 % to 36 %, and cloud‑related threats remain at the top of the risk list.

For startups and small to mid‑sized technology teams, this isn’t abstract risk; it’s a core commercial hurdle. Larger customers often refuse to engage without proof that you manage and protect information in accordance with recognized standards. Compliance certifications like SOC 2 have emerged as de facto trust signals that reassure buyers and accelerate vendor approvals.

At the heart of every SOC 2 audit are the Trust Services Criteria, five principles auditors use to judge how well your systems and processes protect data and support reliable operations. 

Understanding what these criteria mean in practice is the difference between scrambling at audit time and building a predictable, repeatable compliance program. In this blog, you’ll learn what the SOC 2 Trust Principles are, why auditors care about each one, and how they shape the evidence and controls your organization must demonstrate.

What are the SOC 2 Trust Principles (TSC)?

When you prepare for a SOC 2 audit, the heart of what you’re being evaluated against isn’t a checklist; it’s the Trust Services Criteria (TSC). These criteria form the foundation that auditors use to judge how well your organization protects customer data and operates reliably.

The Trust Services Criteria are defined by the American Institute of Certified Public Accountants (AICPA) and shape every SOC 2 audit. They represent established categories of internal controls that auditors use to evaluate whether your systems and processes meet industry expectations for security and trust.

There are five main trust principles in SOC 2:

• Security: The required foundation that protects systems and data from unauthorized access, misuse, or disruption.
• Availability: Demonstrates that systems remain operational and meet uptime or performance commitments.
• Processing Integrity: Confirms systems process data completely, accurately, and on time.
• Confidentiality: Safeguards sensitive business information designated as confidential from unauthorized exposure.
• Privacy: Governs the collection, use, retention, disclosure, and disposal of personal information in line with stated commitments and applicable regulations.

Security is mandatory in every SOC 2 audit. It serves as the foundation of the report, demonstrating that your systems are protected against unauthorized access, misuse, and threats.

The remaining four criteria are optional and should be selected based on your service model, contractual commitments, and the types of data you process.

This flexibility allows you to scope your audit around your actual risk profile, contractual obligations, and the expectations of the customers and stakeholders who rely on your SOC 2 report, rather than implementing controls that add complexity without business value. For example, if you commit to uptime in SLAs, Availability is likely relevant. If you collect personal data, Privacy should be included.

Ultimately, the Trust Services Criteria determine what auditors test and how they evaluate your controls. Selecting the right principles early ensures your compliance program is focused, efficient, and aligned with business needs.

Understanding the Trust Principles: What Auditors Evaluate

To pass a SOC 2 audit, you must demonstrate controls that align with each selected Trust Services Criterion in a way auditors can verify.

• Security: The Mandatory Trust Principle

   

Security, often referred to as the Common Criteria, is the one principle you cannot exclude. It forms the foundation of every SOC 2 engagement and establishes the baseline controls auditors evaluate to determine whether your systems and data are protected from threats, unauthorized access, and misuse.

Under Security, auditors assess whether your organization has designed and implemented controls that safeguard information across its entire lifecycle from collection and storage to processing and transmission.

They evaluate whether:

• Access to systems and data is appropriately restricted
• Risks are formally identified and addressed
• System activity is monitored and reviewed
• Changes to infrastructure and applications are controlled
• Incidents are detected, managed, and documented

Security is not a single control. It is the control environment that supports every other Trust Services Criterion. Without it, auditors cannot rely on the effectiveness of Availability, Processing Integrity, Confidentiality, or Privacy.

Here is a concise overview of the nine (9) Common Criteria and the types of SOC 2 controls auditors look for:

Criterion	Common Criterion	What It Focuses On	Example Controls Auditors Evaluate
CC1	Control Environment	Leadership oversight and commitment to integrity, ethics, and security	Code of conduct acknowledgement, org chart, documented security roles
CC2	Communication & Information	Internal and external communication of policies and control responsibilities	Policy acknowledgements, security training, and signed NDAs for vendors
CC3	Risk Assessment	Identification and assessment of risks that could impact objectives	Formal risk register, periodic risk assessments, vulnerability scans/pen tests
CC4	Monitoring Activities	Ongoing evaluations to confirm controls operate effectively	Internal audits, misconfiguration alerts, vendor performance reviews
CC5	Control Activities	Design and implementation of risk-mitigating controls	Security reviews before releases, policy reviews, and backup verification
CC6	Logical & Physical Access Controls	Restricting access to systems and data to authorized users	MFA on cloud/admin accounts, role‑based access, physical keycards
CC7	System Operations	Ongoing management of system performance and security	Automated health checks, incident response plan, encrypted backups
CC8	Change Management	Controlled and documented system changes	Pull request peer reviews, documented change logs for deployments
CC9	Risk Mitigation – Vendor & Third-Party Risk	Identifying and addressing risks related to vendors and business partners	Vendor risk assessments, due diligence reviews, business continuity coordination

Security is not a single control or a one-time implementation. It is the operating discipline that auditors evaluate to determine whether your control environment is reliable.

Under the Security criterion, auditors are assessing more than tools. They are evaluating whether governance, access management, monitoring, risk assessment, and change processes work together as an integrated system of control.

Evidence matters. Policies must be documented. Controls must operate consistently. Exceptions must be tracked and resolved. Logs must be reviewed. Incidents must be managed through defined procedures.

If Security is weak, every other Trust Services Criterion becomes harder to rely on.

• Availability depends on secure system operations.
• Processing Integrity depends on controlled changes and restricted access.
• Confidentiality depends on enforced access controls and encryption.
• Privacy depends on disciplined data governance.

Security is the foundation that makes the rest of your SOC 2 report credible.

For auditors and for your customers it is the baseline indicator that your organization can be trusted to operate responsibly at scale.

Examples of well-defined controls 

CC1 –  Code of Conduct & Security Governance

Management maintains a formal Code of Conduct and Information Security Policy, approved annually by executive leadership. All employees and contractors are required to acknowledge these policies upon hire and annually thereafter. Compliance is monitored by Human Resources and exceptions are documented and escalated to the CIO.

CC2 – Security Awareness Training

All employees and contractors complete security awareness and privacy training upon hire and annually thereafter. Training includes phishing awareness, acceptable use, data handling, and incident reporting procedures. Completion is tracked by HR, and non-compliance is escalated to management.

CC3 – Annual Risk Assessment

Management performs a formal enterprise-wide risk assessment at least annually, and upon significant business or technology changes. Risks are identified, assessed for likelihood and impact, assigned an owner, and documented in a risk register. Mitigation plans are tracked to completion by the Security team.

CC4 – Quarterly Control Monitoring

Internal controls are evaluated quarterly by the Compliance team to confirm they are designed and operating effectively. Identified control deficiencies are documented, assigned a remediation owner, and tracked through resolution. Results are reported to executive management.

CC5 – Segregation of Duties in Production Deployments

Production code deployments require review and approval by an individual independent of the code developer. Access to production environments is restricted to authorized personnel. Deployment approvals are documented within the ticketing system and retained for audit purposes.

CC6 – User Access Reviews

User access rights are reviewed quarterly by system owners. Terminated employees’ access is removed within 24 hours of termination notification.

CC7 – Security Event Monitoring

Security logs from critical systems (e.g., firewalls, servers, cloud infrastructure) are centrally aggregated and monitored daily by the Security team. Alerts for suspicious activity are investigated within one business day and documented in the incident management system.

CC8 – Formal Change Management Process

All system changes must be documented in a change management ticket, including description, risk assessment, testing evidence, rollback procedures, and management approval prior to deployment. Emergency changes require retrospective approval within one business day.

CC9 – Vendor Risk Management

Critical vendors are subject to a security risk assessment prior to onboarding and annually thereafter. Assessments include review of SOC reports or equivalent certifications. Identified risks must be documented and approved by management prior to engagement.

Availability: Keeping Your Service Reliable

If Security proves your systems are protected, Availability proves they are dependable.

The Availability Trust Services Criterion focuses on whether your systems remain operational and accessible in line with your contractual commitments and customer expectations. Auditors evaluate whether you have designed controls that support uptime, performance, and resilience not just in theory, but in measurable practice.

Unlike Security, Availability is optional in a SOC 2 audit. However, it becomes essential when you:

• Commit to uptime targets in SLAs
• Provide business-critical services
• Support customers who depend on continuous access
• Operate in industries where downtime carries material impact

   

Under this criterion, auditors are not asking whether outages are possible. They are assessing whether your organization can prevent, detect, respond to, and recover from disruptions in a controlled and predictable manner.

Availability demonstrates operational maturity. It shows that your service is not only secure, but engineered for continuity.

The Availability Trust Services Criterion includes the following components, which auditors review to determine whether your systems are resilient and meet defined availability objectives: 

Criterion	Control ID	What It Covers	Key Control Examples
A1.1	Capacity Management	Monitoring system capacity and performance to meet availability objectives.	Real-time monitoring of CPU, memory, storage, and network utilization; automated alerts for threshold breaches; documented capacity planning for anticipated growth and peak usage.
A1.2	Backups & Environmental Controls	Protecting systems and data from loss, corruption, or environmental disruption.	Automated scheduled backups stored in geographically separate locations; periodic backup restoration testing; redundant power and network connectivity; environmental safeguards such as fire suppression and climate controls in data centers.
A1.3	Recovery Testing	Testing disaster recovery and business continuity procedures to confirm they operate effectively.	Documented disaster recovery plan; annual recovery simulations or failover testing; tabletop incident response exercises; documented lessons learned and plan updates following tests.

 

Examples of well defined controls 

A1.1 – Capacity Management

Production system capacity (CPU, memory, storage, and network utilization) is continuously monitored. Engineering reviews capacity metrics quarterly against defined thresholds and documents remediation actions for identified risks.

A1.2 – Backups & Environmental Controls

Production data is backed up daily, encrypted in transit and at rest, and retained per policy. Systems are hosted in SOC 2 certified data centers with redundant power, HVAC, fire suppression, and physical security controls, validated through annual SOC report review.

A1.3 – Recovery Testing

A documented Disaster Recovery Plan defines RTOs and RPOs for critical systems. Disaster recovery testing is performed at least annually, and results are documented with remediation tracked to completion.

Availability is not about avoiding every outage. It is about demonstrating controlled resilience.

Auditors are evaluating whether your organization has defined availability objectives, implemented controls to support them, and tested its ability to recover when disruptions occur. They want evidence that uptime is actively managed, not assumed.

Well-defined monitoring, documented recovery procedures, regular testing, and measurable performance targets signal operational maturity. They show that your commitments to customers are supported by structured processes and ongoing oversight.

If Security establishes that your systems are protected, Availability demonstrates that they are dependable under real-world conditions.

For customers reviewing your SOC 2 report, this distinction matters. It confirms that your service is engineered not only to safeguard data, but to remain accessible and reliable when it matters most.

Processing Integrity: Accuracy and Timelines

If Security protects the system and Availability keeps it running, Processing Integrity ensures the output can be trusted.

When you include Processing Integrity in your SOC 2 scope, auditors evaluate whether your systems process data completely, accurately, and in a timely manner from input to final output. It is not mandatory, but it becomes critical when your platform performs calculations, generates reports, automates transactions, or transforms customer data in ways that affect decision-making.

Processing Integrity focuses on whether:

• Inputs are authorized, complete, and valid before processing
• System logic performs as intended without unintended alteration
• Data is not lost, duplicated, or corrupted during processing
• Outputs are accurate and delivered within expected timeframes
• Errors are detected, logged, investigated, and corrected

Auditors review documented processing workflows, validation rules, reconciliation procedures, exception reports, and error-handling mechanisms. They look for evidence that discrepancies are identified promptly and resolved through defined procedures.

This criterion is less about infrastructure and more about operational precision.

If your customers rely on your outputs for billing, analytics, financial reporting, compliance reporting, or automated decision-making, Processing Integrity becomes a core trust factor.

Strong Processing Integrity controls demonstrate that your service does not just run,  it produces reliable results.

The Processing Integrity criterion is organized into specific components that guide how auditors evaluate the accuracy, completeness, and timeliness of your system’s processing activities.

Each component focuses on a different stage of the data lifecycle from input and processing to output and retention  and requires documented controls supported by verifiable evidence.

Below is an overview of the Processing Integrity criteria and the types of controls auditors typically review.

Criterion	What It Means	Key Control Examples
PI1.1	Data entering the system is authorized, accurate, and complete.	Input validation rules, required field enforcement, format checks, automated rejection of invalid entries.
PI1.2	Documented procedures govern how data is collected and entered into the system.	Defined input handling procedures, API validation standards, user training for manual data entry.
PI1.3	System processing logic operates as intended to produce correct outcomes.	Step-level validation controls, reconciliation processes, exception handling protocols, detailed processing logs.
PI1.4	System outputs are accurate, complete, and delivered within expected timeframes.	Output validation checks, automated report generation controls, restricted distribution lists, delivery confirmations.
PI1.5	Processed data is stored, retained, and disposed of in a manner that preserves its integrity.	Encrypted storage, defined retention schedules, secure deletion procedures, integrity verification checks.

Examples of well defined controls 

PI1.1 – Data Input Validation

System inputs are validated through automated controls (e.g., required fields, format and range checks) prior to processing. Invalid or incomplete data is rejected and logged for review.

PI1.2 – Data Processing

Processing logic is defined through documented business rules and enforced via automated application controls. Changes to processing logic require testing and approval through the formal change management process before deployment.

PI1.3 – Data Output

System-generated outputs and reports include automated completeness and accuracy checks. Exceptions are logged and reviewed by Operations prior to release.

PI1.4 – Data Transmission

Data transmitted between internal and external systems is encrypted using TLS 1.2 or higher. Transmission failures generate alerts and are investigated timely.

PI1.5 – Data Storage and Retention

Production data is stored in access-controlled environments with integrity protections (e.g., database constraints and logging). Data retention and deletion are performed in accordance with the documented retention policy.

Processing Integrity is about confidence in results.

Auditors are not simply reviewing whether your system runs without error. They are evaluating whether your organization has designed controls that ensure data is processed as intended, exceptions are identified promptly, and inaccuracies are corrected before they affect customers.

Well-defined validation rules, documented workflows, reconciliation procedures, and structured error handling demonstrate that processing outcomes are controlled, not left to assumption.

If Security protects the environment and Availability keeps it operational, Processing Integrity ensures the outputs generated within that environment can be relied upon.

For customers who depend on your platform for financial reporting, analytics, transactions, or operational decisions, this distinction is critical. They are not only trusting you to safeguard their data they are trusting you to produce accurate results.

Strong Processing Integrity controls show that your systems do not just function. They function correctly, consistently, and predictably.

Confidentiality: Protecting Sensitive Information

If Security establishes who can access your systems, Confidentiality defines what must be protected within them.

The Confidentiality Trust Services Criterion focuses on how your organization identifies, restricts, and safeguards information designated as confidential. Auditors evaluate whether sensitive business data is clearly classified, appropriately protected, and disclosed only in accordance with contractual and operational commitments.

This criterion applies when you manage information that customers expect to remain restricted not because it is personal data, but because it is commercially sensitive.

Confidential information may include:

• Intellectual property
• Financial records
• Strategic or operational plans
• Proprietary algorithms or product designs
• Customer business documents

Unlike Privacy, which governs personal information and individual rights, Confidentiality centers on protecting business-sensitive data from unauthorized access or exposure.

Under the Confidentiality category, auditors focus on two control areas:

Criterion	Control ID	What It Covers	Key Control Examples
C1.1	Identification and Protection of Confidential Information	Confidential information is defined, classified, and protected against unauthorized access or disclosure.	Documented data classification policy; encryption at rest and in transit; role-based access controls; confidentiality clauses in customer and vendor contracts; access logging and monitoring.
C1.2	Retention and Disposal of Confidential Information	Confidential information is retained only as long as necessary and disposed of securely when no longer required.	Defined data retention schedules; automated archival processes; secure deletion tools; documented destruction procedures for physical media; periodic review of retained data.

Examples of well defined controls 

C1.1 – Confidential Information Protection

Confidential information is classified in accordance with the Data Classification Policy and restricted to authorized personnel based on role. Access to systems containing confidential data is reviewed at least quarterly by management, and inappropriate access is removed timely.

C1.2 – Confidential Information Disposal

Confidential information is securely disposed of in accordance with the Data Retention and Disposal Policy. Electronic data is deleted using secure deletion methods, and physical media containing confidential information is destroyed by an approved vendor. Disposal activities are documented and retained for audit purposes.

Confidentiality is about disciplined restriction.

Auditors are evaluating whether your organization has clearly defined what constitutes confidential information and implemented controls to ensure it is accessed, shared, retained, and disposed of appropriately.

It is not enough to say data is sensitive. You must demonstrate that it is formally classified, protected through enforced access controls and encryption, and monitored to prevent unauthorized disclosure.

Well-designed Confidentiality controls show that sensitive business information is not broadly exposed within your environment and is not retained longer than necessary. They demonstrate intentional handling, documented oversight, and consistent enforcement.

If Security protects your systems and Processing Integrity protects your outputs, Confidentiality protects the business value embedded in the data itself.

For customers and partners reviewing your SOC 2 report, this provides assurance that proprietary information, strategic data, and sensitive records are treated with the level of protection their contracts and expectations require.

Strong Confidentiality controls signal maturity, discipline, and respect for the trust placed in your organization.

Privacy: Personal Data Handling

If Confidentiality protects business-sensitive information, Privacy protects individuals.

The Privacy Trust Services Criterion evaluates how your organization collects, uses, retains, discloses, and disposes of personal information in accordance with your stated commitments and applicable regulatory requirements.

This criterion applies when your service processes personally identifiable information (PII) or other data linked to individuals. It extends beyond technical safeguards and examines whether your governance, policies, and operational practices respect individual rights and reflect responsible data stewardship.

From an auditor’s perspective, the core question is straightforward:

• Does your organization handle personal data in a manner that is consistent with its privacy notice and regulatory obligations?

To answer that, auditors assess whether privacy practices are:

• Clearly defined and publicly communicated
• Operationalized through documented procedures
• Consistently enforced across systems and teams
• Supported by verifiable evidence

Here’s what auditors specifically evaluate under the Privacy criterion:

Criterion	Control ID	What It Covers	Example Controls
P1.0	Notice & Communication of Objectives	Providing clear notice about privacy practices prior to collecting personal information.	Published privacy policy; layered privacy notices; cookie disclosures; onboarding privacy acknowledgements; documented updates to privacy statements.
P2.0	Choice & Consent	Providing individuals with choices regarding the collection, use, and disclosure of personal information, where required.	Opt-in mechanisms; consent management tools; preference centers; consent withdrawal processes; maintained consent logs.
P3.0	Collection	Limiting the collection of personal information to what is necessary for defined purposes.	Data minimization standards; documented purpose specifications; restricted form fields; anonymization or pseudonymization practices.
P4.0	Use, Retention & Disposal	Using personal information only for disclosed purposes and retaining it only as long as necessary.	Defined retention schedules; automated data lifecycle controls; secure deletion procedures; periodic data review and cleanup.
P5.0	Access	Allowing individuals to access, correct, or delete their personal information, as applicable.	DSAR intake and tracking processes; identity verification procedures; documented correction workflows; response time monitoring.
P6.0	Disclosure & Notification	Controlling third-party disclosures and notifying individuals or regulators when required.	Vendor data-sharing assessments; contractual data protection clauses; breach notification procedures; documented incident communication plans.
P7.0	Quality	Maintaining accurate, complete, and relevant personal information.	Input validation checks; user self-service update functionality; periodic data accuracy reviews; reconciliation processes.
P8.0	Monitoring & Enforcement	Monitoring compliance with privacy commitments and enabling reporting of concerns.	Internal privacy audits; escalation procedures; privacy training programs; documented investigation and remediation processes.

Examples of well defined controls 

P1.1 – Notice and Communication of Objectives

Management maintains a publicly available Privacy Notice that describes the categories of personal information collected, purposes of use, sharing practices, retention, and data subject rights. The Privacy Notice is reviewed and approved at least annually and updated for material changes.

P2.1 – Choice and Consent

Where required by law or policy, explicit consent is obtained prior to collecting or processing personal information. Consent records are retained within the system and enforced through application controls.

P3.1 – Collection

Personal information collected is limited to what is necessary to fulfill documented business purposes. New data elements require documented review and approval by the Privacy Officer prior to implementation.

P4.1 – Use, Retention, and Disposal

Personal information is used only for purposes disclosed in the Privacy Notice and retained in accordance with the Data Retention Policy. Upon expiration of the retention period, data is securely deleted using approved deletion methods.

P5.1 – Access

Data subjects may submit requests to access, correct, or delete their personal information through a documented request process. Requests are authenticated, logged, and fulfilled within defined regulatory timeframes.

P6.1 – Disclosure to Third Parties

Personal information is disclosed to third parties only under executed agreements that include confidentiality and data protection provisions. Third-party disclosures are documented and subject to vendor risk review.

P7.1 – Quality

Personal information is maintained to be accurate and complete through automated input validation controls and mechanisms allowing individuals to update their information as appropriate.

P8.1 – Monitoring and Enforcement

Management monitors compliance with privacy policies at least annually. Privacy incidents are logged, investigated, and remediated in accordance with the Incident Response Plan, with corrective actions tracked to completion.

Privacy is where compliance, governance, and trust converge.

Auditors evaluating the Privacy criterion are not only reviewing technical safeguards. They are assessing whether your organization has operationalized its privacy commitments in a way that aligns with recognized regulatory expectations and individual rights standards.

Well-defined notice practices, documented consent mechanisms, controlled data collection, enforced retention limits, and structured response procedures demonstrate that privacy is embedded into your systems  not handled reactively.

The Privacy criterion in SOC 2 is closely aligned with broader data protection frameworks and regulations, including GDPR, CCPA/CPRA, and other global privacy laws. While SOC 2 is not a certification of regulatory compliance, strong Privacy controls often support and complement these legal requirements by demonstrating:

• Transparency in data handling
• Purpose limitation and data minimization
• Defined retention and secure disposal
• Individual access and correction rights
• Structured breach notification processes

For organizations operating across jurisdictions, this alignment strengthens your overall privacy governance posture and reduces regulatory risk exposure.

If Confidentiality protects business-sensitive information, Privacy protects the rights and expectations of individuals.

For customers, partners, and regulators reviewing your SOC 2 report, inclusion of the Privacy criterion signals that personal data is managed deliberately, consistently, and in accordance with established standards.

Strong Privacy controls do more than meet audit requirements. They demonstrate accountability and in today’s regulatory environment, accountability is a competitive advantage.

Final Thoughts: What Auditors Ultimately Evaluate

A SOC 2 audit is not a review of intentions. It is an attestation engagement. Under AICPA standards, a SOC 2 report is an independent auditor’s opinion on whether your controls were suitably designed and, in the case of a Type 2 report, whether they operated effectively over a defined historical period.

Auditors are evaluating more than policies. They are evaluating evidence. They assess whether:

• Controls are formally documented
• Responsibilities are clearly assigned
• Processes operate consistently
• Exceptions are identified and remediated
• Monitoring activities are performed and reviewed
• Evidence demonstrates operation over time

For a Type 1 report, the auditor evaluates the design of controls as of a specific point in time.

For a Type 2 report, the auditor evaluates both design and operating effectiveness over a defined review period typically six to twelve months based on historical evidence.

That distinction matters.

SOC 2 is not about future plans. It is about demonstrating that your controls existed and functioned as described during the audit period.

Across Security, Availability, Processing Integrity, Confidentiality, and Privacy, the auditor’s objective is consistent:

• Do your controls align with the Trust Services Criteria?
• Are they designed appropriately?
• And did they operate effectively over time?

When the answer is supported by sufficient, appropriate evidence, the result is an independent opinion that strengthens credibility with customers, partners, and stakeholders.

In today’s environment, trust is not assumed. It is examined, tested, and attested to.

SOC 2 provides the structure. Your controls provide the proof.

Choosing the Right Trust Principles for Your Organization

When you scope your SOC 2 audit, one of the most strategic decisions you’ll make is which Trust Services Criteria (TSC) to include. 

• Every SOC 2 report must cover Security, but beyond that, the other criteria are optional. They should align with your product, customer expectations, and real business risk rather than being chosen arbitrarily.
• Start by understanding your product and how customers use it. If your service includes uptime guarantees, a backup‑dependent workflow, or contractual service level objectives, including Availability makes sense.
• If your system processes sensitive business information or personal data for end users, then Confidentiality or Privacy should be in scope. 
• Likewise, if accuracy and timing of data outputs matter to your customers, Processing Integrity might be relevant.

A practical guideline for early‑stage teams is to begin with Security, plus one optional criterion that most closely aligns with your core service promise. Security provides the essential baseline assurance that auditors and buyers expect; adding another criterion keeps the initial audit more focused and manageable while still demonstrating meaningful control breadth. 

Many small businesses start with Security and Availability if they promise service reliability, or Security and Confidentiality if they handle proprietary customer information.

By selecting only the principles that matter most for your business and customers, you keep your SOC 2 audit focused, efficient, and aligned with real assurance value, not just a broad checklist.

Assessing Your SOC 2 Readiness? Get Auditor Guidance With Decrypt Compliance

SOC 2 compliance doesn’t have to slow down your business. Many companies face delays because they’re unsure where to start, what evidence to gather, or how to prepare for an audit without disrupting operations. Decrypt Compliance removes that uncertainty, providing clear guidance from day one and eliminating the guesswork that causes delays.

As a tech-first audit and compliance firm, we specialize in helping startups and growing teams achieve SOC 2 compliance quickly and accurately, with a deep understanding of how modern companies operate.

Decrypt Compliance keeps your certification journey smooth, efficient, and audit-ready.

Talk to an Auditor!