When people think of SOC 2®, security often takes center stage. But there’s so much more to it. Beyond safeguarding data, SOC 2® is also about reliability, ensuring that your systems are not just secure but also consistently available and accurate. Two key criteria that embody this are Availability and Processing Integrity. Let’s dive into what these mean, why they matter, and how they can help you build trust with your customers.
Why Availability and Processing Integrity Go Hand-in-Hand
While the Security criteria is the only mandatory requirement in SOC 2®, Availability and Processing Integrity are often the next logical additions, especially for SaaS companies or those handling large volumes of data. Together, they address two critical questions:
- Can your service be relied on to stay up and running? (Availability)
- Can it be trusted to deliver correct, complete, and timely results? (Processing Integrity)
From a user’s perspective, it doesn’t matter how secure your platform is if it’s unreliable. These criteria help you ensure your service works smoothly, accurately, and consistently, day to day, not just on paper.
What Does “Availability” Mean in SOC 2®?
Availability refers to your organization’s ability to keep systems up and running, even during unexpected disruptions. It’s about ensuring service continuity, anticipating system loads, and having a robust plan for fast recovery.
The AICPA defines Availability through a single category (A1) with three criteria, each supported by detailed Points of Focus:
A1.1 – Performance and Capacity Management
Organizations must monitor current usage of system components (like infrastructure, data, and software) and proactively manage load. This includes forecasting growth, identifying bottlenecks, and ensuring enough resources are available to meet stated availability goals, particularly those outlined in SLAs.
A1.2 – Environmental Protections and Backup
This includes the design, implementation, and maintenance of environmental safeguards such as failover systems, power backup, cooling infrastructure, and off-site redundancy. It also requires up-to-date and tested backup procedures to reduce the impact of outages, hardware failures, or disasters.
A1.3 – Recovery Testing
It’s not enough to have a plan, organizations must regularly test their disaster recovery and business continuity plans to confirm systems can be restored within the required recovery time objectives (RTOs). This includes tabletop exercises, failover simulations, and documentation reviews.
Important: The Availability criterion doesn’t set a minimum performance threshold. Instead, it verifies whether the system operates as intended and is accessible to users according to expectations and commitments, typically benchmarked against declared SLAs.
To comply with Availability, companies typically implement:
System monitoring tools and performance dashboards
Alerting and escalation procedures for outages
Documented DR/BCP plans with clear ownership
Transparent incident communication protocols
Curious about what’s required during an audit? Check out the SOC 2® Audit Checklist for a detailed breakdown of availability documentation.
What Is “Processing Integrity” in SOC 2?
Processing Integrity is all about how well your systems handle data, specifically whether they process information accurately, completely, in the correct order, and on time. This criterion is especially important for companies delivering automation, financial calculations, reporting engines, or real-time data processing.
Within the Trust Services Criteria, Processing Integrity is described in a single category (PI1), which contains five criteria designed to validate the correctness and dependability of system behavior:
PI1.1 – Define Processing Requirements and Information Quality
Organizations must clearly define and communicate expectations for data quality and processing, which includes what input, transformed, and output data should look like, and the rules that guide how information flows through the system.
PI1.2 – Input Data Validation
This criterion ensures that policies and procedures are in place to verify that data entering the system is valid, complete, and within expected ranges. Controls may include mandatory field validation, data type enforcement, or real-time rejection of malformed inputs.
PI1.3 – Processing Control
Here the focus shifts to the transformation process itself. The system must process inputs completely and correctly, without unauthorized alterations, omissions, or delays. This includes checks for data integrity during execution and logging any deviations.
PI1.4 – Output Verification
Organizations need mechanisms to ensure that system outputs (e.g., reports, invoices, updates) are timely, accurate, and delivered in the correct format to the correct recipients. This helps avoid costly misunderstandings or compliance failures.
PI1.5 – Data Storage and Protection
It’s not just about real-time accuracy; organizations must also preserve input, in-process, and output data securely over time. This means storing logs, records, and results in a tamper-proof way that meets legal or customer-specific retention requirements.
Note: Processing Integrity is especially relevant in industries like fintech, payroll, and accounting, where data quality has a direct impact on financial or legal outcomes.
To address this criterion, companies often implement:
Business rule validation engines
Queueing systems with retry and failure tracking
Audit logs and change history for processed data
Automated exception reports and escalation paths
Manual QA reviews for edge-case transactions
For a broader understanding of SOC 2 compliance, take a look at What Is SOC 2 Compliance?, a guide tailored for CEOs and CTOs navigating client-driven security expectations.
When Should You Include These Criteria in Your Audit?
Deciding whether to include Availability and Processing Integrity in your SOC 2® audit depends on your business model and customer expectations. Here’s a quick guide:
- Choose Availability if system uptime is a core part of your promise to customers.
- Add Processing Integrity if your product performs critical data operations or business logic.
Including these criteria sends a clear message: We don’t just secure your data—we deliver a dependable service.
How These Criteria Tie Into the Bigger SOC 2® Picture
While Security (CC1–CC9) forms the foundation of SOC 2®, Availability and Processing Integrity are deeply interconnected with it. For example:
- Controls like change management (CC8) and system monitoring (CC7) directly support Availability.
- Availability failures can escalate into Confidentiality risks, such as data loss or exposure.
- Processing errors can undermine Privacy or the overall trustworthiness of your audit.
If you’re planning to pursue multiple Trust Service Criteria, understanding these connections is essential for scaling your compliance program effectively.
Final Thoughts
SOC 2® is a reflection of how seriously your company takes operational responsibility. By including Availability and Processing Integrity alongside the Common Criteria, you’re sending a strong message to customers and auditors alike: This platform works the way it’s supposed to, even under stress.
So, whether you’re a startup or an established enterprise, embracing these criteria shows that you’re committed to delivering not just a secure service, but a reliable one as well.
Suggested Reading
- Understanding SOC 2 Trust Service Criteria – the full breakdown of all 5 TSC.
- SOC 2 vs ISO 27001 – Which framework fits your growth strategy?
- How Startups Can Get SOC 2 Compliance Without a Security Team – practical advice for lean teams.
